John Dowson

To clarify, I suggest that you first disable the WASM (+ any additional logging) and fly like that for a while. If it crashes again, we know it isn't related to the WASM (and you can uninstall as not using, but up to you), and I can provide some additional logging flags to help track this down. If you are happy that its not crashing any more, I would like you to re-enable the WASM once again, and set Debug (or maybe Trace) level logging in the WAPI, and see if we can get more information from the log. I will also perform some tests here...

You again posted in the wrong support forum (what has your issue got to do with FSUIPC7, which is where you posted?) - I have moved your post for you. FSUIPC4 is not compatible with FS9 - you must be using FSUIPC3, no? Please note that this is no longer supported, although I can maybe try to help...you would attract other users that could possibly help if you had given your post an appropriate title... What is 'flightsimpm'? Have you tried their support? I don't really know what this means - what are those offsets? Why are you using those? Are you using Project Magenta? They are in the offset area for Project Magenta... I am also totally lost by your post, sorry. Please try and explain your issue more clearly, and attach your FSUIPC log and ini files. However, I think you need support for flightsimpm...or maybe Project Magenta if using that...

Yes, you are using the MobiFlight WASM module, not the FSUIPC one. You may as well disable the FSUIPC WASM - you can even uninstall it (i.e. opt not to install it the next time you re-install). But I would like to know why its crashing, so maybe keep it active for now... I would prefer the latter...but if we find something that avoids the crash, that should also help in identifying what is causing it...

Did you check the USB hubs? That is usually where the problem lies... Logging should certainly not affect anything...\ Looking at your initial crash log again, are you sure it crashed when returning to the main menu, not when starting another flight? I ask as this is where you stop the flight/return to main menu: and then around 5 minutes later a new flight is started: Maybe try with Extras logging only (turn off event logging), and set this ini option: StopWAPIInMenu=No If you still get a crash, you could try disabling the WASM to see if its related (if not using it) or activate Debug level logging in the WAPI if you are. Ok, but I don't think its a simconnect issue if FSUIPC is crashing... Lets see how it goes with this...if the problem persists, I may need to get a crash dump file from you to see what is happening... John

I've looked into this further and I don't think this is going to be possible... The problem with the win key shortcuts is that windows interprets them first and if there is a windows assignment then that is performed and the key press used is not passed on to FSUIPC, so it is not possible to assign a button press to this key press combination. However, you can assign to win+? key presses if there is no windows assignment to such a key press - but then, what is the point? However, it may be possible by assigning to the FSUIPC control Key Press & Release. I've just realized that I haven't updated these yet to use the updated shifts to handle the left/right modifiers for the shift, alt and control keys. I will look into and correct this, hopefully next week, and see if I can add another shift code there to allow the win key to be used as a modifier using that control (as well as the individual press/release controls).

I am not going to look into this further until that is done... FSUIPC receives controller input directly from windows, and then sends this to the sim as controls. It should report an error if there is a problem with simconnect. You could try activating the simconnect log file , and see if any errors are reported there. Are you using any other simconnect clients? Have you tried with those changes mentioned previously?

Why are you asking questions about SPAD.next in the FSUIPC support forums? Why not try the SPAD.next support forums? If you are using FSUIPC7 and have questions on that, please use the FSUIPC7 sub-forum. If using GF devices with FSUIPC7, you need the GFDev64.dll (available from www.fsuipc.com and the download section if this forum) in your FSUIPC7 installation folder. I will move this post to the FSUIPC7 support sub-forum. John

Use of the win key causes issues as it is reserved for use by windows. You cannot currently use this as a modifier for assigning key presses to buttons (or in key assignments). I surprised you need win+Y for this - according to the Microsoft documentation (see https://support.microsoft.com/en-us/windows/keyboard-shortcuts-in-windows-dcc61a57-8ff0-cffe-9796-cb9706c75eec), that is: Windows logo key + Y Switch input between Windows Mixed Reality and your desktop. You should be able to change this in windows, most probably with a registry edit. Try google... I could possibly allow this as a modifier for button assignments to key presses - I will check this. John

And it still displays the warning the next time you start FSX? If so, you should try the registry fix for this (in the FAQ section): John

Any available simvar can now be added to an FSUIPC offset - see the section Adding Simulator variables (simvars) to FSUIPC offsets on page 34 of the Advanced User manual. John

Strange - this works fine here and for many people, without issues. You have to do this BEFORE you start MSFS (of course...). Have you tried the MSFS Add-on linker - many people use this to manage the contents of their Community folder - seems to work well - I also use it occasionally but more often I do this manually. I find that it loads lvars for some aircraft just with having the aircraft in my Community folder (e.g. the FBW A320). I can get > 3000 lvars when I have several add-ons in my Community folder... But whatever works for you... Nor am I, very strange...

This issue has been reported hundreds of times now...please see one of the previous responses:

Then you must have installed the WASM 0.5.9 as well - this is installed with FSUIPC7, unless you manually uncheck this component during installation, in which case the log would report a WASM mismatch...

I can't see any indication of SimConnect issues in your log. When controls become unresponsive, this is usually due to windows putting the controller to sleep. Check the USB hub and device properties and make sure 'Allow the computer to turn off this device to save power' (under Power Management in device properties of Device Manager). Windows has a habit of resetting these settings on occasion.

Strange - I have no issues here...You did have an aircraft loaded and ready-to-fly (i.e. not in the MSFS menu) I presume... It seems that FSUIPC7 isn't receiving the lvar/hvar config data (which is why the menu items are disabled). You could try disconnecting and reconnecting yo see if that triggers the config data (do not enable/disable!). Could you activate Debug level logging in the WAPI and WASM and show me your FSUIPC7.log file again, and also show me your FSUIPC_WASM.log. Maybe also try with a different aircraft - although this shouldn't make any difference. I have done several tests here with various aircraft, starting FSUIPC7 with MSFS and also starting it after an aircraft is loaded and it is working every time.... John

Its John - Pete retired several years ago. Thanks for reporting back - as I said, you need the WASM enabled for the script as it is using an lvar. John

I will create a FAQ topic on this issue (when I have time) and put all relevant information there - there have been too many posts on this issue, which is why I am always repeating myself... John

It won't auto-start if you set it to admin. As I have said many many times now, if MSFS is not obeying the EXE.xml it is a problem for Asobo, I cannot do anything about this. You can switch to using the MSFS.bat method - see the previous posy I referenced. I really have nothing more to say on this issue that I have not said 10 times before...I am not going to repeat myself again, read the other posts.

Yes - the general method of doing this is to activate logging for events, open the logging console and then select/change the function in the cockpit UI and see what, if anything, is logged. If there is a control/event logged, that will also be in the drop-down menu and you can assign to that (also using the parameter that is logged). However, many aircraft in MSFS do nor use standard controls/events, and it gets more tricky... The first port-of-call, if no event/control is logged, should be the MobiFlight HubHob preset list (see https://hubhop.mobiflight.com/presets/) where you can search for available presets for many aircraft (both provided and add-ons). If there is a preset, then you can assign to that - FSUIPC7 comes with the MF presets, although the preset list may be out-of-date (but can be updated - see the Advanced User guide). If there are no events and no presets (currently available...) then it gets more complicated...you can try listing lvars to see if any look appropriate, otherwise you need to start looking at some of the aircraft' xml files to see how the function is controlled - this is how the presets are determined. I believe there is a MF video on this on YouTube, and there may be other resources.

If there are presets available then using those is certainly preferable to using lua...,I missed them in the preset list as they are called ANTISKID and not BRAKE... The lua script also requires the WASM to be enabled, as it is using lvars...

No, not with what you showed me... Can you activate logging for Buttons & Keys, Events and Lua Plugins. Then generate a log (full please, not a continuation) where you press each of your buttons assigned to the autobrake positions, in turn. Then exit FSUIPC7, and show me/attach your FSUIPC7.log, FSUIPC7.ini and PMDGAutoBrake.lua files. I will take a look at them tomorrow. John

Are you saying that FSUIPC7 cannot be started from the MSFS.bat file (when modified as indicated in the other topic I referenced)? If so, that is very strange....have you set FSUIPC7 to run as admin?

But the last entry in the log you posted is at 42344 - 42 seconds after FSUIPC7 started...

Did FSUIPC7 crash? I ask as the log is not complete...i If not, then you didn't wait long enough (what is your LvarScanDelay set to?) - the log ends after 42 seconds and the lvar/hvar data has still not been received in FSUIPC7 from the WASM. Maybe try initially without LINDA...

Your EXE.xml looks ok - if it is in the correct location for your installation then I have no idea why MSFS is not using that file and starting your add-ons. But this is an MSFS issue and I cannot help with this - you need Asobo / MSFS support. It seems that quite a few people are having this issue, but there is nothing I can do and nothing I can say that I haven't said already. You should raise this with Asobo, and you could also go back to the old method of starting FSUIPC7 via the MSFS.bat file. Please see that link I posted in my previous comment for details. You can also modify to start your other add-ons.