Timer Code

[Guest VAPilot]

I need a timer code for my Transponder ident light, according to the information I have, when the ident button is pressed the light then lights up for 18 seconds and then goes off.I came up with this:BOOL FSAPI ident_button ( PPIXPOINT relative_point, FLAGS32 mouse_flags ){ if (ident_light_position == 0) ident_light_position = 1; if (ident_light_position == 1) { lookup_var(&seconds); //Get elapsed time time = seconds.var_value.n; ident_time = time + 18; //Add 18 seconds } return FALSE;}Then in the PANEL_SERVICE_PRE_UPDATE: lookup_var(&seconds); //Get current time time = seconds.var_value.n; if (ident_light_position == 1 && time == ident_time) { ident_light_position = 0; // Turn light off }an after the 101st compiler error, I am stumped.The compiler errors(248) : error C2440: '=' : cannot convert from 'FLOAT64' to 'time_t (__cdecl *)(time_t *)'(249) : error C2296: '+' : illegal, left operand has type 'time_t (__cdecl *)(time_t *)'(429) : error C2440: '=' : cannot convert from 'FLOAT64' to 'time_t (__cdecl *)(time_t *)'(431) : warning C4047: '==' : 'time_t (__cdecl *)(time_t *)' differs in levels of indirection from 'INT'

[n4gix 4,947]

I use a different approach to the problem, and don't have a clue what your compiler errors are... :)Here is how I "blink" an N2% string://////////////////////////////////////////float time_count = 0;float time1 = 0;////////////////////////////////////////// case PANEL_SERVICE_PRE_UPDATE: lookup_variables(); // I collect all lookups into // one function() call time_count = TICK18var.var_value.n ; break;//////////////////////////////////////////FLOAT64 FSAPI N2_Display_Hi( PELEMENT_STRING pelement){ float rwert=pelement->source_var[0].var_value.n; time1 = fmod(time_count,18) ; if ( ( TURB_ENGINE_1_CORRECTED_N2var.var_value.n < 96 && mbat == 1 && panelfl > 50 ) || ( TURB_ENGINE_1_CORRECTED_N2var.var_value.n > 96 && time1 < 9 && mbat == 1 && panelfl > 50) ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; } else { HIDE_IMAGE(pelement) ; } sprintf(pelement->string,"%5.1f",rwert); return 0;}The time_count is cheerfully accumulating a count at 18Hz...In the callback, time1 = fmod(time_count,18) ; gives me a starting value for the display timer.time1 < 9 will alternately hide/display the string ever half-secondFor a timer of 18 seconds, I could use:time1 < 324 ; // 18 ticks/second x18 seconds = 324ticks

[WarpD 824]

Fair warning: Use of the TICK18 imposes the very real risk of a rollover error.

[dragonflightdesign 98]

if(timer_number>65535)timer_number=timer_number-65535;-Dai

[Guest VAPilot]

Sorted the compiler errors, take TIME out and replace with ident_seconds and it compiles first time. Not sure why as it is a gauge on it own and I have not used time any where else :-rollThis it what it look like now, does not work though, but at least in compiles :-) which is a big step forward from yesterday.BOOL FSAPI ident_button ( PPIXPOINT relative_point, FLAGS32 mouse_flags ){ if (ident_light_position == 0) ident_light_position = 1; if (ident_light_position == 1) { lookup_var(&seconds); //Get current time ident_seconds = seconds.var_value.n; ident_time = ident_seconds + 18; } return FALSE;}if (ident_light_position == 1 && ident_seconds == ident_time) { ident_light_position = 0; // Turn light off }Thanks for the code Bill, will take a look and see if I can come up with something. I will continue to use elasped time though to make sure I dont get the roll over error that Ed warned about.Thanks

[ddawson 35]

Russell,You're testing for equivalence - with floating point values that can be a very unreliable test.Try changing this:if (ident_light_position == 1 && ident_seconds == ident_time)to this:if (ident_light_position == 1 && ident_seconds > ident_time)I presume you are incrementing the ident_seconds variable somewhere...Doug

[Guest VAPilot]

I was just about to post I had got it working, and the reason was ident_seconds == ident_time. Thanks for posting though DougI added a temporary string to the gauge, one for ident_seconds (variable ELAPSED_SECONDS) and another for indent time, when I clicked the button ident time increase by 18 sec from the current elapsed time, then when elapsed time = ident_time nothing happened, so I figured even though they should equals each other they never did. Changed it to this:In the ClickBOOL FSAPI ident_button ( PPIXPOINT relative_point, FLAGS32 mouse_flags ){ if (ident_light_position == 0) ident_light_position = 1; if (ident_light_position == 1) { lookup_var(&seconds); //Get current time ident_seconds = seconds.var_value.n; ident_time = ident_seconds + 18; } return FALSE;}In the PANEL_SERVICE_PRE_UPDATE:lookup_var(&seconds); //Get current time ident_seconds = seconds.var_value.n; if ( ident_light_position == 1 && ident_seconds <= ident_time) { ident_light_position = 1; } else { ident_light_position = 0; }now works a treat, press the button light comes on, 18 sec it goes off again.

[n4gix 4,947]

>Fair warning: Use of the TICK18 imposes the very real risk>of a rollover error.True Ed. That could become a real problem on those 60.5+ hour flights... :)

[WarpD 824]

>>Fair warning: Use of the TICK18 imposes the very real risk>>of a rollover error.>>True Ed. That could become a real problem on those 60.5+ hour>flights... :)>Um... no. TICK18 is a system level value. It's not actually an FS variable at all. It comes from the base OS, a throwback from DOS. It is from the days of DOS 1.0, believe it or not. It is triggered 18.2 times per second and thus never resolves to an actual second. 65535 divided by 18.2 is 3600.8241758241758241758241758242. That's 3600 seconds. One hour.

[n4gix 4,947]

>Um... no. TICK18 is a system level value. It's not actually>an FS variable at all. It comes from the base OS, a throwback>from DOS. It is from the days of DOS 1.0, believe it or not. >It is triggered 18.2 times per second and thus never resolves>to an actual second. 65535 divided by 18.2 is>3600.8241758241758241758241758242. That's 3600 seconds. One>hour.Well, that's certainly odd then. I've had this type of timer running continuously for as long as 10 days without any problems whatever... *:-* In any case though, simply replacing my TICK18 with seconds will accomplish the same goal.

[taguilo 33]

>>>Fair warning: Use of the TICK18 imposes the very real>risk>>>of a rollover error.>>>>True Ed. That could become a real problem on those 60.5+>hour>>flights... :)>>>>Um... no. TICK18 is a system level value. It's not actually>an FS variable at all. It comes from the base OS, a throwback>from DOS. It is from the days of DOS 1.0, believe it or not. >It is triggered 18.2 times per second and thus never resolves>to an actual second. 65535 divided by 18.2 is>3600.8241758241758241758241758242. That's 3600 seconds. One>hour.Ed, TICK18 is a float var, so I guess the number it can hold is much bigger than 65535, or maybe I'm missing something? In this case the risk of rollover would be null, and that would be the reason it actually works in Bill's code.Tom

[WarpD 824]

You're missing something. Just because FS returns a double (FLOAT64) doesn't mean the system (where TICK18 comes from) uses a double (FLOAT64).It's not the only variable returned as a double that actually isn't.Rollover is indeed a serious issue for the TICK18 value. Many, MANY gauges in the past have stumbled when using TICK18 for a timer.

[n4gix 4,947]

>You're missing something. Just because FS returns a double>(FLOAT64) doesn't mean the system (where TICK18 comes from)>uses a double (FLOAT64).>>It's not the only variable returned as a double that actually>isn't.>>Rollover is indeed a serious issue for the TICK18 value. >Many, MANY gauges in the past have stumbled when using TICK18>for a timer.I always cast the TICK18 as an (int) anyway, to eliminate the silly "warning" the compiler issues. I also periodically reset the timer to zero. That undoubtedly accounts for my lack of problems... ;)

[dragonflightdesign 98]

Hi Bill>I also periodically reset the timer to zero. That undoubtedly accounts for my lack of problems... ;)That was the point of the line of code I posted earlier in the thread. It dynamically checks and, if necessary, corrects the looked-for timer value.-Dai

[taguilo 33]

>You're missing something. Just because FS returns a double> (FLOAT64) doesn't mean the system (where TICK18 comes from)>uses a double (FLOAT64).>>It's not the only variable returned as a double that actually>isn't.>>Rollover is indeed a serious issue for the TICK18 value. >Many, MANY gauges in the past have stumbled when using TICK18>for a timer.Ed, I'm not sure of the accuracy of your statements.After some test in FSX, I've found that TICK18 -Is indeed an FS variable that adds one every *FS* cycle of a 18.2 cycles per second rate OR LOWER, which means IS afected by FS engine performance (measured by fps). It has nothing to do with system timer (directly), DOS, or whatever.-Starts from 0 at panelset initialization, and is not affected by PAUSE in the sim but it will stop when an FS's menu system is visible (for example, in MAP view, or when selecting an aircraft), and also when clicking on control boxes/window title bar in FS's windowed mode.-Returns a val that can be saved on any data type (char, int, float, etc) and DOESN'T give a runtime error when bound is overflown but instead starts from 0 or a negative value (for example, if saved as *char*, TICK18 will oscillate between -128 and 128)(*)-If assigned to a float var, it will go well beyond 65535, so no risk of rollover here.Tom(*) EDIT: actually this in not because of TICK18 but instead of one of the functions that I'm using to test ( sprintf_s() )