John Dowson

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

AXIS_MIXTURE4_SET is a standard MSFS/SimConnect control - you do not need to use event files. Just assign your tiller axis to that axis controls. And when using event files, you do not need to 'write inside the file'. Those are controls and control numbers, not parameters. TO use TOGGLE_TAXI_LIGHTS, just assign to the control Toggle Taxi Lights in the FSUIPC control dop-down - its a toggle control so no parameter needed. To use the TAXI_LIGHTS_SET control, assign to Taxi Lights Set and the parameter will be 1 for on and 0 for off. If you want to understand what the controls do and the parameter means (when nbot obvious), you need to consult the MSFS documentation - see https://docs.flightsimulator.com/html/index.htm#t=Programming_Tools%2FSimVars%2FEvent_IDs.htm. For the FBW A320, you should consult the MobuFlight hubhop preset list: https://hubhop.mobiflight.com/#/list This lists the following MF presets for the nose light switch: Looking at the code for those presets, they are using a combination of lvars and 2 events, You can set-this up directly using FSUIPC, but it would be much easier if you installed the MF WASM module and use those presets directly. To do this, once you have installed the MF WASM module, create an event file in your FSUIPC7 installation folder (eg FBW-A320-nose.evt) with the following content: [Events] 0=MobiFlight.NOSE_LIGHTS_OFF 1=MobiFlight.NOSE_LIGHTS_TAXI 2=MobiFlight.NOSE_LIGHTS_TO You can then assign to those MF events directly. You can also use the provided MF event files for the DVW A320 - A32X-FBW1.evt and A32X-FBW2.evt (located under the EventFiles sub-folder of your installation). However, I have not updated these in quite a while and so they are out of date, with many events missing, such as these. You could use these files, and add any missing entries to the A32X-FBW2.evt file (max of 256 entries per file, with 255 being the highest index number). No idea. Check the MF preset list to see if anything looks appropriate. Otherwise you can try activating logging (for events and axis controls) and seeing what is logged when you change the lights in the UI, and then assign to those controls. There is a lot of information available both in these forums and elsewhere. If using the FBW, also check there discord channell, as well as the MobiFlight discord channel and resources. For FSUIPC, you should at least take a look at the provided documentation. John

Also, please make sure that you are using the latest version of FSUIPC, v7.2.14 (v7.2.15 will be released tomorrow). If not, please download and re-install. Only the latest version of FSUIPC is supported. John

Not sure what this means.... Do you mean that when you start FSUIPC7, it opens the steam app? Or when you open an FSUIPC client (which client?) it opens the steam app? FSUIPC7 works both with MS Store and Steam MSFS installations. Did you actually install FSUIPC7? Have you tried running it (by double-clicking the FSUIPC7.exe)? If you are having problems installing FSUIPC7, please show me your InstallFSUIPC7.log file. If you are having problems running FSUIPC7, please show me your FSIOPC7.log file. Otherwise, please try and explain your problem a bit clearer... John

No problem - hope it wasn't too much of an ordeal, and I wish you a speedy recovery. Ok, glad it all seems yo be working now. No problem. Sorry it took so long to get there! John