Timer Question/Suggestion

[+USCcouple]

I have recently been messing around with the timers more for a new cartridge. I found out that the countdown timer continues to “count” when the cartridge is closed. I can see where this is very useful in some cases where you want the user to move from point A to point B in a given amount of time, and would not like the user to be able to turn off the device and move without the timer counting down.

 

However there are other situations where I want a timer to not count if the device if off. For example if I have a countdown timer and there is code that happens on the tick when it ends. If the player started the timer and then turns the unit off, when the unit is turned back on, the countdown timer might set to zero, and then the timer tick event never occurs, which would obviously be a problem for the player.

 

I can see ways of making the timer stop and restart with the same value, by putting functions in CartStop and CartStart/CartResume events, but this would be complicated and possibly flawed. This workaround might be fine if the user closes the application properly, but if the unit lost power all of the sudden then there would still be a problem.

 

I was wondering if there might be a way in a future release to set the timer so that it does not change when the program is not running. Also in order to pause a countdown timer, the timer has to be stopped and then the value saved in a variable, and then to restart it the timer has to be set to the variable and then started. Would there be a way to implement a pause for the timer, or rather a continue, since when it stops it still has the old value until it is started again.

 

Any comments or ideas?

 

Thanks,

Kevan

[iryshe]

You hit on the reasoning why countdown timers continue to tick even when you save and close the application. In reality, of course, on restart it checks the time and expires the countdown timer if too much time has passed. While you have full control over a user in a traditional console-based game you don't have the ability to stop a real person from moving (or doing anything you don't want them to do) outside of the constraints of the device. I don't think I'd want that power in anyones' hands.

 

If you truly want to have an event managed as you outlined in your post you would just choose to manage the countdown yourself as a variable that you decrement by 1 every time the OnTick event occurs. That way if and when the user saves and closes the cartridge it can just resume with the value it had when it left off.

[+USCcouple]

For example if I have a countdown timer and there is code that happens on the tick when it ends. If the player started the timer and then turns the unit off, when the unit is turned back on, the countdown timer might set to zero, and then the timer tick event never occurs, which would obviously be a problem for the player.

 

Could there at least be a fix for this issue, as it does seem like a rather large problem.

 

Thanks,

Kevan

[+qlenfg]

You start the timer, stop it, then display it:

 

I do this when the cartridge is started:

 

Start ztimerTrip_Timer

 

Each timer tick (1 second) Timer_Count is incremented by one.

 

And when they reach the final zone:

 

Stop ztimerTrip_Timer

Set Timer_Count Equal to Timer_Count / 60 * 10

Set Timer_Count Equal to math.modf(Timer_Count)

Set Tmer_Count Equal to Timer_Count / 10

 

This takes the timer, which is in seconds, and rounds it out to minutes and 10ths of minutes.

 

Works fine on the emulator, but blows up on the Colorado as soon as you enter the final zone.

[Ranger Fox]

And you did require math for that, right? If yes, just as a check, after you see the cartridge blow up, open the lua file and see if the builder stripped the line from the top.

[+qlenfg]

And you did require math for that, right? If yes, just as a check, after you see the cartridge blow up, open the lua file and see if the builder stripped the line from the top.

 

Will check the raw code as suggested. I did not put a math statement in the author... section as I never found a working example of the statement.

 

The conversion to minutes was lark -- probably should have left it out for now. In any case, the command does stop the timer.

 

But it appears the timer works without the math, I just hate seeing the time in seconds when the cartridge will take minutes or hours.

 

Not sure which line you mean. I hand-coded the math into the .lua file and it worked fine in the emulator, but not on a Colorado 300. Here is the code segment:

 

function zonePub:OnEnter()

-- #GroupDescription=At_Pub --

-- #Comment=At_Pub Comment --

Wherigo.MessageBox{Text=[[Ah! Finally here!]],}

Wherigo.Command("Alert")

ztimerTrip_Timer:Stop()

Timer_Count = Timer_Count/60*10

Timer_Count = math.modf(Timer_Count)

Timer_Count = Timer_Count / 10

Wherigo.MessageBox{Text=[[it took you ]]..Timer_Count..[[ minutes to get here.]],}

ztaskGoTo_Pub.Complete = true

cartBullnBush.Complete = true

Wherigo.Command("SaveClose")

end

 

In case you are wondering, I want to write a Wherigo cartridge to do a pub crawl around Fort Worth.

Edited May 4, 2008 by qlenfg

[+qlenfg]

Something ain't right.

 

I set up the same type of cartridge for a close location, and had what appears to be the same crash, even with no math involved. I simply started a timer, added one to a variable every timer tick, then stopped the timer and displayed the variable contents when the final zone was reached. No conversion math, beeps, etc...

 

Worked fine on the emulator, died horribly on the Colorado 300.

[+qlenfg]

Got it figured out. For some reason the cartridge was crashing when I tried to display a message when you entered the zone. I moved the display message routine to a separate task and it worked fine when I called it from the zone routine. Threw in the basic timer display and it still worked. I'll add the rest of the features and hopefully it will still work.