Frequency:Consistently Severity:High Bug description:
Input events are slower in FS24.
Below I have the same code running in both games.
“_Update” is on a normal 1hz update loop add 1 to itself
“_Event” is in an input event adding “ANIMATION DELTA TIME, Seconds” to itself
The whole thing resets at 10 seconds.
FS20
FS24
FS20 is working correctly and is perfectly in sync (only 1 frame behind)
Both tests are run without frame generation around 60fps in the same parking spot, same weather.
I assume this is occurring on your Da40 aircraft package?
Can you let me know in what part of the behavior logic your are testing this, particularly the TIMER_TEST_EVENT variable? (You can send the modified behavior files to @PrivateContent)
I made some tests myself in some of your InputEvent sections but could not replicate the issue.
It looks like it’s framerate related.
At first I could not replicate or the drift was minimal (a few tenths over the 100 second loop).
I then lowered my graphics settings to get a consistent 60 FPS and the drift became obvious.
Can you confirm this? I assume you have a high and consistent framerate?
This was reviewed by our systems engineer and this is actually the expected behavior.
The input event execution is event based and was never designed to match sim rate in the first place. The fact it did in MSFS 2020 is coincidental.
The proper way to do this is through a behavior update component.
A ASOBO_Tick_Every_Frame_Helper function was added in the MSFS 2024 behavior files to help in such situation. (C:\MSFS 2024 SDK\ModelBehaviorDefs\Asobo_EX1\Common\Shared\Utils\Procedures\Procedures.xml)
You should be able to port this code to 2020.
<!-- @DOC MACRO TICK_Get_Delta_Time
@Brief Tick delta time set every frame when using ASOBO_Tick_Every_Frame_Helper in an input event
@Return Tick delta time (O:_DeltaTime)
-->
<Macro Name="TICK_Get_Delta_Time">(O:_DeltaTime)</Macro>
<!-- @DOC FUNCTION ASOBO_Tick_Every_Frame_Helper
@Brief Configurate an input event to make it tick every frame. Delta time is stored inside the macro TICK_Get_Delta_Time
@Param TICK_VAR name of the tick variable
-->
<ParametersFn Name="ASOBO_Tick_Every_Frame_Helper">
<Parameters Type="Default">
<TICK_VAR>XMLVAR_#IE_PRESET_ID#_Tick</TICK_VAR>
<TICK_VAR_SCOPE>O</TICK_VAR_SCOPE>
</Parameters>
<Parameters Type="Override">
<TICK_ONCE>(#TICK_VAR_SCOPE#:#TICK_VAR#) 1 + dnor (>#TICK_VAR_SCOPE#:#TICK_VAR#)</TICK_ONCE>
<UPDATED_THIS_FRAME>(O:_LastUpdateTime) @E_SimulationTime ==</UPDATED_THIS_FRAME>
<STORE_LAST_UPDATE_TIME>@E_SimulationTime (>O:_LastUpdateTime)</STORE_LAST_UPDATE_TIME>
<UPDATE_DELTA_TIME>@E_SimulationTime (O:_LastUpdateTime) - (>O:_DeltaTime)</UPDATE_DELTA_TIME>
</Parameters>
<Parameters Type="Override">
<TICK_CODE>#TICK_ONCE# #UPDATED_THIS_FRAME# if{ quit } #UPDATE_DELTA_TIME# #STORE_LAST_UPDATE_TIME#</TICK_CODE>
</Parameters>
<Parameters Type="Override">
<UseParametersFn Name="ASOBO_Watch_LocalVar_Helper">
<LOCAL_VAR>#TICK_VAR#</LOCAL_VAR>
<VAR_SCOPE>#TICK_VAR_SCOPE#</VAR_SCOPE>
</UseParametersFn>
<UseParametersFn Name="ASOBO_Append_Init_Code_Helper">
<APPEND_BEFORE>True</APPEND_BEFORE>
<INIT_CODE>#TICK_CODE#</INIT_CODE>
</UseParametersFn>
</Parameters>
</ParametersFn>
Ok, interesting.
Ive already moved most things to GT_Anims. Those runs at the games frame rate.
Engine based stuff are forced to 100hz, but only active in FS24
Updating a physical property in a simulation assuming some ‘delta time’ for your underlying calculation would be ‘unusual’ (e.g. you assume a delta time of 1 second so you calculate one second’s-worth of fuel flow). I’m not sure it that’s what’s being talked about here, but there’s so many free-running clocks in MSFS that’s always going to be problematic. The check is the same update code should work just as well with a 2-second update as a 1-second update.
The only thing you can rely on is SIMULATION TIME, (or as was previously ABSOLUTE TIME) should be absolutely locked to the simulation, i.e. of the flight model or the weather effects. If ‘SIMULATION TIME’ drifts too far from ‘real time’ you could raise that as a bug, but that should affect ALL code in the sim, not just one specific calculation. MSFS itself has challenges sticking to this basic principle (simvar values are related to a known simulation time) so you have to be careful.
The correct technique is simple: in one cycle you use SIMULATION TIME + { FUEL QUANTITY, OTHER SIMVARS, WHATEVER }, and the next time you do a calculation, which can be any time in the real world, you update with a new coherent collection of those values relevant to the new SIMULATION TIME and update simvars you’re interested in. Your formula should be confident those two simulation time values are accurate for the two sets of simvar values your using, and if your formula needs ‘delta time’ that’s the difference between the two simulation times.
All retail simulators accumulate 3rd-party code that is trying to update things based on real-time, or frame time, or javascript time, UI-update-delta, or whatever, and then asking for those things to be ‘more synchronised’ with the internal simulation, but essentially that approach is fundamentally flawed. MSFS doesn’t help by provide quite a variety of free-running clocks (like the html/js delta_time) so there’s kind of double jeapordy there.
This topic has been automatically closed after 60 days of inactivity since it was marked as by-design.
If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.