Version: 1.1.9.0
Frequency: Consistently
Severity: Low
Context: External SimConnect client using SubscribeToSystemEvent
Bug description: The sim doesn’t send any indication that the simulation has been stopped, for example when leaving for the main menu.
Repro steps:
Subscribe to “SimStop” and “Sim”, you won’t get either indication when leaving for the main menu. The sim only sends a “Pause”.
I’d like to suggest an increase in the ‘severity’ from low. For a classic simconnect application such as a logger in 2024 it’s currently not possible to detect when the log should be written to file and the logging re-initialized (i.e. on the exit to the main menu) vs. when the logging should be simply paused & continued when the player un-pauses.
And while we are on the topic - the opposite isn’t working corretly either, never has been, in MSFS2020 too.
On the way from MSFS boot to the cockpit, a SimConnect clients gets multiple messages about “SimStart”, “Pause” and “aircraft loaded” - although the 3D simulation isn’t actually running. I found it quite hard to “nail” the moment in time when the simulation is actually running and the aircraft is loaded in full.
The expected behavior would be that you get exactly one call to SimStart when the 3D simulation is active, and one to SimStop when it isn’t. This doesn’t have to happen with each trip to the menus (would be great though), but at least when going from the Main Menu into the sim and back again.
My flight logger simconnect code from MSFS2020 needing to detect the various ways a pilot might have completed a flight (including a sim CTD) took a bit of a nosedive on transition to MSFS2024 partly due to the differences in the ‘pause’ behaviour.
BUT searching this forum for clues and hints revealed there’s a well-established art of using the A:CAMERA STATE simvar as a proxy for where the use is interacting in the sim. It’s clearly not perfect but it’s a really useful additional piece of information. I’m shocked I’ve never noticed it before.
Someone at FSDeveloper (thread) seemed to observe that the sim sends PAUSE_STATE_FLAG_SIM_PAUSE | PAUSE_STATE_FLAG_PAUSE (9) for Pause_EX1 event value when navigating to the main menu, which they said was new in FS24. I haven’t tested this myself at all yet, just passing that on, FWIW.
I was using Pause_EX1 argument values as a way of providing clues when the user quits flying to return to the ‘main menu’ / ‘world map’. I have a FAI IGC flight logger simconnect app which needs to decide when to re-initialise the logger for the next flight. I found using Pause_EX1 pretty fragile for common simconnect code for MSFS2020 and 2024, i.e. in 2024 a user somehow managed to trigger the apparent ‘I’m in the main menu’ pause arguments after hitting ‘Esc’ while flying and making some adjustment in Settings.
The ‘Pause’ UI-detect approach really is trial-and-error as there’s no concrete definition of what will work where.
What I have most recently as the most reliable method for both 2020 and 2024 is to detect a transition in the A:CAMERA STATE simvar from [anything] to [12] which says the user has entered the World Map. That’s technically not the main menu but it always precedes a ‘Free Flight’ in both sims which is my use-case.
I don’t mean to suggest I have any definitive answer here - just I find comparing notes on this kind of stuff really helps.