John Dowson

You reverse in the calibration panels, not in the assignments tab. You can also do this by scaling the axis by *-1 (e.g. add ',*-1' to the axis entry in your FSUIPC7.ini, before the comment). Then also calibrate with No Reverse Zone.

Your log file shows an issue installing the auto-start component for MSFS2020: This is because your current EXE.xml file either has the wrong encoding, or is an invalid xml file. Try changing the encoding (you can sue Notepad++ to do this) or check the format. For further details, see As for the WASM not being installed, the community path looks incorrect: I do not know why that 'xtBoot' string is for...do you know what this is? Could you show me / attach your Usercfg.opt file for MSFS2024 - this: C:\Users\Dale\AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalCache\UserCfg.opt Is your Community folder specified correctly there? It is the InstalledPackagesPath at the end of the file. Did you just install the 'fsuipc-lvar-module' folder? That should work, but why don't you just copy the one from your MSFS2020 folder to the MSFS2024 folder? If the FSUIPC WASM folder is installed in your MSFS2024 Community folder, but isn't working, can you show me your FSUIPC7.log file and also your FSUIPC_WASM.log file (if present - see the WASM documentation in the Advanced User guide if you don't know where this is located). It could be the WASM is installed and working (you can check this in MSFS2024, using the Developer menu), but FSUIPC7 cannot detect it, again probably due to this strange 'xtBoot' string that seems to be coming from your InstalledPackagesPath. John

It has been found that the update of the EXE.xml (to add the FSUIPC7 auto-start entry) can fail when the EXE.xml file has the wrong encoding. The EXE.xml file must have either standard UTF-8 encoding or Windows-1252 encoding. Sometimes this file can be encoded in UTF-8 BOM (or maybe other character set encodings) which will cause the update to fail. If this is the case, change the file encoding and try again. Note that you can use Notepad++ to view and change the encoding used in a file. I have updated the initial post in this topic with this information. John

How have you configured the reversers? Please show me / attach your FSUIPC7.ini file so that I can see your assignments. Do the reverse levers use an axis or do they trigger buttons?

The separate throttle control axes are calibrated to give full reverse (when a reverse zone is enabled) at -4096 - from the user guide (section DETAILS OF MSFS’s AXIS CONTROLS on page 48): This should give you movement of the throttle through its full range in the VC as the lower range is taken to match the aircraft. If this was calibrated to -16384, the throttle in the VC would hit the bottom when your throttle axis hit -4096, and the rest of your throttle lever below this would produce no throttle change in the VC. John

sound.adjust takes a reference (returned from sound.play or playloop), not a device number. If its just a sound issue, create a simple lua to test the sound, i.e sound.path("C:\FSUIPC7\Callouts") ipc.log("Playing sounds on device 4: " .. sound.device(4)) ref=sound.play("2000",4) sound.adjust(ref, 100) ref=sound.play("1000",4) sound.adjust(ref, 100) ref=sound.play("500",4) sound.adjust(ref, 100) ref=sound.play("400",4) sound.adjust(ref, 100) ref=sound.play("300",4) sound.adjust(ref, 100) ref=sound.play("200",4) sound.adjust(ref, 100) ref=sound.play("100",4) sound.adjust(ref, 100) ref=sound.play("50",4) sound.adjust(ref, 100) ref=sound.play("40",4) sound.adjust(ref, 100) ref=sound.play("30",4) sound.adjust(ref, 100) ref=sound.play("20",4) sound.adjust(ref, 100) ref=sound.play("10",4) Then assign that to a button. Also test on other sound devices (you could make the device number a parameter, or wrap it in a loop to iterate over devices 0-6. Do you hear anything on any device? Also try setting a Log->Custom value of x20. This should add additional logging on sounds.

No, not needed if its now working. The issue must have been because the MCDU add-on is taking two many connections - its probably handling the connections badly, and requesting new connections before closing existing ones. The SimConnect.log file would show what is happening, but not really needed as its now working. John

You can turn off logging for IPC Reads - that is not needed. Your log files show that FSUIPC cannot connect when your Winwing MCDU addon is running. This may be because you have ran out of connections. What is the value of the maxClient parameter in your SimConnect.xml file? This file should be under [User]\AppData\Roaming\Microsoft Flight Simulator\. Try changing the value of this to 128 in all entries. If that doesn't work, then you will need to generate a SimConnect.log file so we can see what is happening to the connections connections. To do this, see Can you also show me a log file without IPC Reads logging set.

You can limit the range of the axis by manually editing the FSUIPC calibration entry. If you assign and calibrate the spoilers, then open and find the calibration entry: It will look something like this: You can decrease the minimum value and increase the maximum value to fool FSUIPC into thinking the axis range is larger than it is, and then the calibrated down to the standard -16384 - +16384 range. So, for example, if you doubled the top range: Spoilers=-16383,32768/16 the axis would only move half way through its positive range as your axis input value of 16384 would be calibrated to 8192.Try different numbers to get the range you require (change this when the FSUIPC axis assignments or calibration window is open, and click to reload your settings once the changes have been saved). John

I have looked into this further and the EXIT OPEN simvar is now deprecated in MSFS2020, and marked as legacy in MSFS2024. It may still work in some aircraft, but may not be reliable. It looks like you now have to use the INTERACTIVE POINT OPEN / INTERACTIVE POINT GOAL simvar(s) instead, and the key event TOGGLE_AIRCRAFT_EXIT / TOGGLE_AIRCRAFT_EXIT_FAST to open/close the doors. Both are indexed (I presume) either by door number or by the following: 0: Main exit 1: Cargo exit 2: Emergency exit 3: Fuel hose 4: Ground Power cable I have made a note to look into this further when I have time, probably at least not until November. John

SLC probably uses FSUIPC's doors offset, 0x3367. This is th ecomment on that offset: Take a look at that referenced post - this looks to be the same issue. You could try logging offset 0x3367 (as U8 in hex) to see if/how it updates both with and without GSX. Not sure if this is a GSX issue or an Asobo issue. If there is something else that holds the doors state when using GSX, perhaps some lvars, you could use these and write a lua script to spoof the reading of the doors offset to the correct value. I don't have GSX (or SLC) so I can't really look at this in details If you can log that offsets values for when using GSX and not, and can find something else that does hold the correct door state, I can show you how to use this in a lua to spoof the reading of that offset by SLC,.

It will be larger due to the additional logging. Try attaching here - if its too large, you can provide me with a download link somewhere or use one of the free file transfer services, such as https://filetransfer.io/.

By the way, what do you mean by 'cannot see the flight'? Does it connect to FSUIPC7?

Please use the specific sub-forum for FSUIPC7 for all issues / questions on this product. I have moved your post. There should be no issue running ,multiple FSUIPC7 clients at the same time - at least not with FSUIPC7. What happens when APL2 is running and can see the flight, and then you start your Wingwing MCDU add-on, if possible (whatever that is)? If its a WASM=based add-on, you won't be able to do this though. Can you show me your log files please, with logging for IPC Reads activated. Show me / attach two log files (FSUIPC7.log), one from when APL2 is running and working, and one from when both are running and it isn't working. Also please exit FSUIPC7 before attaching log files. Your attachment limit will be very low - you may need to compress/zip these files. John

@paddler Did you make any progress with this issue?

Please read the documentation, section Invalid Key Problems in the Installation and Registration guide You could also search for one of the several hundred other user reports on this issue... If you re-installed windows, your problem will almost certainly be that you need to install the required VC++ redistributables. See the documentation. John

Its not that difficult - and I gave you detailed instructions. What don't you understand? No I don't - I don't have the time for this. John

Looks like the latest security intelligence update (1.437.99.0) fixed this issue. John

Good to know, thanks. As this issue was only affecting assignments to virtual buttons, there is probably a better way I could have done this (as I do for standard buttons). I will look into this at some point. If I do change this, I will provide you with another exe to test, but it won't be for a while. John

I also submitted to Microsoft to get this rectified:

You should have an 'Actions' button there - don't know why it isn't showing...

You have to go into protection history and restore from there.

The uncompressed exe is also now getting flagged/blocked. I have reported to Microsoft. John

Allow it - its a false positive, as always....

Thats a better log and does show an issue.. When you profile is initially loaded, the input event is not known. The inputs events are received after the profile is loaded, but the loaded profile isn't updated - it is only updated here: and so after this, the assignment to the input event works. I am not sure what caused the profile to be reloaded here, but they are reloaded when you open/close the assignment panels, so that may be it. This also explains the double entries in the menu. When you see this, the input events are loaded (hence visible), but the input event is not linked to the button assignment, so another entry is added. Previously I was reloading assignments when input events are received from MSFS, but this was disabled as it could occasionally write an empty assignments section (basically removing all assignments), so ?i removed this. I have reenabled this in the attached version, and tried to correct the writing of an empty section. So please try this version, but also please take a back-up of your ini file(s), just in case (although you should have a back-up in your backup-ini folder, as inis are now backed-up on re-installation). Like standard events, some aircraft continually emit some inout events. You can ignore these by adding the following to your [Profile.C172_Carenado] section in your FSUIPC7.ini: DontLogTheseIE=VARIABLE_AMBIENT_LIGHT_UPDATE Let me know how it goes with this version, John FSUIPC7.exe