IMPORTANT for XML-gauge developers: Variables and Framerate

In my quest to find the reason why some users of my "groundhandling" gauges have problems with sounds not being played, I (accidentally) found a reason: slow framerates.There is something every XML gauge designer should realise when creating an XML gauge.As Arne Bartels already explained a few times in various posts, if you give an event in an XML-gauge, the result of it will not be visible untill the next time the gauge is scheduled.Example:If you have XML code like :....(>K:TOGGLE_LOGO_LIGHTS) ......(A:LIGHT LOGO,bool) //Read LOGO lights state......the new LOGO light state is not reflected in XML untill the next time the gauge code is run.Unlike G:Var's or L:Var's.FS obviously has some internal process, where the content of FS variables that you read in XML, are a copy of the "real" FS variables; and this copying is a scheduled proces within FS; which would explain this behaviour.But it gets worse:While scheduling times of gauges are NOT depending on framerate, the scheduling of this "copy" proces IS.(note: for XMLgauges, the schedule time is defined in the "Update Frequency", see table below)Which means that if the framerate gets below 18 fps (and the XMLgauge runs at the default 55msec schedule), the statement that "the result of command will be visible the next time the gauge is scheduled) may NOT be true: it may even take MORE than one schedule time !!!!I did some measurements, and it appears that this "copy" process is directly related to framerate.So: with FS indicating 10 fps, this copy process runs only every 100 msec.This means that if you have a construction like"condition"if{ (A:LIGHT LOGO,bool) ! if{ (>K:TOGGLE_LOGO_LIGHTS) }}els{ (A:LIGHT LOGO,bool) if{ (>K:TOGGLE_LOGO_LIGHTS) }}to force LOGO lights ON when "condition" is TRUE and OFF if "condition" is FALSE, you may end up toggling the LOGO lights a number of times ON and OFF again, instead of just once.Which, when used for other code "logic", may give very unpredictable behaviour of your gauge.Although there are more code-intensive ways to avoid this (e.g. "remember" in a local variable that you have already executed the command in a previous schedule), the simplest solution (although not fool-proof) to avoid this problem:NEVER USE AN UPDATE FREQUENCY HIGHER THAN 0.17 sec ("6")This means that the gauge works as expected, for framerates as low as 7 fps (which is at least MY absolute minimum to have FS running).In an XML gauge, you can include:This "Update Frequency" determines the interval with which FS schedules the gauge (i.e the refresh rate)If line absent, value=0 or value>9: 0.055 secValue=1: 1.00 secValue=2: 0.50 secValue=3: 0.33 secValue=4: 0.22 secValue=5: 0.17 secValue=6: 0.17 secValue=7: 0.11 secValue=8: 0.11 secValue=9: 0.11 secHope this helps ....Regards, Rob Barendregt