John Dowson

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

Why would that may any difference? No idea why you would want to do that... You need to recompile the WebSocket server code using the latest WAPI lib and headers (0.5.6). It looks like it is still compiled against version 0.5.5. Did you not try that?

If you are creating the assignment in the UI, it should take affect straight away, with no need for an MSFS restart. If you are manually editing the ini, then a combination of a WASM reload and an assignments reload should suffice - there are buttons in the Button, Key and Axis assignment panels to reload your assignments - try using those. And you should never need to restart MSFS. You should be able to get away with reloading your assignments for most (manual) changes, but for some changes you may need to restart FSUIPC7 (but not MSFS). Just exit MSFS and restart it by double-clicking the FSUIPC7.exe file, not using the desktop icon that starts MSFS. John

How can you have both 5.1 and 5.3 installed on the same PC? I did not think this was possible... How did you install FSUIPC6 into both versions? The installer will only find one version, based upon the P3D registry entries, and install into that.... Did you manually create an add-on.xml file for one of the P3D versions? Are you using the same FSUIPC6 installation for each version? Try activating logging in FSIUPC for Buttons & Key presses as well as events. Then produce a short log file in each version, where you load an aircraft and then operate one of your switches (that works in one version and not in the other). Then exit P3D. Do this in each version and show me your FSUIPC6.ini and the two FSUIPC6.log files, one for each P3D version.

This sounds very strange... I have no idea what could cause such behavior. Did you update all threeP3D components, Client, Content and Scenery? Not sure what to suggest, except maybe to try re-installing the P3D client. Also, check your FSUIPC6 installation folder - make sure that it is not installed under a windows protected folder, such as Documents or Program Files. If it is, try installing in a different location. To do this, just re-run the installer and select a different installation folder - you can skip registration. After re-installation, uou can copy your existing files (FSUIPC6.ini, FSUIPC6.key, *.lua, *.mcro, *.dll) to the new installation folder. John

FYI, I have also updated the compatibility check om the latest version. Now it will log a message if using a different WAPI version (that may not be fully compatible with the installed WASM) but will continue, rather than stop/disable. John

Yes - I am Pete's son. Thank you for your king comments. Regards, John

First, all custom events must contain a period (.). So, if it is an FBW A320 event, it should be: 30=A32NX.PUSH_OVHD_CALLS_ALL Check all the other events in that file, and you will see that they are all prefixed in this way. Second, are you sure that those are actually existing FBW events? Checking the MobiFlight hubhop resource (https://hubhop.mobiflight.com/#/list), I can see the following MobiFlight events: PUSH_OVHD_CALLS_ALL_OFF PUSH_OVHD_CALLS_ALL_ON These events are listed in the A32X-FBW2.evt file, so you need to use that if you want to use these MobiFlight presets. Alternatively, those events just set/toggle the lvar L:PUSH_OVHD_CALLS_ALL. You can use the lvar directly in FSUIPC rather than using MobiFlight events, by either adding this lvar to an FSUIPC offset or using a macro file. Details of both techniques can be found in the User Guide and Advanced User guide. John

Writing to offsets can update the relevant simvar directly if the simvar is writeable, and use events otherwise. This is documented in the FSUIPC Offset document as Ok-SimC when updating a simvar directly, and Ok-SimE when using events (with ?-SimC and ?-SimE being used when status unknown or different for different aircraft). The master battery offset is Ok-SimC and so will update the ELECTRICAL MASTER BATTERY simvar (offset 0x281C) directly and no event will be seen. John P.S. Glad you solved your issue!

Can you please check that you are using the correct header file in the include folder. The WASMIF.h file should contain: #define WAPI_VERSION "0.5.6" It looks like you are still using the 0.5.5 release. I have checked the downloadable zip (available at www.fsuipc.com) and this does contain the correct version. So, update and recompile using the latest WAPI from that zip - both headers and lib. John Later: also checked the FSUIPC-WASM.zip included in the FSUIPC SDK folder, and that also contains the correct version.

First, Pete has now retired (although he does monitor the forums and will occasionally help out), and I am now providing support (and development) if FSUIPC and WideFS. FSUIPC uses SimConnect for most interactions with P3D, although not all (e.g. access to lvars is done using the panels.dll functions). Could you please provide me with your FSUIPC ini file so that I can take a look at your settings. Also, I need to see your FSUIPC log file that shows one of your issues, i.e. a programmed button not working. To do this, activate FSUIPC logging for Buttons & key presses as well as Events, and generate a short log file where you load your aircraft and activate a button or switch that is assigned in FSUIPC (and not working), then exit P3D and show me the log file and I will take a look. John

I have moved your post to the FSUIPC7 / MSFS sub-forum. How to set-up the trim wheel has been asked many, many times before - try searching this forum and you will find numerous posts. However, note that the honeycomb trim wheel works on buttons, not an axis, so you cannot use axis controls with buttons (well you can but that is quite advanced, and you really shouldn't be doing this for the honeycomb trim wheel. I have even posted my Honeycomb settings, including the trim wheel - see If you want to try FSUIPC7, you can find a trial license in a sticky post at the top of this forum. John

First, I have moved your post to the FSUIPC7 / MSFS sub-forum. You can post in the User Contributions section once you have your contribution available! Not sure what you mean by IDE in this context - I would have though that most of the common IDEs (Visual Studio, Netbeans, Eclipse, etc) would support lua. I don't see the need and just use Notepad++ for my scripts. LINDA is the only high-level lua solution for use with FSUIPC7 as far as I am aware, although I wouldn't class this as an IDE for lua, but it may also serve that purpose I guess (I don't use this myself). You could try asking over on the LINDA support forum: https://www.avsim.com/forums/forum/429-linda-support/ Cheers, John

Ok, but if you let me know the aircraft (plus any mod) you are using I can probably help without seeing your logs, as I can try here, if not using a specific add-on that I don't have... John