Input events slow

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.

The slow input events can cause up to a 10% power loss on my aircraft compared to FS20.

To compensate I put some of the code into a “GT_ANIM” and this reduces the power loss to 3-4% over FS20.

Hello @MrTommymxr

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.

Regards,
Sylvain

I dont have that code in my da40. I will add it tomorrow including other loops at different frequencies.

Ok i have added the code to the DA40. Same link, just redownload.

3 blocks of code have been added in the model.boom folder.

  1. The normal xHZ code is at the bottom of the DA40_Logic.xml
  2. _Event is at the bottom of the DA40_Inputs.xml
  3. _ANIM is line 163 of DA40_EX.xml

Here are all the timer_test values. in FS20
image

FS24
image

The xHZ have improved in FS24, but input events are still slower

1 Like

Hello @MrTommymxr

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?

Regards,
Sylvain

Yeah i have medium ish settings. 60fps without frame gen, 120 with.

Thanks for looking into it.

Any chance the normal updates can also be looked at in FS20?

Hello @MrTommymxr

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 (&gt;#TICK_VAR_SCOPE#:#TICK_VAR#)</TICK_ONCE>
		<UPDATED_THIS_FRAME>(O:_LastUpdateTime) @E_SimulationTime ==</UPDATED_THIS_FRAME>
		<STORE_LAST_UPDATE_TIME>@E_SimulationTime (&gt;O:_LastUpdateTime)</STORE_LAST_UPDATE_TIME>
		<UPDATE_DELTA_TIME>@E_SimulationTime (O:_LastUpdateTime) - (&gt;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>

Regards,
Sylvain

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

Thanks for looking into it

1 Like

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.

Im honestly not gonna bother anymore.
Im just copy pasting everything into random GT_anims because those actually work.

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.