John Dowson

Please check for similar topics before posting....see John

Ok. Please also see the following post, and also the links that it references: John

The Gear Up and Gear Down work fine in those aircraft for me, so something else must be going on. Can you please do as I previously advised: Thanks, John

What is the problem with assigning to this button - is it recognised by FSUIPC when you press it? Not sure what you mean by 'clickable area' on this context - what has this got to do with key presses? Can you please explain. Are you sending key presses to P3D via button assignments, or assigning key presses in FSUIPC to send controls? Could you show me your FSUIPC6.ini and FSUIPC6.log files. For the latter, activate logging first for Buttons & Keypresses as well as for Events (non-axis controls), and generate a log where you press your keys or buttons that are not working as expected, and I will take a look. John

event.intercept intercepts offset writes, not actual events. I don't see how this can prevent the flight plan from being deleted (if that is the case...), intercepting this can only prevent the location of the flight plan held in the offset from being overwritten. The current flight plan path is held in offset 0x0130. You can try to intercept that and prevent that being cleared, but you would still want to write the actual flight plan to that offset when it is received. You could possibly copy the floght plan to another location when received, of you can set the location for the flight plan in the other add-ons that use this. Otherwise, I would try to stop the add-on deleting the flight plan on touchdown, if possible. Maybe contact the support for this add-on to see if that can be done. John

So you cannot even assign the axis in the axis assignment panel? Is anything on your device recognised - any axis or button? No mod will fix the controller not being recognised - this is a windows issue. Can you please show me your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files and I will take a look. John

Hi Draci, This is VERY strange! I don't really have a clue on what could be causing this.... The 'Mode: FREEZE_ATT...' log line is just a log message of events received from the FS - FSUIPC just logs these and takes no action, so it should not affect any functionality. There are no messages indicating simconnect data stalled or FSUIPC reconnected either, so it looks like data is still being received. FSUIPC is not quitting. In fact, you have a log message from a lot later: 12464485 **** Restarting traffic scanning due to non-reception **** and no shutdown messages, so either FSUIPC was still running when you attached the log file, or it has crashed. If P3D is still running, then FSUIPC is still running. Vheck the windows event viewer though, to see if windows is logging anything there when this occurs - show me anything relevant you find there. Try setting the stall times to negative numbers - this will then just log a message when stalled rather than re-connecting. Use the following: TrafficStallTime=-1 NormalStallTime=-1 Also activate logging for Buttons & Key presses as well as Events. If you do this, the next time you get this issue try pressing an assigned button and see what gets logged - you can attach the log again here and I will take a look. John

Maybe it will. What wind smoothing options have you set? See the Advanced User guide for details on wind smoothing options. May be better to ask on those posts what wind smoothing settings should be used to counter-act this problem with Rex. John

👍

Do you have any references/links? That sounds like a problem with Rex and I have no idea why anyone would think just installing FSUIPC would solve this issue. Sounds like you need Rex support really... John

Ok, thats strange. This was certainly working last time I checked, I will check again. Ok, I have them - I'll check tomorrow and let you know. I understand...I haven't done any recreational flying for a long long time now, only short flights to look into other peoples issues... John

Hi. I have no idea what problem you are referring to, or why you would think that installing FSUIPC4 would solve this problem. What led you to believe it would? John

Isn't that where I said it should be, and where you should be putting your *.hvar files?

Sorry, no idea why its crashing. You are also using an unregistered version, so FSUIPC isn't doing that much, just requesting data from the FS and using that to populate the FSUIPC offsets. Ok, lets see what they say... John

Then the location must have changed. Try searching for the FSUIPC_WASM.log file (try using Everything if you have that, otherwise I recommend you install - it is quite useful for finding things...)- wherever that is, that is the folder where you should add your hvar files (and also where you should make updates to your FSUIPC_WASM.ini, to prevent them being overwritten when re-installing). It seems to be in a very strange location for MS Store installs, but there should be also be a link/shortcut/junction to the folder somewhere under your AppData folder... Please let me know the location if/when you find it.... John

Yes, I have just noticed that file, and have now added the hvars to it. But deleting that should have no affect at all - that folder IS NOT USED. You need to copy/move the .hvar files from that folder to one of the two correct locations for them to be used. There are two 'correct' folders for the hvar files - please see my comment above, or the Advanced User manual. Only the one in Community/fsuipc-lvar-module/modules will be used. Bit you should really put that file in the other location, to prevent the A320.hvar file also being loaded when you re-install, as explained above.... You mean an MS Store installation? FSUIPC7 does not run on the xbox... From the Advanced User manual, P46

Ok, thanks Paul. No need to do this with lvars as I don't think they can be duplicated (although I may be wrong. I will also update the WASM to remove duplicate (full) hvar names, but this won't be until the next FSUIPC7 release now. However, once I have implemented this, you could still possibly see duplicate hvar (and lvar) names if they are the same in the first 55 characters but differ after that. I allow this as all actions on hvars/lvars are performed on id, so as long as you know the correct id of the lvar/hvar you are using, the name doesn't matter. The user would only see the 55 character truncated name though, so would somehow need to know which is which (either via testing, or for hvars by checking the order in the .hvar file(s)). Yes, that works for me. It shows the duplicated hvars though, which I think is better... Ok. You should put your (renamed) hvar files under the AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module\work folder (for Steam, path is different in MS Store installations) instead. When a hvar file is loaded from this folder, it will not scan the Community\fsuipc-lvar-module\modules folder for further hvar files. Try as advised above, i.e. use the other folder for your hvar files. This is not touched during installation. John

Only in the WASM, not the WAPI. The WAPI is fine - that is used by FSUIPC7 without issue. I don't use the WAPID.dll, I just updated the WAPI in the WAPID project and recompiled. Was the WebSocket server previously tested with hvars? I have just checked again and now also have it working with hvars! It seems the issue/crash occurs when I have duplicate hvar files being loaded, i.e. when a hvar name is duplicated. I removed/renamed one of the hvar files (I was loading two files containing the same hvar names), and now it seems to be working ok. @Scotfleiger Are you also perhaps still loading multiple hvar files, or have duplicate hvar names? Ah...that could be a problem... Do you have any unit tests with the WAPI calls mocked-out? If so, you could maybe try a test with duplicate hvar names, to see if that is the issue. I can (and probably should) update the WASM to not allow duplicate hvar names really. Doesn't make any sense to allow this - apart from if they are the same for the first MAX_VAR_NAME_SIZE characters (currently set to 56) and then differ...

No idea - this is the first time I have heard of the LVLD.dll. Is this something that is used by the Level-D Simulations 767? Id so, ir seems strange that is is being loaded from the DLL.xml, i.e. for every flight, even if not using the 767. Or is this something else? I don't know.... Sometimes the order does matter, so just try switching the order, to see if that helps. No. I don't understand why an older version of FSUIPC4 would work but the latest not. Omly the latest version of FSUIPC4 is available and supported. I really do not know what to advise here. I you tried support from Level-D Simulations? If you attach your FSUIPC4.log file for when FSUIPC4 crashes on start-up I can take a look. This may reveal something. John

Just tried with a different aircraft and it is working fine. The 2nd aircraft I tried had no hvars - could it be an issue with receiving hvars? Can I generate a WAPI log file from the websocket server, and if so, how? I can see a log level in the config file, but no output file is produced - does it just log to the websocket server console? John

No. The only change in this WAPI version was to update the compatible WASM version, and to change the check on WASM versions to just log a message if the version of the installed WASM doesn't match and continue, rather than stop. John

I get the same behavior. It seems to crash on or soon after receiving the CDA data. It is reporting the correct WASM / WAPI version though. I had forgotten that the websocket server was included in the Utils folder. I will update the released installer with the latest websocket server version, although I'll wait to see if this issue can be addressed first. I will also give Paul advanced noticed of any WAPI updates so that i can include a compatible websocket server version when I release. John

Thanks Paul! John

I am not a sure I fully understand what you are trying to say... Are you calibrating with a reverse zone on the axis? If so, then you should assign the "stop" button (on your axis) to the Throttle Dec control, both on button press and release (in the buttons and switches page, as you say). This should then trigger reverse thrust when you hit the stop button and move the throttle down. Alternatively, depending on how this "stop" button functions, you may need to assign to Throttle Dec with repeat on button press, and Throttle Cut on release. Also, if assigning two axis for throttle 1 and throttle 2, then use the Throttle 1/2 dec ()and maybe throttle 1/2 cut) controls instead. Otherwise, maybe try setting the [JoystickCalibration] INI parameter UseAxisControlsForNRZ to Yes. See the Advanced user guide for the details on this option.

Ah, sorry... I forgot that the WebSocket server was developed by @Paul Henty. He needs to make a new version of the web-socket server (and also the .net client dll) to be compatible with the latest release. Hopefully he will pick-up the tag and update, otherwise I will DM him. John