FPVSteve

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.