John Dowson

Ok, thats good to know...and rather surprising! At least the installer needs to be updated to install the auto-start component. You could try manually adding the FSUIPC7 entry to the MSFS24 EXE.xml file, which should enable the auto-start. Did you try installing the FSUIPC WASM module into the MSFS2024 Community folder? Just copy from your MSFS2020 Community folder. This is needed for the functionality for presets, lvar & hvars. Well, they always have been, hence the need for presets... Anyway, I will review the MSFS2024 documentation on the available events/controls, when available. John

Maybe - if supported by the aircraft. As that event doesn't exist in P3D, for any aircraft that allow other values for anti-ice rather than on/off, then it must use something else, i.e. another event (or custom control) or possibly an lvar. For which aircraft are you trying to use with this event? If the aircraft supports gradual anti-ice, then try activating logging for axis controls, open the FSUIPC logging window and see what, if any, events are logged when you move the gradual anti-ice in the virtual cockpit. If any event is logged, you can try assigning to that. Otherwise, look to see what lvars are available and see if any look applicable, and if so what value range the lvar takes. If an lvar is used, you can create a lua script and use this via assigning your axis to an FSUIPC offset - I can help further with this if needed.

Please see the following post and use that for any other queries/questions on using SkyDemon with FSUIPC: John

Please note that FSUIPC only send out GPS data to serial/com ports, not to the network. This is why you need additional software (Flight Sim GPS) which (I guess) takes the GPS data from a virtual com port and sends it out to the network, This software doesn't seem to be available any more (if anyone can provide this or knows where it can be downloaded, please advise!), and so I think your best solution would be to use the MSFS Bridge Connector, which is payware but very cheap (5-6euros). Otherwise, for use on an iPad, you would need to connect the iPad to your PC via a USB-serial cable. For running SkyDemon on a PC, either the same PC or a client PC, you will need to set-up some virtual com ports. This is described in the following posts (for FS9 & FSX/FSUIPC4 but applies to later version of FSUIPC and P3D/MSFS):

Note that someone has RC4 working (more-or-less!) with MSFS, using ShowText for the menus. See the following post: An issue has also been reported when using PF3 with both FSUIPC7 and FSUIPC6 - see This is corrected in the latest beta release of FSUIPC7 (see Announcements sub-forum) and there is also a patched version of the FSUIPC6.dll available with a fix for this in that post referenced above. John John

@Gabe_62 & @Ray Proudfoot: someone has RC4 working (more-or-less!) with MSFS, using ShowText for the menus. See the following post:

The available controls are determined by the FS, not FSUIPC. When FSUIPC6 is ran, it will also create a text file listing all available controls for the current FS, located in your FSUIPC documents folder, with the file name starting 'Controls List for P3Dv....'. But as far as I am aware, the ANTI_ICE_GRADUAL_* controls/events are for MSFS2020 only - there are not known by any version of P3D (or FSX).

Ok - then follow the instructions in that FAQ entry, i.e. set the WASM ini parameter LvarScanDelay to 0. Once this is set, the lvar scan will only be performed on initial aircraft load. If you create new lvars via FSUIPC with the provided lua function, or if created by writing to offsets, then FSUIPC should automatically perform a rescan/reload. However, if further lvars are created by the aircraft itself, or other add-ons, or using FSUIPC via other means (e.g. via calculator code)m then they will not be known to FSUIPC (or FSUIPC clients) until a rescan/reload is performed. I am nit sure how you (or Paul's dll) is creating lvars, but if you don't see them (after a short delay from creation, 20ms or so) then you need to explicitly ca;; for a reload - I am sure you can perform this via Paul's dll). John

All of the PMDG-specific offsets are read-only - as it says in the PMDG offset documentation: You can use offset 0x3110 to send the control if you like, but that is incorrect - writing to 0x3110 will trigger the control, and that offset contains the control number. Write the parameter to offset 0x3114 first, i.e. WriteFSUIPC($3114, 4, value); WriteFSUIPC($3110, 4, 70008);

Can you first check that you are not getting a crash in the FSUIPC WASM module - see If you list the lvars in FSUIPC (Add-ons->WASM->List Lvars) can you see the lvars you created? If not, try reloading and listing again (Add-ons->WASM->Reload & List Lvars) - does that work? This should hopefully determine if the issue is in FSUIPC or the WASM/WAPI, or an issue in Paul's WebSocketServer.

👍

👍

No, I wouldn't say that... The weather data is requested and received via SimConnect. As I said, I am not that familiar with the weather interface and I will look into this further when time permits and get back to you, but this may take a while...

Please find FSUIPC6 v6.2.2a which contains the same fix. John FSUIPC6.dll

Ah, yes, sorry - I can certainly do that...

No it can't - but you don't need to. You can just correct for this in the offset event handling function, and set the lvar to a value of 1 when the value if the simvar is > 1370, otherwise set it to 0 (as the calc,. code does). You do not implement any logic in the myOffsets.txt file. This only allows you to add simvars to FSUIPC offsets so they you can read/write/update them. The logic in how you use the values is encapsulated in the lua script that uses the offsets. So instead of this: ipc.execCalcCode("20 13 (>A:BUS LOOKUP INDEX,number) (A:CIRCUIT CONNECTION ON:20, number) ! (>L:CBL_BAT_RELAY)") in your offset event handling function for the simvar A:CIRCUIT CONNECTION ON:20, you would use: ipc.execCalcCode("20 13 (>A:BUS LOOKUP INDEX,number) " .. value .. " ! (>L:CBL_BAT_RELAY)") where value will be the value if the A:CIRCUIT CONNECTION ON:20 sinvar that is passed into the handling function. John

I can't see how I can fix this in FSUIPC - how would I detect such aircraft in the first place?

Well, its not coming from there either...can you show me / attach your FSUIPC4.ini file. Do you have controls disabled in FSUIPC4? If not, also check any assignments there. This assignment/control isn't coming from FSUIPC

I have done this now if you would like to try the latest beta (InstallFSUIPC7.4.18beta.zip). You can remove that new ini parameter with this version. John

Great! Yes, I am sure that would be helpful for others. Regards, John

No problem... Also, if assigned to a momentary button (as opposed to a switch or sticky-button) and you only want 2 controls to be sent, you can assign one control to the press and the other to the release.

You can do this by either: - using a macro (see documentation on macro usage) - overloading your assignments via editing the ini- this is described in many other support requests, e.g. That is for FSUIPC6 but the procedure is the same for FSUIPC7. - defining a preset to send both controls and assign to the preset For issues and questions on MSFS/FSUIPC7, please use the FSUIPC7 support sub-forum - I will move your post. John

I have just done some tests as well, and setting the same cloud layer at 3000ft to 6000ft I see this for cirrus: 750719 46208 Monitor IPC:CE80 (U16) = 975 750719 46208 Monitor IPC:CE82 (U16) = 914 750719 46208 Monitor IPC:CE87 (U8) = 1 which changes to the following when switching to cumulus: 822422 46208 Monitor IPC:CE80 (U16) = 2133 822437 46208 Monitor IPC:CE87 (U8) = 9 so I am seeing a bigger difference for the cirrus which is way off... Checking in P3Dv5 - the upper altitude for cumulus is even more out: 73906 44992 Monitor IPC:CE80 (U16) = 3469 73906 44992 Monitor IPC:CE82 (U16) = 914 73906 44992 Monitor IPC:CE87 (U8) = 9 and Cirrus give the same as P3Dv6: 212172 44992 Monitor IPC:CE80 (U16) = 975 212172 44992 Monitor IPC:CE87 (U8) = 1 Not sure why the upper altitude mismatches the P3D value at the moment... Update: a 3000 foot thick layer of cirrus is either not possible in reality or very highly unlikely. The cirrus layers are usually very thin. I’m not sure what P3D actually does when you tried to set such values. My logging suggests that this is being reduced by P3D, but you seem to be seeing the correct value, which is strange... Also I think the upper altitude is calculated, not provided, so may not be a 100% match with the set value. But I need to go through the code and look at what is being received to generate these values. As I am not familiar with this section of the code, this will take me quite a while. I will look into this further when time permits and get back to you, but this may take a while... John

Yes - only log files from the current and previous sessions are available. No need to post it unless FSUIPC actually crashed. As I said, it was most likely an exception due to the MSFS crash, and then FSUIPC7 would exit gracefully. Just look at your log file to confirm this, and only post it crashed, i.e. no closing log statements, like the following: John

It doesn't/can't.... Can you show me/attach the A320 Mode.lua script - it may come from this assignment: