John Dowson

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

You can use the ini parameter DontLogThese to ignore those, best used in your profile section. See the Advanced User guide for details on this ini parameter. Yes, strange, However there is an issue with some external controls in that they don't work in the same manner as the internal one. This has been reported to Asobo (a long time ago), but I guess it has not yet been fully addressed. Is there another lvar that holds/controls the light state? If so, you could try using that.... John

Also, for any/all auto-start issues. please see the following FAQ entry: John

You should only use the direct SteeringTiller axis if you want to blend with the rudder (and then assign to the same axis as rudder) If you are using separate axes and don't want any blending, you can try assigning using 'Send to FS as normal axis' and try either the Axis Steering Set and Steering Set axes. You can still calibrate. Axis Steering Set seems to work fine in the longitude. Also no issues if you want to bind that axis in the sim.

So it installed ok after the reboot, including updating the EXE.xml? If FSUIPC7 is not starting with MSFS, then its most likely an issue with your EXE.xml. Please show me/attach that file, together with your InstallFSUIPC7.log file and I will take a look. Note that you should run MSFS at least once after re-installing and before installing FSUIPC7. John

Ah...I think you are misunderstanding FSUIPC's rudder/tiller blending facilities. These are intended to be used when both the rudder and tiller are assigned to the same axis. It doesn't make sense blending these if separate axes are used as there are already separate values for rudder and tiller. That is strange - it should show the deflection that you apply (once calibration has been applied)....

Can you please set logging for Axes Controls, and also log offsets 0C08 and 0C0A, both as S16 (and log to normal log file) and show me a FSUIPC7.log file. Thats strange - I will check this. Note that you have a profile-specific calibration section for the DHC-4 - were you looking there? It is still set to Q in the ini you attached. Strange that the first image you posted shpws the general calibration section though, and not the profile-specific one. Did you make this profile-specific after attaching that image? I don't have the DHC-4, but I will check this in another aircraft. You should also consider changing your aircraft names in the profiles to use substrings, so that they catch mpre variants. e.g. change to and update the other aircraft names in your profile sections to use substring matching. John

WideClient does not transmit axes data, only buttons. This is because the overhead/lag on axes connected to a client PC makes them basically unusable. You should connect your throttle quadrant to the FS PC (the server). John

Maybe the lvar is only controlling the visuals? If thats the case, then something else may be needed to control the actual functionality (and sound). I don't have this aircraft so cannot look into this. There are a few things you can do: 1. Use FSUIPC's logging facilities, and log Events and Input Events. What do you see logged when setting the autobrake with the mouse, and is this different than when using the preset? You can check this in real-time by opening the logging console (Log->Open Console). 2. Inspect the code of the autobrake switch/rotary to see how it is implemented. See https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ 3. Ask about this preset on the Mobiflight HubHop support. on Discord under the MSFS2020 channel. John

Glad you got this working! Yes, doing that should have given you a lot if insight in how and why to use such functionality as assignment overloading, adding lvars to offsets, and using offset conditions, That should be useful for future complex assignments. The lua script is also not a bad solution, but this is probably more resource efficient and will execute faster, as it won't have the thread creation overhead (as all lua scripts are ran in separate threads). No problem - and thanks for the update. John