If the user starts the flight on the ramp, he is put outside the aircraft to perform the walkaround. However, I’ve noticed that many system events do not work until he enters the cockpit. For example I put a code that tries to set autopilot heading bug every frame to 270 degrees using simconnect events, and it only starts to have effect once the view changes to cockpit:
The same issues exists for many other variables, like radios, course setting etc, haven’t checked them all. I also tried to use Simvar Watcher instead of events, and that one works, so the simvars are settable during walkaround, but not through key events.
Obviously 2020 aircraft are not aware of the walkaround phase and the required changes in the initialization sequence.
Ideally, for 2020 aircraft the initial walkaround phase should be disabled and the user should load inside the aircraft cockpit when starting on the ramp, just like it worked in 2020. He should still be able to leave the aircraft if he wishes with keyboard shortcut, but the initial walkaround should be skipped entirely, it serves no purpose for 2020 aircraft.
I’ve already seen many confused customer reports (for our aircraft and others), who spawn outside the aircraft and can’t enter the cockpit, because the door handles are not interactive, and the only way to continue is to use the “Shift-C” keyboard shortcut, that has a rather unrelated name of “Take Control of Character” in the settings.
Repro steps:
Use SimConnect_TransmitClientEvent to send HEADING_BUG_SET event during the initial walkaround phase. It should set the AUTOPILOT HEADING LOCK DIR simvar, but does not.
Investigated the problem a bit more, and indeed it looks like Simconnect events do not work while the user is outside the aircraft.
Here is a modified SendEventA sample from the SDK that continuously rotates the heading bug.
It works from the cockpit, but the simvar does not change when you exit the aircraft. Not only during initial walkaround, but every time you leave the cockpit. You can monitor the simvar with simvar watcher.
This causes issues during aircraft initialization, because from the 2020 gauge point of view, the flight is started, yet the events don’t work.
Additionally, it seems like any key events are being ignored, also when triggering them via the gauge api (trigger_key_event_ex1) or the new events api. So it does not seem to isolated to simconnect.
Once inside the cockpit, everything works as expected. When leaving it again, no events are processed.
I also think it’s not isolated to 2020 aircraft only. I spawned in the default Cessna 172 and tried to extend the flaps with the “FLAPS_INCR” event. It works inside the cockpit, but has no effect when outside with the avatar.
Thanks for confirmation, yes, this particular issue with events is affecting both 2020 and 2024 aircraft. I’m not sure if that is a bug or a design decision, but it breaks compatibility with 2020 aircraft somewhat.
With 2024 models we can at least make checks for walkaround state and adjust the code accordingly, but 2020 aircraft are not aware of that, which causes issues. Especially on initial walkaround that happens when starting on the ramp, because the aircraft is initializing while the user is outside.
What we now did (in the FBW) is to check for the CAMERA STATE variable before running initialization. We check for it having values 2 or 3 (which is Cockpit or external view, so basically it turns 2 after pressing Shift +C). More of a workaround, but seems to work for now.
This is a regression we are already tracking.
Right now, SIMCONNECT_OBJECT_ID_USER corresponds to aircraft when you are in the cockpit and avatar when you exit the aircraft.
We plan to address this by splitting this into: SIMCONNECT_OBJECT_ID_USER(=0): legacy value for user aircraft ObjectID SIMCONNECT_OBJECT_ID_USER_AIRCRAFT(=0): value for user aircraft ObjectID SIMCONNECT_OBJECT_ID_USER_AVATAR: value for user avatar ObjectID SIMCONNECT_OBJECT_ID_USER_CURRENT: value for user aircraft/avatar ObjectID (current behavior of SIMCONNECT_OBJECT_ID_USER)
Just in case it was missed, wasm events API also suffers from this issue, and there’s no way to specify ID_USER in those functions. I think the legacy trigger_key_event_ex1 should default to USER_AIRCRAFT, to maintain backwards compatibility, while the new fsEventsTriggerKeyEvent needs an api extension if you want to split control over aircraft and avatar this way.
That’s a fair point.
This first fix (available in the flighting 1.3.7.0) only addresses the SimConnect side for now.
Investigations are still ongoing for WASM.
