John Dowson

For controls, you should start with the standard controls, not offsets. For example, the standard control for AP altitude hold would be the AP Alt Hold control (65726). Note that the standard way to determine what control to use is for any button or switch to set logging for Events (Log->Events), open the logging console (Log->Open Console) and then toggle/set the switch in the virtual cockpit and see what is logged. If anything is logged, use that. Note that many MSFS aircraft continually emit certain events, and these are different for each aircraft. These can make using the log difficult, so best to ignore these by setting the DontLogThese ini parameter (see the Advanced User guide for details). Many MSFS aircraft, especially third party/add-ons, do not use the standard controls/events. For such aircraft, check to see if an MF preset is available - you can use the search interface on the MF HubHop site: https://hubhop.mobiflight.com/presets/. All MF presets should be available for use in FSUIPC7. Some aircraft also use their own custom controls (e.g. PMDG, FSLabs, etc). For such aircraft, check the documentation - and there is a FAQ entry on using custom controls with PMDG aircraft. If there are no standard events, presets or custom controls that work, you can look at the available lvars or preset events, or examine the switch/button behavior to see what it is using - see the following article: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ If you require any further help, please let me know the aircraft you are using. John

Listing lvars shows the currently held value by FSUIPC, which is a max of 166ms or so out of date (using the default update rate of 6Hz). There is already a facility to log lvar updates, either to the log or a separate ext window. This is done via an ini file section (at the moment) - see the Advanced User guide. John

There may be an lvar that you could use - try listing them to see if any look applicable. John

Just received further information: if you press tab to check and nothing happens, this means the mouse macro facility can't be used. The whole thing about mouse macros is that it’s all a code hack, especially in FSX, and some parts of the FS code just aren’t constructed in the manner where they do work. The test offered at the creation phase is to check that, and if it doesn’t work other methods have to be used to action the function desired as mouse macros won't work. A lot of later add-ons did not use the original library-provided methods for implementing their controls. And that is where the problems are, and there is nothing that can be done in FSUIPC to get around this John

No point attaching images - they don't tell me anything that you have not already told me. Did you try my recommendations? Maybe also leave the Module line in as it looks like this is needed (although I have never seen this before!). I have never seen parameters 23 and 24 used before - I though these should be in the 1-17 range, as the documentation states. But if it doesn't work, there is not much I can do about this. FSUIPC4 has been closed for further development for many years. And I don't have much experience with FSX and certainly don't have the dodosims 206, which also doesn't seem to be available anywhere either. My PC has also now died after the latest windows (insider) update, so cannot do anything at the moment or until I have sorted this out... Sorry I can't be of more assistance. John

The log you attached shows that FSUIPC7 did not connect, and was still running when you attached the log file. Please ALWAYS exit FSUIPC before attaching files. And please leave FSUIPC7 running at least until MSFS arrives at the main menu. Your issue is almost certainly due to the auto-start parameters not being tuned correctly. I cannot advise what to use with that log file you attached for the reasons already stated. Try tuning the auto-start parameters yourself (see the documentation or that FAQ entry I referenced) or provide me with a better log file and I can advise what to try. Also check your EXE.xml (location is logged in the InstallFSUIPC7.log file if you don't know where that is. If there are multiple entries for other apps, then you can also try making sure FSUIPC7 is started first. You can also attach this and I can take a look. John

The logging I requested would just confirm that the auto-brake threshold wasn't being used, but I think that was added in a later version of FSUIPC 7 than the one you are using anyway. You should update to the latest version of FSUIPC7. John

Did you not read my previous comment: You are not using an airbus, so this parameter has no effect. If you want to mimic this in airliners, then you would need to use a lua script. Note that you are using a very old version of FSUIPC - 7.4.17. I only support the latest release, which is 7.5.3. Please update if you require further support: You need to set the logging flags then exit FSUIPC and let MSFS auto-start it, as then I can see/check the logging. John

Looks like you are using the PM 737. The brake release threshold is only applicable to airbuses, as these are the only aircraft that use this brake release mechanism (although I see in the documentation that this is omitted!). Try setting the logging for Extras before the aircraft is loaded - this should then log a message indicating if the brake release threshold is applied or reset. John

Ok, that makes more sense then, and it will be because FSUIPC is not connecting to the FS. The log file should reveal why. John

What has changed? Can you show me / attach your FSUIPC5.log file showing this issue. If there are any log files from Pegasus, please also attach them. John

Did anything change to cause this issue? If it was an FSUIPC update, and you were previously using was pre 7.5.0, then it could possibly be due to the late population of offset 0x3308 that was introduced in v7.5.0, which is needed for compatibility with MSFS2024. If that is the issue, you can use/add the ini parameter Init3308 in the [General] section of your FSUIPC7.ini file to to 13, eg. Init3308=13 Otherwise, this is usually due to the auto-start parameters that need tuning. This is described in the Advanced User guide, or in the following FAQ entry: If you can show me/ attach your FSUIPC.log file when FSUIPC7 is auto-started and your clients won't connect I can take a look. Btw, I don't think Track IR needs or uses FSUIPC these days (if it ever did), although I don't have this for MSFS2020. John

That is strange - I don't know how that could get there... What are the mouse operations that you need? Was it a middle-single (2) click together (or followed by) with a left single click (3)? Even then, that should be: [Macros] 1=Warning mute 1.1=RX746f0*X55cc,2 1.2=RX746f0*X55cc,3 2=DIR GYRO 2.1=RX79ee0*X55c3,2 2.2=RX79ee0*X55c3,3 They will only work in whatever view they were created in (otherwise the mouse-rectangle will not be available). Ok. Cheers, John

What aircraft are you using? Can you please set logging for axes controls (Log->Axes Controls), Events (Log->Events) and Extras (Log->Extras) and show me/attach your FSUIPC7.log file showing the issue. Try and keep the session as showrt as possible - just load the aircraft, replicate the issue, then exit FSUIPC7 before attaching the file. John

This is your mouse macro file: [Macros] Module="DodoSim206.gau" 1=Warning mute=RX746f0*X55cc,23 2=DIR GYRO=RX79ee0*X55c3,23 There are two issues: - the line starting 'Module...' is invalid - why is that there? - 23 is not a valid mouse flag value. Valid values are 1-17 (see the documentation). Did you edit this file? What mouse operation is required on these button in the VC? If just a single left click, try: [Macros] 1=Warning mute=RX746f0*X55cc,3 2=DIR GYRO=RX79ee0*X55c3,3 If its a press and release, try: [Macros] 1=Warning mute 1.1=RX746f0*X55cc,3 1.2=RX746f0*X55cc,13 2=DIR GYRO 2.1=RX79ee0*X55c3,3 2.2=RX79ee0*X55c3,13 If it requires some movement, try: [Macros] 1=Warning mute 1.1=RX746f0*X55cc,9 1.2=RX746f0*X55cc,13 2=DIR GYRO 2.1=RX79ee0*X55c3,9 2.2=RX79ee0*X55c3,13 etc Use the mouse operations required on the switch. John

Sorry but I dont understand why you ate now talking about events. I thought your issue is with nouse nacros? Note I am on holiday now, back on Monday. In the mean time, why not try what I have advised, i.e. rather than sending a single left mouse press, try sending both a press and release, or a press-and-drag and release.

No this is not possible (FSUPC7 is a distinct application). The only thing I can advise is: 1. Check the MSFS console - if you see excessive logging there then that could be the culprit 2. Check the Asobo forums for similar issues I would suspect MSFS server issues. You can try and disable some online services (AI traffic, weather) to see if that improves things. Sorry I can't be of more assistance, John

Presumably the mouse macro is being called? You can verify this by logging Buttons & Keys and checking the log. If the macro is being called but is not working, it could be that you need to manually modify/edit the mouse macro to either add a button release (the macro will have only recordeed the mouse press), or change the press to a press-and-drag and also add a release. This is similar to what I explained in this post: So try modifying the macro - if you can post/attach it here I can take a look and adjust it for you. John

Yes, that is the brute-force method, but you will have lost the auto-start of your other entries: FenixBootstrapper AFCBridge IVAO Pilot Client Couatl FSRealistic SimHaptic That is why I didn't recommend that. If you also want those auto-started, try that last EXE.xml I attached (or add the entries for them back into your current EXE.xml). John

Yes, sorry - there is something very strange with that EXE.xml. I have re-written it - try this one: EXE.xml You should be able to uninstall/re-install with that one. John

Sorry, but what issue with uninstall? It maybe the same issue - problems loading your EXE.xml. I have just tried with your EXE.xml and I can see the issue - never ending messages updating the EXE.xml. I will take a deeper look...

There was a problem loading your EXE.xml for both MSFS2020 and MSFS2024: I am not sure why the installer couldn't load your EXE.xml as it looks ok - this normally happens if there is an xml syntax issue in the file. You can add the FSUIPC7 entry manually: <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path>D:\FSUIPC7\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> I have added it for you in the attached MSFS2024 EXE.xml. John EXE.xml

No problem! John

...but this shouldn't apply when using presets/calc code as that is executed via the Gauge API, so I don't understand this either...

All FSUIPC log files can be found in the FSUIPC installation folder. The location of the EXE.xml file is also logged in the InstallFSUIPC7.log file, but I see you have found and attached that. Well, FSUIPC7 will not auto-start as there is no entry for FSUIPC7 in the EXE.xml that you attached. Did you install the auto-start component, and if so which one? Re-run the installer and leave all the settings as-is, then try again, and if you still have issues please show me the InstallFSUIPC7.log file - I need to see this to diagnose any issues. John