John Dowson

This should be set as default. No. All folders/files are created by FSUIPC, you do not need to create anything. And profiles in separate files are only used when you set UseProfiles=Files Please see the document Profiles in Separate Files.pdf. Each profile will have an entry [Profile.xxx] where xxx is the name of the profile. Again, you do not create this - FSUIPC creates this for you when you create a new profile. In this section are the aircraft names that use the profile. You can have many aircraft using the same profile (and you should name your profile accordingly, e.g. TwinProp), but many aircraft (more so in MSFS than in previous FSs) will require their own profile, especially if using lvarsm hvars or presets/calculator code. Yes - this is also added automatically when you create the profile or add an aircraft to an existing profile. No - when you create a profile (or add an aircraft to a profile) the full aircraft title will be used. To match other liveries, you should edit the aircraft title (in this line in the FSUIPC ini file) to be a substring match to the title of the aircraft so that it matches different liveries. Otherwise you would have to add the aircraft again when using a new livery as the title would not match. There is also a new ini parameter called UseAirLocForProfiles which, when set, will use the folder name of the aircraft.cfg file for matching aircraft to profiles, which should catch most (if not all) aircraft when using different liveries. Please see the section on profiles in the User Guide, as well as the Advanced User guide for a description of the UseAirLocForProfiles parameter. John

Yes, this is what you reported. I was just suggesting to try 6.1.8 again to confirm. The problem only seems to occur in the latest ProSim beta as well, which also indicates its not an FSUIPC issue. Anyway, talked to Pete about this - he is aware of this issue and will check later next week.

I'm not sure about that - there are very few changes between 6.1.7 and 6.1.8 - only the following: - Bug fixed that prevented assignments to buttons with numbers 64 – 95 from being triggered - New functionality to allow the user to add any simvar to a free FSUIPC offset Looking at that link, this was your issue: I'm not sure how this can have anything to do with FSUIPC... Can you try 6.1.8 again to confirm please. As I don't have/use Prosim, I'm not sure what I can do. I'll see if @Pete Dowson can check this as he uses the ProSim 737 (probably later next week, after the Bank Holiday). John

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