Controlling .gau update frequency

[Guest HC001ST - Stick]

2 questions1) How do you control the frequency that a .gau is updated?2) My gauge is apparently acting on var values that have not yet been entirely initialized on panel/aircraft initialization. What's the best way to ensure valid values before allowing gauge logic to operate on them? In my case, I'm noticing that although an aircraft's engines are started, when loading the aircraft, the RPM and other engine vars appear to start at zero (or perhaps a random value), and spool up to value at some point. I need to prevent the gauge from acting on this transient data.Thanks

[Guest zip]

Do a search on the forum below - I thought I answered this somewhere before.Two options I use:1) the main callback is called approx 18 times per second (the old DOS timer tick), so you can time an update this way.2) use a windows timer to set flags.On your second question, this sort of delay occurs all the time in an event based system. This forced me to get in the habit of checking conditions all the time and never assume that a value is valid when I read it. You may not get the actual values until later, and in particular, some values do not get updated every cycle.

[Rocky 128]

As far as I know (I'm not 100% sure), here are the answers I can give:1) If you develop your gauge with the standard SDK macros (MAKE_STRING, MAKE_NEEDLE, ...), they will be refreshed 18 times by second. If you use your own gauge callback, it is called more often, but I don't think there is a fixed time interval between 2 calls. As far as I understood, FS shares the CPU time between all the tasks, and the refresh rate then depends on the CPU power.2) I have noticed the same problem, and the only solution I found is to wait for a little time (1 or 2 seconds) before actually starting the gauge after it has been loaded. During this time, the gauge is in an "initialization" status and ignores all the FS values.Hope this helps...Eric

[Guest HC001ST - Stick]

>Q: How do you control the frequency that a .gau is updated?>Ans: the main callback is called approx 18 times per second >(the old DOS timer tick), so you can time an update this way.Not sure what you mean by "time and update".I was looking to control how often the gauge has to be processed by FS, be framerate friendly. I guess what I'm asking is, given that the gauge callback IS called 18 times/second, how do you stay "frame rate friendly"?>Q: My gauge is apparently acting on var values that have not >yet been entirely initialized on panel/aircraft initialization.>What's the best way to ensure valid values before allowing gauge >logic to operate on them? In my case, I'm noticing that although >an aircraft's engines are started, when loading the aircraft, the >RPM and other engine vars appear to start at zero (or perhaps a >random value), and spool up to value at some point. I need to>prevent the gauge from acting on this transient data.>Ans: use a windows timer to set flagsNot sure I understand how this answers my question about how I determine that FS is done initialization, and data is now valid.Thanks

[Guest HC001ST - Stick]

>2) I have noticed the same problem, and the only solution I>found is to wait for a little time (1 or 2 seconds) before>actually starting the gauge after it has been loaded. During>this time, the gauge is in an "initialization" status and>ignores all the FS values.Eric,Yeah, not sure that's a good solution, just waiting for an abitrary time, but thanks for the idea. I suppose if there is on other way that might work, but I'd be uncomfortable just depending on it.

[Guest zip]

Using windows timers will interrupt FS processing independently of the main FS thread because they are OS timers and thus not controlled by FS. If you need a precise time measurement, such as for a clock or navigation update, a windows timer will be the only way to achieve this. Another use is to make sure that your callback gets called no matter what FS wants to do. As with any async type operation, your code should not tie up the CPU, and your goal is to complete the call and return as fast as possible. I use timers in this fashion to set a number of global flags, that I then update when FS9 calls my functions. This way, I know an event has occured, I have used very little CPU time to set my flag, and I take action based on the flags when FS gives my code a time slice of execution.My experience with the internal tick of 18 times per second is that it's more or less reliable as Eric points out. The chief advantage of using the main gauge callback frequency is that you're on FS time slice time. By this, I mean that FS tells you it's a good time to do your code updates. I have a global counter that just increments every time the main callback is called that I use as an approximate method to figure out when to run an internal update. This is good for example on VC gauge updates vs 2D panel updates, or if you need to get updated flight parameters every so often (example, fuel level).You can also use this to count custom paint requests, and repaint at a slower rate (by skipping paints). This can have a significant effect on FPS.There's not a whole lot you can do about the internal FS variables not updating since there's no event that says "all variables updated and ready to use", but you can check for expected value ranges and often use related values to see if the data you got makes any kind of sense. Another tip is to wait for the first PANEL_OPEN request (lookup service codes in gauges.h), because that's usually an indication that the a/c is loaded, that the main panel initialized, and that internal variables have been updated.Keep on asking questions! I certainly wish more developers would share their tips and tricks on this forum. Then again, because it can be very often be a frustrating experience figuring out what the MS team did and how things work, I understand why the shroud of secrecy exists, expecially if the tip is used in a commercial product...

[Guest HC001ST - Stick]

Wow, quite a lot of useful info there. Thanks.Yes, the idea of a counter updated by the g_cb had occured to me when I thought about making a "test" gauge to "count" each run of each section in the g_cb to get a better idea of what was happening.Interesting use of the time calls to set state info that is ready to process when the gauge gets CPU time.I'll play with this stuff and see if I can't solve the problem I'm dealing with now.Thanks again.