FPVSteve

In that case it appears to not be working (for me) as when I close MSFS 2020/2024, FSUIPC continues to run in the system tray.

Hmm - I don't seem to have an "Exit with FS" option (or at least I can't find one): Where is that option located and I'll let you know whether or not it was selected - that may indeed be the source of the issue if it's switched off. Thanks John, Steve

Well I presume it isn't closing when the simulator closes - perhaps it's not detecting that the simulator is no longer running? I do understand where you're coming from but I also think that it might be a better solution to simply switch to the already running process if one exists rather than showing an error. The error message has only one function after all which is to kill the newer process. FSUIPC should be able to take care of that functionality without showing an error IMO. Anyway, just my opinion - it annoys me enough to ask for a solution 😂

Hi, Is there any possibility that the dialog box that pops up saying "FSUIPC is already running" could be removed? It doesn't seem to serve any other purpose than to require a confirmation (pressing OK) before closing the second instance of FSUIPC - from an end-user point of view the second instance could just disappear quietly and the first instance would operate as expected anyway. The reason I'm asking is because the message box pops up but more often than not ends up behind the simulator meaning you have to alt+tab out to get shot of it which is fairly annoying. Thanks!

Where do you get the idea that I'm somehow "angry"? That's not the case at all 🙂 The only thing I will say is you will probably have more luck talking to me directly about issues concerning my software - if you had put forward the information about you running SLC on a remote machine to the simulator during our support communications, I could have told you immediately that SLC works remotely for basic functionality but does not support LVARs via WideClient (and it says as such on the Settings screen). This will change in the near future, but you will have no luck at the moment and so should turn off the advanced functionality that requires LVARs in SLC Settings on the Compatibility > Aircraft tab. P.S. The Settings.xml file you posted is a template and is not the Settings file that is active within the application.

Confirmed - yes, instead of Tail Left and Tail Right, Asobo were using Nose Left and Nose Right for the values.

Great news - it worked perfectly. I tried multiple combinations: Straight / Stop Straight, Left, Stop, Straight, Right, Stop, Straight, Right, Left, Stop, Left, Stop etc. All fine. Thank you very much for that.

Hi, I decided to monitor the pushback offsets and noticed the following: 0x31F0 = Current Pushback State 0x31F4 = Pushback (Set) 0 = Straight 1 = Left 2 = Right 3 = No Pushback Edit: it looks like 0 is now 4 in MSFS, so it is no longer zero indexed. (1 and 2 directions may be mixed up in this report but it is neither here no there as the result is the same) If I write to the offset 0x31F4 directly, the value is stored and the value in 0x31F0 also changes to reflect the state. However, nothing happens in the sim. If, however, I use SHIFT+P, the offset monitor comes back with "SimRead: 31F4='PUSHBACK STATE' (also 31F0) INT32: 4(0x00000004)." The aircraft starts to push back... however none of the directional values work, and you cannot cancel the pushback by setting "3" as the value ... you have to SHIFT+P again Is there any way to make the simulator react to the offsets (0 (or 4) and 3 as the values) instead of needing SHIFT+P - and also to respond to a turn request by specifying either 1 or 2 as the value? Here is a sample log (NOTE THAT I HAVE ALSO TRIED TO WRITE TO BOTH OFFSETS IN MSFS - IN OTHER SIMS, ONLY WRITING TO 31F4 IS REQUIRED - then 31F0 updates automatically) (Attempt to START by writing an integer of 4) 733296 Monitor IPC:31F0 (S32) = 4 733312 Monitor IPC:31F4 (S32) = 4 ----- nothing happens --- (SHIFT+P PRESSED) 733359 SimRead: 31F4="PUSHBACK STATE" [also 31F0] INT32: 4 (0x00000004) ---- aircraft pushes back ---- (Attempt to STOP by writing an integer of 3) 734281 Monitor IPC:31F0 (S32) = 3 734296 Monitor IPC:31F4 (S32) = 3 ---- nothing happens ---- (SHIFT+P PRESSED) 734343 SimRead: 31F4="PUSHBACK STATE" [also 31F0] INT32: 3 (0x00000003) ---- aircraft stops pushing back ----

Yes, they probably open the doors on the model but they do not update the simulator door status. I could be wrong but if they did, FSUIPC would pick up on it like it does with a jetway being connected then the sim opening a door. FSUIPC is working as it used to, but the simulator is overriding the values.

Just to confirm the above I've done some testing this morning and it does appear that writing to the offset gets overridden by the flight simulator. What this means is you cannot open or close a door at will any more - the doors appear to be controlled by the simulator and will only be "open" if you are connected to a jetway. Similarly, once connected to the jetway you cannot manually set a Door offset to "closed (0)" - it will be overridden to "open (1)" by the simulator. To successfully open the doors, you must be at a gate (not a ramp) then summon the jetway from the "ATC > Ground Services" menu. You must also disconnect the jetway in the same way. From the point of view of FSUIPC in both cases reading the offset value works perfectly. "Write" works but gets overridden back to the value that MSFS deems to be correct for the current ground "status" of the aircraft. Offset bit manipulation by MSFS: A320 (Single Jetway Gate): 0 - Jetway turns to 0 or 1 depending on if connected 1 - No effect 2 - No effect 3 - Catering Truck turns this to 0 or 1 depending on if present 4 - No effect 5 - Baggage truck turns this to 0 or 1 depending on if present 6 - No effect 7 - No effect There may be other manipulations available for larger aircraft such as the 747 and 787 at larger gates with multiple jetways but I'm sure you get the idea.

Further to this update I have had a report that the offset does respond correctly if a jetway is connected - apparently this switches the bit of the connected door to "1" or "open". If this is indeed the case, then the aircraft must have some logic built into it to determine whether it's in a valid state to have a door open - either a jetway connected or perhaps some airstairs (if that's possible within MSFS).

Thank you, it's not a huge issue but it would be good to know either way.

The Door offset 0x3367 does not appear to be working correctly (or perhaps it is from the point of view of FSUIPC). It does talk to the simulator - in the 787 and A320 the "DOOR" warning flashes up on the display when sending "1" to any of the bits, however it immediately returns to the previous value and the door closes. I'm wondering if perhaps the simulator is simply resetting the value because the doors are in-fact still closed, whereas in other simulators the bits simply get accepted regardless of what is happening to the aircraft model.

Are you able to tell us some of what will / won't be supported via FSUIPC upon release without breaking NDA? Information about support for simple offset values such as aircraft altitude / heading / light switches / landing gear and flap positions etc would be very helpful - if they don't change from the point of view of an end user then so much the better. If you can't then no problem - I still thank you for your hard work in the meantime.