John Dowson

The last log file you attached when FSUIPC was still running - please exit FSUIPC before attaching any files. Ok. The next time this happens, can you open FSUIPC and go to the axis assignment panel and see if your axis is recognized. Can you also check the USB hub settings (in windows device manager) and make sure 'Allow the computer to turn off this device to save power' is unchecked/disabled for all your USB hubs and devices. Also check if its a USB-2 device it is connected to a USB-2 port, and if its a USB-3 device its connected to a USB-3 port.

Could you please set a custom log value (Log->Custom) of x200000, also set logging for Buttons & Keys, and show me your log file and JoyScan.csv file the next time you get this issue. Also, please check your key assignment for this, and make sure you have checked No repeats!. It could be repeating which is causing issues updating the files... John

I cannot help with MobiFlight or Linda. FSUIPC will only recognize HID joystick type devices in the assignments panels. Your devices are HID but not "joysticks". The only way to assign to such devices in FSUIPC is by using the lua com library. This is what LINDA is using - LINDA is an interface to FSUIPC's lua scripting interface. A similar issue was reported several years ago, although using P3D - see Maybe try contacting that user to see if he has aby advice. Sorry, but I can't really help you any further with this hardware.

I really can't see anything in that video... can you please attach your files, your FSUIPC7.ini and FSUIPC7.log files. For the latter, please activate logging for Axes Controls, load your aircraft and move the throttle through its full range and back again, then exit before attaching the files. Normally such issues are because the throttle is assigned either to multiple axes or in multiple places. In MSFS2024, check that you have no assignments to the throttle in both the general settings and any aircraft specific profiles.

Can you please also show me / attach your FSUIPC7.ini file. Your log shows some issues with a lua script: Could you also attach that script please. If you exit FSUIPC and restart, does it then work or not? if not, can you exit MSFS and also attach your FSUIPC_WASM.log file. Then I need to see the log file from that session - the one you attached shows that FSUIPC exited normally, so I presume that was from a different session, no? So if one device stops working, does the other still work? Is it just assignments to presets/lvars that stop working, or all assignments? If you exit and restart FSUIPC, does it then work or do you have the same issue? Please supply further info, add/attach your log and ini files and check to see if the WASM has crashed or not (exit MSFS and check to see if the WASM exited cleanly or not in the WASM log file). John

Your log files also show an issue with one of your lua scripts that needs investigating: John

But the 7418 log shows that FSUIPC7 hadn't even connected to MSFS before it exited.... So it is working ok in 7.5.0? Was this with the Init3308 ini parameter added? I don't think so as you are using 7.5.0 - please try with the 7.5.1a version and use that - this ini parameter won't do anythung in 7.5.0, so you need to use the later version... This log file shows that when it is failing, the software is reading 0E (14) from 0x3308: The value 14 signifies MSFS20245. From the 750k version it is reading 0 (i.e. not yet populated): So it looks like it is the new value of 14 in offset 0x3308 that is causing this 'subscript out of range' issue. Really, the software needs updating to recognize this new number for MSFS2024. Failing that, you will have to manually set/change this number to 13 when set to 14. This offset is set as soon as FSUIPC establishes a connection to MSFS. So what you need to do is to change this value to 13 once 14 is written to that offset. It is not possible to update offset 0x3308 in the current version, so please try the attached version below, 7.5.1b, where it is possible to update this offset. To do this, create a lua script called ipcInit.lua and add the following: ipc.writeUW(0x3308, 13) If you do this, 14 will be written to offset 0x3308 when FSUIPC connects to MSFS2024, then the lua script will run automatically and change this value to 13. If the GSTEP software is started after the value has changed to 13, you should be ok. John FSUIPC7.exe

What antivirus software are you using? This will ne a false-positive, You need to either disable the anti-virus while downloading/installing, or add an exception to allow it to be downloaded and ran. You should also report this to the antivirus provider and they will check it and update their definitions. Note that this has already been reported for Kapersky:

From the comments this seems to be an issue with the FSUIPC WASM module and not FSUIPC itself, no? If you remove the WASM and just use FSUIPC, does it work? I don't know how FSUIPC could cause a plane to freeze, especially as the aircraft is not using FSUIPC or the WASM module. Is the WASM module crashing or exiting correctly with MSFS? Could you show me / attach your FSUIPC7.log and FSUIPC_WASM.log files from when this happens and after you exit MSFS / FSUIPC7. Also please activate WAPI debug level logging in FSUIPC7 (Log->WAPI->Debug) and also in the WASM module (via the FSUIPC_WASM.ini file). As you are a new forum user, you will have a very low limit for attaching files, so you may need to compress/zip them.

One more thing...if a button/rotary is calling a lua script very fast (or on repeat), what happens is that the first press compiles and executes the lua, but when the next press is received, if the previous lua is still being compiled or ran. then that thread is terminated and a new thread started. So what is happening when you turn the rotary fast is that each lua execution thread is being terminated/killed before it is doing anything. What you can do is increase the LuaRerunDelay ini parameter, which will give each lua execution thread more time to run before it is killed. The default value of this parameter is 66 - try increasing to say 200 (ms), to see if that improves things, and you can adjust up/down from there. John

FSUIPC's flight save/load functionality just calls the sim's functions to save/load the flight, and this in turn will also call the PMDG aircraft to save/load its state. There is therefore not much I can do about this,... One thing you can try, if not using already, is to also save/restore the FSUIPC offsets when you save the flight. To do this, look at the Miscellaneous tab option Reload FSUIPC data. Details on this option can be found in the User guide. Otherwise you should maybe ask about this on the PMDG support forums, as it may be an issue with the aircraft. I am surprised about this though as this aircraft has been around for quite some time. Maybe check if this has already been reported. John

Ah, yes...sorry, was thinking of MSFS and not FSX/P3D... Note that you can also call lua scripts with LuaValue by using offset 0x0D70. So if your script was auto-ran, you can send it the ipcParam value by first writing the value to offset 0x0D6C and then write "LuaValue <scriptName>" (where <scriptName> is the name of your lua script) to offset 0x0D70. But if I were you I would ask for advice on the best way to accomplish this to the MobiFlight folks, as I am sure there must be an easier way... I don't use MobiFlight so cannot really advise on this, but MF support is pretty good so try there... Cheers, John

But I thought MF has its own inteface to lvars - why don't you just use that? Or you can create a preset/calc. code to set both lvars, I can't help with MobiFlight though - you should ask about this in their discord server. Note they they usually tell people that you don't need to use FSUIPC if using MobiFlight with MSFS. There are two ways to do this: - use offset 0x7C50 - add the lvars that you want to update to spare/free FSUIPC offsets (via the FSUIPC7.ini file) and just write to those offsets John

So you are assigning in MobiFlight and not in FSUIPC? How was mobiflight starting your original lua script? Why don't you assign in FSUIPC rather than in MobiFlight? No, this is just not true. Many people are using lua scripts to control encoders perfectly fine with FSUIPC. But if assigning in MobiFlight I cannot help. If you are using MobiFlight, then why are you using lua? I don't know how (or why) you use FSUIPC's lua capabilities via MobiFlight, but I would recommend either using lua via FSUIPC or asking on the MobiFlight discord how you can assign to set lvars in MobiFlight without using lua - I am sure that is possible (using a presetm for example).

What do you mean by this? There are various different pause states (5 in all) - some controls work in some pause states, some not. The pause state indicator at offset 0x0262 whoulc indicate the current pause states: That will depend on the pause state, But FSUIPC is also a SimConnect application and if the sim time is paused then it cannot be changed, unless you are using the active pause state (possibly). I doubt this will be fixed by Microsoft / Asobo as it is not an issue. John

No - it is a free update. Id you gad previously registered, you do not need to re-register - just use the same key file. If you are installing in a separate location for MSFS2024, just copy across your FSUIPC7.key file from the MSFS2020 installation. For all installation and registration issues, please see the provided documentation, both the README.txt and the Installation and Registration manual. John

No, and there won't be any as MakeRwys is no longer supported: John

Yes, as each time the script is ran, it needs to be compiled first. It needs to be auto-ran, but you need to modify the script and assignments first. As you are using ipcPARAM, you could try: function setPitchBug(param) ipc.writeLvar("MJC_VAR_WRITE_VALUE", param) ipc.writeLvar("MJC_VAR_WRITE_CODE", 46987) end event.param("setPitchBug") Have that auto-ran, and change your assignment to use LuaValue <name-of-plugin> together with the parameter (if not using that already). Alternatively, you could remove the assignments in FSUIPC, and use the lua event.button function to handle the rotary buttons and then send the appropriate commands in the handling function for the button press/release event(s). John

Ah, sorry...misread that!

I would need to see the complete lua script to advise. But for performance issues, make sure the lua is always running, i.e. it uses the event library and is not compiled and started each time on a button/key press. Also, to improve lua performance, you should consider setting the LuaAffinityMask ini parameter to move the lua execution threads off of core 0/1. This goes in the [General] section and is a mask of the cores to use - if you are not sure what value to use, you can use this web page to calculate it for you: https://bitsum.com/tools/cpu-affinity-calculator/. For example, I have 6 physical cores, but really 12 as I have hyper-threading (HT) active. To move lua threads off of core 0/1, and use 2-11, I would set LuaAffinityMask=xFFC For rotary encoders that only have one button in each direction, you can also consider using a lua script that gives both fast and slow virtual buttons in each direction, so that you can assign larger inc/dec values on a fast virtual button. Such a script is provided in the example lua plugins. John

I don't expect you to tell me what to do! I need to see your log files....and also attach your FSUIPC7.ini file.

If its working on one PC but not on another, then I would have thought that this implies there is some difference between the PCs that needs to be looked at, not with the software itself...

I have rebuild this now with VS2022 and it will be updated in the next release. John

Is it working when running as admin or not? You said it was but later 'in fact doesn't work...' - why did you think it was initially working? There are no changes from 7.4.18 that should affect add-ons really, except for the change in offset 0x3308 which is what that latest beta version is addressing. Can you activate logging for IPC Reads and IPC Writes and show me the FSUIPC7.log file from both versions and I will take a look. Try and keep the logs as short as possible, i.e. start your software and when it fails or connects, exit FSUIPC7 and attach the logs here. Also any log files from the G-Step software showing the error may be useful. Ok. John

No - that parameter was added in FSUIPC5 and is not available in earlier versions of FSUIPC. John