Initialisation sequence problem with XML gauges.

[rcbarend 37]

For XML gauge designers:As you probably know, the result of setting an FS variable via an event, is NOT visible via the related A: variable untill AT MINIMUM the next time the gauge is scheduled. And not even THAT is guaranteed, depending on actual framerate and gauge UpdateFrequency.See also:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchThe same problem might occur when you try to initialise an FS variable once, when a gauge is loaded.Example:Suppose you load an existing flight in which a lightswitch is set ON, and you want force the lightswitch to OFF when the aircraft is loaded.(in a initialisation tag that is executed only once).Now, a lot of variables only have a Toggle function, so in order to force it OFF you have to test the current state first.I have seen several times when testing such a variable the first time the gauge is loaded, the variable DOESNOT have the correct value (as defined in the .flt file).So, the XML-copy of the variable doesnot reflect the actual value yet. Only the second time the gauge is scheduled, this XML-copy of the variable has the correct value.I.o.w.: if your gauge relies on such an initialisation, the initialisation loop should be executed at least 2 times before the read value is reliable.So be warned :-) ...Cheers, Rob Barendregt

[Guest Karl R Pettersen]

The way I handle this problem, is to put it all in a sequenced delay (see another post).1) Wait until the .flt file has done its work.2) Do the changes you need to do, initializing work etc.3) Wait a little more, then check that all went well.May look harder to do, but is slightly less "messy" than setting variables twice. Would setting twice work just as well on all machines? Not too sure. The waiting will check that all went well, and inform if it didn't, in which case the user should increase the delay time (2.5 and 5 seconds should be more than enough though).

[rcbarend 37]

Hi Karl,As usual, there are more solutions to a problem :-)What I usually do, is execute the initialisation sequence once in the second time the gauge is scheduled; and that never fails ..What I also found that this "FS variables copying process" directly relates to the framerate. So with framerate = min. 5 fps, the copying process runs at least every 0.2 sec). Hence, I always use UpdateRate=4 (0.22 sec) in my gauges.With this assumed min. framerate, my gauges always run as intended, both at initialisation time and normally. What you do at initialisation is way too long; if it would take this long time at initialisation of the gauge, setting a variable and then testing it in the next cycle (when the gauge is running normally) would give problems too (since it's the same issue).Cheers, Rob