Skip to content
View in the app

A better way to browse. Learn more.

The AVSIM Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Initialisation sequence problem with XML gauges.

Featured Replies

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

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).

  • Author

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

Create an account or sign in to comment

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.