MSFS20 setInterval( ) within MSFS Update Section

[ark1320]

I cannot get the Javascript setInterval() function to work within a MSFS update section for an HTML gauge. No matter what interval I use (here 2 sec), the TEMP_TEST variable below increments at the same (very fast) rate.
Is there some limitation in using setInterval() within a MSFS update section, for example, maybe something to do with the update section rate vs the setInterval repeat rate (maybe the setInterval rate has to be faster then the Update section rate)?
Thx,
Al

          setInterval(()=> {this.TEMP_TEST++}, 2000);
          SimVar.SetSimVarValue("L:TEMP_TEST_VAL", "NUMBER", this.TEMP_TEST);    //This line just for display purposes in DEV mode

 

[ark1320]

The setInterval() function is basically a repeditive or looping function, and as I was thinking about this it occurred to me that I don't think I've ever seen a typical loop operation, like a do -while or for loop, in any of the sim Javascript code. Does the nature of the way the sim operates preclude such loops in HTML gauges?
Thx,
Al

 

[WarpD]

There may be too many left parentheses.

 

[ark1320]

Well, I looked at the syntax again and the basic form for setInterval and the arrow function are:
-- setInterval(func, delay)
-- ( ) =>
If I remove the curly braces above, it does not seem to make any difference in the result since it is a single line arrow function. A multiline arrow function requires the curly braces, however.
Thanks,
Al

 

[ark1320]

I wonder if the problem could be related to the setInterval delay time being greater than the Update section repeat time. For example, if the update section repeats every 100ms or so, what happens if the interval delay is 1000ms? Does the setInterval function get reset and "start over" (increment once) every 100ms so the 1000ms delay never happens? Said another way, I wonder if the count up rate I see is essentially the Update section repeat rate?
Thx,
Al

 

[B21-soaring]

I suggest not including JS async timers in your game code - IMHO it's just asking for trouble conflicting with CoherentGT owning the 'outermost loop' of the high-speed Update handling down the chain of BaseInstrument subclasses.

Far safer will be to use the already-built-in Update callback support and simply check the time. Safe is to use either the various MSFS simvars (I recommend SIMULATION TIME) or in an unusual situation where you believe real-world time is more important than time inside the game, you can use JS Date() values. I have to say where I've seen the latter done, this has always been a rookie error from someone unfamiliar with issues that commonly arise in game programming. Someone in Asobo has made a really amateur error halfway down the Instrument code stack, passing an 'update delta time' value that is calculated by subtracting JS Dates, so that bears no relevance AT ALL to the timestep in the simulation defining the time gap between simvar values that are being passed in the same call.