John Dowson

Yes...is the speed an issue, or is the problem with the parameter being lost for the first call here: You are sending two different parameters to the same script at the same time, so it looks like the second is overwriting the first before it is processed (they are global parameters/variables). I'm not sure if I can do anything about this but I'll take a look (may take a few days to get around to this).

No, that doesn't matter. Did you change the stall parameters as suggested. Did you not see any stalled warning messages (or re-connects)? Maybe activate Extras logging as well. As well as finding out what clients those ids refer to (as suggested by Pete), you should also look for and count any connection closed and open messages, which will be when clients are re-connecting. That would be interesting to know. The start of the log file should show you the format of the open messages - just extract all of those from your log, together with any close messages. John

Are you using the lua script to use the buttons outside of the 32 button limit? Have you tried using the lua script for the Bravo? See and this may also be of interest: John

They should be under %LOCALAPPDATA%\CrashDumps. However, you may not have application crash dumps activated. If not, you can activate (either for all or just for FSUIPC7) - see https://www.meziantou.net/tip-automatically-create-a-crash-dump-file-on-error.htm. Then. of/when it occurs again, send me the crash event report, the dump file and the FSUIPC7.log file. Thanks, John

I'll check with @Pete Dowson but I don't think we can do this as then we would either have to install the required lua.dlls with FSUIPC, or put a requirement on the user to install these if they want to use lua. Can you not include the lua core in your dll and just dynamically link to the one in the FSUIPC6.dll?

I would do as Pete says, but first delete your current profile (its empty) and start again. When you create a profile (best to do this in the axes assignments section first), you must either import the [General] axes first (a pop-up will ask you this) or add at least one axis assignment before you close. Otherwise you will have a profile created and no axis section which can cause issues later when trying to add/edit axis assignments for that aircraft.

So the crash was with FSUIPC7 - did MSFS crash or did it keep running? Can you show me your FSUIPC7.log file (from when the crash occurred), and was there a crash dump file produced? The event log does show it was an FSYUPC7 crash, which is the first I've seen - usually its MSFS that crashes. As the crash is in the ntdll.dll, I would need the crash dump file to investigate. John

Yes - the MSFS SimConnect documentation states: Internally, not all events are mapped to the relevant SimObjects. i.e. not all sim events are currently working. So it looks like those sim events are still not connected for that aircraft. You should report this to Asobo via zendesk. Hopefully there will be lvars (or hvars) as alternatives for such events at some point as well, maybe before these are fixed by Asobo.

Can you also please post your ini and log files again for both installations. I need to see these each time you make any changes. It should not have showed a 'missing C joystick' if you had made the changes that I suggested (there was no C joystick!) rather than those of Masterius. You problem with the parking brakes on P3Dv5 was that it was assigned to a device with letter A, which had changed GUIs and was -re-registered as device C. The changes I proposed would have corrected this. But now its probably better to show me your files again and we can go from there.

The auto-start feature, which updates the MSFS EXE.xml file so that MSFS starts FSUIPC7, is optional since the v6.0.12 release. Re-run the installer and de-select the auto-start component. In versions prior to v6.0.12, the FSUIPC installer provided an optional desktop-link that wouls show a splash screen, start MSFS and then start FSUIPC7 30 seconds later. In the latest installer, the desktop link is still provided (optional), but this only now shows a splash screen while MSFS is starting - it no longer starts FSUIPC7. John

Ok, thanks for the update.

Yes, its a separate purchase/key. It will be blank unless you enter a key there. You don't need to purchase both each time. WideFS7 is compatible with FSUIPC4, FSUIPC5, FSUIPC6 and FSUIPC7. You just need one key to activate in each/all versions. That depends on your set-up. If you have FSUIPC clients running on a client PC (i.e. separate from the PC running the FS and FSUIPC), then you need WideClient running there and the WideFS license registered on the receiving version of FSUIPC. John

What version of FSUIPC are you using? There was a fix in FSUIPC6 v6.10.12 relating to the timings for repeat button presses (both real and virtual). This update has now been applied to FSUIPC5. If you are using that, I could apply it there to see if that helps.

You can try as @Masteriussuggests (except edit as below), but that may not work either - sometimes you need to edit the registry to remove such entries. However, they are only warnings and not important - they won't have anything to do with your issue. Your Parking Brake isn't currently working as your 'A' device is missing. Changes the [JoyNames] section to the following:

First, you posted in the FAQ sub-forum, where it explicitly states (in several places) NOT for support requests. Please take care to post un the correct forum for future posts. We do not support x-Plane. Thats xpuipc by a different developer. FSUIPC7 is the version of FSUIPC that works with MSFS. and is a different product to FSUIPC5 and requires a separate license, available from SimMarket. A discount is automatically applied for FSUIPC5/6 license holders at checkout. FSUIPC supports all HID joystick type devices for assignments via its UI. For other HID devices, you can access via the lua com library

Why? Your ini and log tell me a lot more than a video can. I rarely watch videos for support requests - they are not needed except in exceptional circumstances (and don't have the time!). We prefer a decent description + log and ini files. You can do. Make sure to reload assignments if FSUIPC is running. Otherwise, you can clear it from the axis assignments panel.

Probably because its assigned to two axis - most likely one you are also using (assigned in P3D) to the rudder: Try deleting one of those - probably 2.

Keyboard input is received from MSFS via SimConnect as key input events, when MSFS has the focus. Commands are sent back (usually) as events also via simconnect. When FSUIPC has the focus, it receives the key events as windows messages. Yes, that would be the case when MSFS has the focus. See if there is a difference when MSFS has the focus vs when FSUIPC has the focus. John

Yes, your registration details for FSUIPC4 will be valid for all versions of FSUIPC4, and the same for WideFS7. The latest version of WideFS7 is 7.156.

Yes. If P3D/FSUIPC6 is running, you will not be able to run/start FSUIPC7, and vica versa, so if FSUIPC7 is running you cannot start/run P3D. Yes. Its not that complicated. You can have as many different FSUIPC installations as you like (same or different versions), but only one can ever be active at any given time. I wouldn't worry about it. Just download FSUIPC7, install it and try it out. Note that FSUIPC7 can also be auto-started with MSFS, but as a separate application.

No, its a simconnect.xml that you need to change, the MaxClients parameter - see https://www.prepar3d.com/SDKv4/sdk/simconnect_api/configuration_files/configuration_files_overview.html. You could also try temporarily changing this line in your ini: TrafficStallTime=1 NormalStallTime=1 to TrafficStallTime=-1 NormalStallTime=-1 This will instruct FSUIPC to just log a message when data is stalled rather than closing the connection and re-connecting (this saving a connection). However, if the connections really are closed, then you will stop receiving data. With this change, you can checj your logs after a session and see if the data was stalled at all during the session. If so, you can determine how long the maximum stall was (with a setting of -1, it will log a message every second that it does not see data), and then set the parameter back to a positive number. i.e. if you find that you were getting a maximum of 3 messages logged, then set the NormalStallTime to 3 (meaning it will then attempt to re-connect after 3 seconds of not seeing data). But if your maxClients is high enough, you shouldn;t need to do that, so try adjusting MaxClients first.

FSUIPC7 is a completely different product, for MSFS only, and does not replace FSUIPC6. There are no problems having both installed, but you can't run both at the same time. FSUIPC7 is also a stand-alone application (whereas FSUIPC6 and earlier were dlls/library plugins to the FS) and should be installed in its own folder. You can also download and install the unregistered version to check for yourself.

What was it?

Such crashes are usually caused by a corrupt or missing weather file, usually the wxstationlist.bin file. To check this, can you delete this file from your Prepar3D AppData\Roaming\Lockheed Martin\Prepar3D v4 folder (if it is there) and check that it exists under your Prepar3D v4\Weather folder (don't delete that one!).

No. Thats expected - it will get very large. There is no point in posting any log if you haven't experienced the issue yet. And I am certainly not interested in seeing a log that big! To see if its a simconnect issue, you need to search the file to see if there was a simconnect error that occurred at the time you lost control. search for the string 'error' or maybe 'i/o error'. If you find one, then you then search and count the number of client connections/disconnections, as that is known to be an issue. Did you increase the maximum number of clients allowed for SimConnect? Also, check you FSUIPC6.log file to see what errors were reported, and also if there are any messages relating to stalled data or reconnection. You can also count the number of client connection/disconnections logged, to see if that is the issue. If it is, there isn't much you can do except to try and prevent clients re-connecting. Maybe show me your FSUIPC6.ini file to see if we can change the stall-time/reconnect settings to see if that makes a difference.