John Dowson

Not for me - there is nothing I can do about this - it is (obviously?) an MSFS issue, and nothing to do with FSUIPC. I really don't understand how add-ons in the Community folder can affect the functionality provided by the EXE.xml file. I suggest you raise a bug with MSFS/Asobo and report your findings there, as it is they who need to look into this. Cheers, John

I have nothing more to say on this matter that hasn't been said already. If auto-start via the EXE.xml isn't working, just use the MSFS.bat method to start FSUIPC7 or start it manually.

So try 0x6B (or 107) for +, and 0x6D (or 109) for -. John

No sorry, I was mistaken in this. I added support to send left/right ctrl & shift, but not for assignments. This was implemented to support assigning button/switch assignments to key presses assigned in MSFS (as some controls only work in MSFS, such as camera controls). It will be very difficult to add support for left/right shift/ctrl/alt as currently I only allow 1 byte (8 bits) to handle the modifier key, and 7 bits are already taken/used - from the User manual: So you can only have a maximum of 1024 key assignments. There are around 80 (rough guess) non-modifier key codes, so with the 6 (or maybe 5) modifiers currently provided, that allows for around 480/400 distinct assignments. Do you really need more than this? Another issue with switching to left/right modifiers would be in handling existing assignments, which I would need to think about... So, all-in-all, I don't think this is going to happen, at least any time soon. It will be a lot of work for little benefit, as far as I can see. There is a lot more additional functionality that would be more useful for most folks, so I won't be considering this for the time being. Sorry about that. Regards, John

I do not understand the term sketch in your question, but please read the document FSUIPC Lua Plug-Ins.pdf (which will be in your FSUIPC documents folder, under your Windows Documents folder). Extensive documentation is provided so that I don't spend all day responding to such questions - please check the documentation (and existing support requests - most questions have been asked before...) before requesting support. John

Why are you asking about FSUIPC7 auto-start in a thread that is titled 'WideFS failed to connect'. There are now numerous threads about FSUIPC7 not auto-starting with MSFS, and i have said everything I can on this topic. Please check the support forum for similar issues before posting. Please see: John

That is because this is not relevant to auto-start. Check that you have not set FSUIPC7 to run as administrator, check your installation location, and check the permissions on the FSUIPC7 installation folder. Please see John

Just tun the script only for the FBW A320. Are you using profiles? If not, you should, as this is the mechanism to have different assignments for different aircraft. You need to auto-start the lua from the profile [Auto.xxx] section (where xxx is the profile name) rather than the [Auto] section that will be used for all aircraft. If you do nor know what profiles are, please read the user manuals... John

Then you have either assigned incorrectly or there is an issue with your hardware (possibly the axus are registered as digital on/off axis). Please attach your FSUIPC7.ini and a full FSUIPC7.log file. for the latter, you need axis logging activated, and with the aircraft loaded activate each toe brake through its full range and then exit - you can zip the log if it is too large to attach as-is. John

Do you mean by sending a key press using the Key Press & Release / Key Press/hold & Key Release controls? If do, the parameter will be the windows virtual key code - see https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes For +/-: VK_ADD 0x6B Add key VK_SUBTRACT 0x6D Subtract key A link would have been useful! John

I thought I had added support for this a while ago (except for alt - I think I removed this as using the alt key can cause issues), but I will check...

No problem 👍

Also a good idea to remove the comments from the delay/timeout line as MSFS takes such a long time to load: :: wait for MSFS to start (2mins) timeout /t %delay% /nobreak > NUL John

Its an issue due to the interaction with OneDrive in windows 11 (and maybe other cloud-syncing services). Yes, I don't doubt it. What surprises me is that this issue seems to be happening when an FSUIPC7 folder is created outside of a windows protected folder for some people. I guess this can still be due to permissions based upon individual users condifurations, but such things are difficult for me to diagnose... Yes, seems ok here as well (although I have had an occasional CTD...). Thanks for your input. Regards, John

You should only need one profile for all FBW liveries. Check you are using substring matching to the aircraft (not based upon the livery). You can also switch to using the aircraft.cfg folder name for matching profiles using the UseAirLocForProfiles ini parameter. John

This isn't possible with the current implementation as all lvars are passed from the WASM to FSUIPC7 as a list/array, with the position being the if of the lvar. If I don't pass all lvars, I would also have to pass the lvar ids. This would be a major change which I certainly won't be considering at the moment. I could do this. I am having a break from new development at the moment to catch-up on other things, but I will add another CDA (or 2) for lvars in a future release, maybe in a month or so. There are a few other things to consider/try. Lvars are loaded for many aircraft that are in your community folder even if not being used. which can reduce the number of lvars available for the aircraft that you are actually using. Try clearing your Community folder to contain only the items you are using for each flight. Many people use the MSFS Add-on Manager (a free utility) to do this. Also, even if lvars are not known to FSUIPC7, they can still be used in Presets (or in calculator code). So you can create presets to use the lvars which are out of the 2044 range. However, you cannot get the value of such lvars (or add them to FSUIPC offsets). You can, in the preset calculator code, check the value of the lvar and change it or send a control based upon the value (as many of the MF presets do). John

Did you remove the comments so that the bat file starts FSUIPC7? I cannot see how that fails to start FSUIPC7...it is just a standard bat command to start an executable... Are you using an MS Store installed MSFS or a Steam version? I'm on Steam and have no issues here. If it was an issue with SU9, I would have expected a lot more reports of this issue.

Sorry, seems you have already tried that... If the FBW A320 spoofing script isn't running, I have no idea why this is not working. Show me your FSUIPC7.ini and a log file generated with logging for Events activated and also logging offset 0x0bc8 where you activate and de-activate the parking brake. John

I have just checked this in a couple of aircraft and the offset is working fine here. Check that the lua spoofing script for the FBW A320 isn't running for other aircraft as this will result in the value always being read as 0 as the lvar used by the FBW A320 will not be available for other aircraft. The script should be running for the FBW A320 only, and so either started manually for that aircraft, or via an [Auto.xxx] profile section used by that aircraft only. If thats not the issue, try logging offset 0x0BC8 (as U16) and see if the logged value changes. John

How have you assigned your lever - in P3D or in FSUIPC? To what control have you assigned the lever? You can try assigning the axis in FSUIPC 'Send direct to FSUIPC calibration' to both the LeftBrake and RightBrake controls, and then calibrating both.... John

I've updated now and still all ok here. I also updated to SU9 (v1.25.7.0) and auto-start is still working. Another user who experienced this issue has found a solution that works for him - see Maybe check that you have not set FSUIPC7 to run with Admin privileges... John

Do not install FSUIPC in a windows protected folder such as under ProgramData, Program Files or Documents. Installing FSUIPC in such folders invariably creates issues. I have just updated to SU9 (v1.25.7.0) so I don't think that this can be an issue - unless it was present in the beta and has now been fixed. Thanks for the info though - quite a few people are experiencing this issue, and it may help them... John

I don't think this can be an issue, but I am still on 21H2 22000.651. I am updating to the latest update (KB5012643) now and will check... Why do you think that? The FSUIPC7 and the WASM module are two distinct components. When you start FSUIPC7 manually does it connect to the WASM (e.g. can you list lvars)? If so, the WASM has started with MSFS, it is just that MSFS is no longer starting FSUIPC7 from the EXE.xml. I have no idea why this is now happening for a few people. All I can suggest is that you go back to the old method of starting FSUIPC7 directly from the MSFS.bat file. See the link I posted above on how to do this. John

First, you posted in the wrong sub-forum. Please take care to post in the correct forum. What aircraft are you using? If using the FBW A320, you need to use an lvar and spoof the offset to the lvar value, as we already discussed in this thread: If its not the A320, but some other aircraft that is not using the standard SDK simvar, then you will need to determine what is usedm get that into an offset and spoof the offset again. Is this any different from last time this was reported?

This post is old now - I have only just seen this as it was posted in the wrong sub-forum. Hvars are only visible to FSUIPC if made known via *.hvar files. Please see the Advanced User guide. John