John Dowson

Its John - Pete retired over 5 years ago now. Glad its now working, Happy Christmas! Regards, John

If you get errors running the installer, it is usually due to not having the correct VC++ redistributables installed. See either the README.txt or the Installation and Registration document which both contain details on how to update these. John

I have moved your post to the FSUIPC7 support forum. There is nothing wrong with the installer. Try downloading the latest version (7.5.1) from fsuipc.com and try again. You should not do this, and also you should not install FSUIPC7 in such folders. Just unzip and run the installer from your Downloads folder. John

The only duplicate seems to be the X-56 Rhino Stick..do you noy have two of these? If not, then windows is reporting this device with two separate GUIDS: However, it is these entries that look suspicious: as the game controller (Afterglow Gamepad for Xbox 360) and MFG Crosswinds are reporting the same GUID. Are you using the fame controller in FSUIPC? If not, maybe a food idea to ignore this device... If using the JoyLetters facility (which is active by default), then all devices (device ids) will be mapped to a letter. If you want more details, see the provided documentation - the JoyLetters are explained in the User manual. I don't understand that ini extract you pasted as it doesn't correspond to the files you attached - there are no MFG Crosswind V2 there, probably due to the duplicate GUIDs. And your log file shows that they were acquired twice. Your log file shows that it was attached when FSUIPC was still running. Please ALWAYS exit FSUIPC before attaching any files. Your registry also shows some issues with some duplicated ids which can be corrected. Can you. please re-attach those two files, but after exiting FSUIPC, and also attach your complete FSUIPC7.ini file. Let me know which devices are working and not working and we can go from there.

If presets stop working, it is usually due to the WASM crashing. This is a known issue, and is caused by continua scanning for lvars. See this FAQ entry for details: With 7.5.0 and 7.5.1, this should be the default, i.e. LvarScanFrequency should be 0 by default in these versions. If it isn't, you have an FSUIPC_WASM.ini file in your WASM persistence storage area - remove that file or update there. If that is not your issue, I will need to investigate further. But this will be next year now as I am now on holiday until January, sorry. This is available in several other topics if you search, but I do not usally provide older versions. If you need to select a profile, this means that the aircraft you loaded was NOT already associated to a profile. This is almost certainly due to you not using substrings for your aircraft profile names. Are you aware of this, i.e. once you add an aircraft to a profie, you should then edit the name of that aircraft in the profile to use a substring that matches all variants. If you don't do this, using the same aircraft but with a different livery will NOT match the profile. Alternatively, you can use the aircraft folder to determine profiles, using the UseAirLocForProfiles parameter. Please see the provided documentation on using profiles, profile substrings and using that parameter. Otherwise, I will need to see your files showing your issue. You should ALWAYS attach files if you have an issue - your ini and log files tell me a lot for such issues. And pleas give a topic an appropriate title....

Presume you mean 7.4.17... And here I presume you mean 7.5.1... When did you add this - did you do it when FSUIPC7 was not running? If not, try again... This is the only change that can cause this issue, and adding that should fix it. This has been confirmed by several users. If that is not your issue, then I will need to investigate further. But I will not look into this until the New Year now. But please try again with this set to confirm.

👍

Looking at your log, when a Flaps Inc command is being sent, a Flaps Down control is also being seen: and similarly, when a Flaps Dec command is being sent, a Flaps Up control is also being seen: These additional up/down controls are NOT coming from FSUIPC, so they must be either coming from MSFS itself or somewhere else. Please check your MSFS assignments, and make sure you check both the General and Aircraft specific assignments. Also check the assistance options. I have checked a few aircraft here and do not see this, so it must be something in your MSFS settings. John

I have checked this here now and it looks like in both cases (i.e. when using FS Controls and when using presets) what is happening is that both controls are being sent, but the FS is only responding to the first control. I am not sure why this is happening, but really you shouldn't be sending the slow/small inc/.dec control when sending the fast one. To prevent this, add another preset condition in the slow control to be only sent when the trigger button is off, i.e. change: to John

Cam you please attach your FSUIPC7.ini and FSUIPC7.log file, the latter with logging for Events and Buttons & Keys activated and showing your issue, i.e. load an aircraft, activate the flaps Increment and then exit. Also check that the button is not assigned in MSFS2024..

Better to disable controllers in P3D completely, otherwise it has a habit of silently re-assigning them. So please first try with controllers disabled. If you still get the same issue, please activate logging for Axes Controls and show me / attach both your FSUIPC6.ini and FSUIPC6.log files and I will take a look. Note that I have now finished for the holiday season, but I will take a look at your files over the weekend when I find some spare time. Regards, John

I have finished now for the day (and year really!), but will take a look over the weekend when I have some spare time...

Please attach files rather than posting extracts... It is strange that I cannot see a button 2 press event logged, but the condition does change from false to true, and the control is being activated. The fast controls use offset 0x07D4 and set the AUTOPILOT ALTITUDE LOCK VAR simvar. If this is not working, then the aircraft doesn't use that simvar (or uses it in conjunction with something else) . Try assigning to the AS1000 presets instead, i.e. AS1000_AP_ALT_INC_100 AS1000_AP_ALT_INC_1000 AS1000_AP_ALT_DEC_100 AS1000_AP_ALT_DEC_1000

Try/start with the User manual. I provide extensive documentation do I don't have to answer such questions, and there are many on-line resources. And please don't hijack unrelated topics for your question - if there is no appropriate topic, pleas start a new one. John

The standard way to have both slow and fast inc/dec on a rotary is to use fast/slow buttons in each direction. Some rotaries do have two buttons in each direction for this, one for a fast turn and one for a slow turn. For rotaries that only have one button in each direction, you can use a lua script that can turn this one button into two virtual buttons, one for the fast action and one for the slow action. Such a lua script is included in the lua examples zip file (in your FSUIPC Documents folder) called Rotaries.lua. But you should also be able to do this using a button. If this isn't working, try using logging to work out what is happening - activate logging for Buttons & Switches and see what is logged (use Log -> Open Console to see the log in real-time). If you want further help with this, show me / attach your FSUIPC7.ini file, and an FSUIPC7.log file generated with logging for Buttons & Switches activated and showing both the slow and fast assignments. Well, you will still get the regular assignments unless you add another compound condition to these to only send when the activation button is not pressed. But what is probably happening is that you are using a momentary button and not a switch, so when you press it it is instantaneous, so when the rotary assignment is triggered it doesn't recognise the activation button as being pressed. If this is the case, then you should switch to using the button flag instead. See the section on using button flags in compound conditions in the Advanced User guide - here is an extract: John

What about in 7.4.18, the previous version to 7.5.0? There was a change introduced in 7.4.18 that could cause this: So, if using a 3rd party traffic injector, you need to set that ini parameter. This is the documentation for this parameter (from the Advanced User guide: John

Yes, very strange... I will be releasing 7.5.1 later today, and I am going to switch to using version numbers on the downloadable file which should help with this cache issue. Cheers, John

Ok, sorry I cant be of more help. And a Merry Christmas and Happy New Year to you! Regards, John

...and I will be releasing 7.5.1 tomorrow (only minor updates to help users with 3rd-party software using FSUIPC that hasn't been updated for MSFS2024) so maybe try that once released.

I don't understand this, unless you download from here (i.e. these forums) and didn't clear your browser cache, in which case the older cached version was downloaded. The download forums on this server will be removed soon, so you should use fsuipc.com. I will be moving everything to there, and support via Discord, over the next few months... Regards, John

Ok, I have corrected it there. But you only need to download that if not using FSUIPC7. Yes, I updated this after the beta, or maybe in the final beta. It will overwrite, but I think this was changed a day after the initial release, so if you downloaded early it would have had the old value. As I said, I think the initial release still had this set as -15. As this was causing issues, especially in MSFS2024, I decided to make 0 the default, but I didn't release/update the version number for this change. If this fixes the issue, could you post this on the IniBuilds forums so that anyone who has this issue can check that setting. I still don't understand how a WASM crash can cause the a/c to freeze though, very strange.... John

What website? Use fsuipc.com, as the zip file may have been cached if using the download links in this forum. I have checked the zip file again and it is definitely set to 0.

Yes, that is an error and will be corrected in the next release, sorry. The log file shows that the WASM crashed. Try disabling lvar scanning, see the following FAQ entry: Basically you just need to set the WASM ini parameter LvarScanFrequency to 0. In fact. the latest release should have this already set, but may be overridden if you have an FSUIPC_WASM.ini file in your persistent storage area. If you do, remove that or change/update there. I don't see how a WASM crash can freeze the sim though, unless the A300 is using the WASM... John

But you don't have to go back to the main menu to exit the sim - use the FSUIPC7 menu option MSFS->Exit

Then the log file should be here: AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\WASM\MSFS2020\fsuipc-lvarmodule\work i.e. under MSFS2020 not MSFS2024. There is an error in the document that I will correct. It will get created, as it is created when MSFS starts the WASM during start-up. However, if you kill the sim it won't exit correctly. No point in doing this.... Of the FSUIPC WASM module is installed, that folder will/must exist. You are just looking in the wrong place... The folder and log file will exist regardless of whether you use the WASM or not, if the WASM is installed.