having issues with timer.pause() and timer.resume()

Solar2D Daily Builds and Public Releases
#1

Hey guys,
I have post this on the other forum. I added it here to gain attention because this part is very crucial for our app. I’m Sorry. :slight_smile:

I’ve seen this post before and did not mind the issue because they said it is all in the build and if you subscribe you will get the latest build which is fixed. I bought it and have the latest one still the same result. Here is the sample code.

[lua]local function defaultTimer()

local timer1 = {}

for count = 1, 15 do
timer1[count] = timer.performWithDelay(count * 1000, function ()
print(count…" is Activated")
timer1[count].expired = true
end)
timer1[count].expired = false
end
timer.performWithDelay(5000, function ()
for counter = 1, #timer1 do
if not timer1[counter].expired then
print(counter…" is pause with: “…timer.pause(timer1[counter])…” time left")
end
end
end)

timer.performWithDelay(8000, function ()
for loop = 1, #timer1 do
if not timer1[loop].expired then
timer.resume(timer1[loop])
end
end
end)
end

defaultTimer()[/lua]

What I expect to be the result is a increasing order of print. The timer pauses at 4 so it stops there. As soon as it resumes the first thing that it would print is 5 then 8…6…9…7…10…11 then it goes on normally till the end. What is with resume? is there something that I did wrong? I thought this was fixed? this timer is very crucial for my game please help. BTW, I also tried the bebeegames timer and the timer has some issues too nevermind on that. [import]uid: 149900 topic_id: 27020 reply_id: 327020[/import]

#2

Taking the code you posted and running it directly, in Windows sim 704b (I’m a trialist) I get this output:

[lua]Copyright © 2009-2011 A n s c a , I n c .
Version: 2.0.0
Build: 2011.704
1 is Activated
2 is Activated
3 is Activated
4 is Activated
5 is pause with: -12 time left
6 is pause with: 988 time left
7 is pause with: 1987 time left
8 is pause with: 2987 time left
9 is pause with: 3986 time left
10 is pause with: 4986 time left
11 is pause with: 5985 time left
12 is pause with: 6985 time left
13 is pause with: 7984 time left
14 is pause with: 8983 time left
15 is pause with: 9983 time left[/lua]

What is wrong with that? What would you want to see?

Please be aware that timers require the rest of the system to be performing at a reasonable rate - if you have a function which takes a very long time to execute and does not return within a reasonable amount of time some timers may have spurious values. [import]uid: 8271 topic_id: 27020 reply_id: 109652[/import]

#3

The problem is during the resume. You did not notice it?Wait for three seconds after the pause it resume again. There will the problem will be. Please run it again.

Thanks [import]uid: 149900 topic_id: 27020 reply_id: 109691[/import]

#4

I still think you’re seeing a combination of issues created by having multiple timers very closely created - but not created at the same time (because that’s impossible) - unpausing non-paused timers and resuming unpaused timers.

I tidied the code up a bit. I think your controlling timers (which have to be factored into the equation) should have counters assigned, so I put those in.

[lua]-- timer test

local function runTimers()
local timers = {}

for count = 1, 15 do
local function enable()
print(count…" is Activated")
timers[count].expired = true
end

timers[count] = timer.performWithDelay(count * 1000, enable, 1)
timers[count].expired = false
end

print(#timers…’ timers created’)

function pause()
for counter = 1, #timers do
if not timers[counter].expired then
print(counter…" is pause with: “…timer.pause(timers[counter])…” time left")
end
end
end
timer.performWithDelay( 5000, pause, 1 )

print(#timers…’ timers paused’) – at this point five timers have started and the rest

local function unpause()
for loop = 1, #timers do
if not timers[loop].expired then
timer.resume(timers[loop])
end
end
end
timer.performWithDelay( 8000, unpause, 1 )

print(#timers…’ timers unpaused’)
end

runTimers()[/lua] [import]uid: 8271 topic_id: 27020 reply_id: 109703[/import]

#5

I tried you code. Sadly it showed the same result. Here is the result
[lua]15 timers created
15 timers paused
15 timers unpaused
1 is Activated
2 is Activated
3 is Activated
4 is Activated
5 is pause with: -3 time left
6 is pause with: 997 time left
7 is pause with: 1997 time left
8 is pause with: 2997 time left
9 is pause with: 3997 time left
10 is pause with: 4997 time left
11 is pause with: 5997 time left
12 is pause with: 6997 time left
13 is pause with: 7997 time left
14 is pause with: 8997 time left
15 is pause with: 9997 time left
5 is Activated
8 is Activated 6 is Activated
9 is Activated 7 is Activated
10 is Activated
11 is Activated
12 is Activated
13 is Activated
14 is Activated
15 is Activated[/lua]
looking at the time remaing during pause it is well seen that the bigger the number the bigger is the delay yet 8 came first before 6 same goes with 9 and 7.

I see your point about closely created timers though. Is this really the issue here? Can something like this be done? Or a recontruction is very well advised here? [import]uid: 149900 topic_id: 27020 reply_id: 109819[/import]

#6

What are you trying to use this code for? Can it really need 15 timers?

My point before was really about the actual (documented) unreliability of timers. They are an underlying system mechanism, not Corona’s, and to have a timer fire at a specific time requires a bunch of things to work in the same order naturally. They are not guaranteed and its down to the internal environment. [import]uid: 8271 topic_id: 27020 reply_id: 109836[/import]

#7

I ask the same as @horacebury… why are there 15 timers being fired in a loop? This just screams out “I’m trying to intentionally break Corona and error-out my app”. I use timer pause and resume frequently, and it works fine. Perhaps your example is a “test case” but in this particular case, I can’t imagine why you’d trigger 15 timers AND 15 local “enable” functions in a loop.

Brent Sorrentino
[import]uid: 9747 topic_id: 27020 reply_id: 109839[/import]

#8

@ swabeh,

Your new approach is MUCH better. :slight_smile: And sorry for being somewhat snippy in my response. It was way too late for me to be writing coherent responses.

The “one timer” solution is not only better for performance and stability, but the further benefit is that you just re-assign new timer executions to the same variable handle (first cancel it, then immediately start the new one). And thus for pausing purposes, you can just pause/resume that handle and everything should work fine.

Brent Sorrentino [import]uid: 9747 topic_id: 27020 reply_id: 110381[/import]

#9

Hey guys,

Hey dont get me wrong I’m not trying to “break” corona. This was my first flow of the game but then I changed it. I guess that style of coding is just a bad way of doing things. What I was trying to do is like a karaoke that lights up in a specific time what I did was to load a set of timing to be activated in a specific time, not random and from a text file. That’s pretty much is it.

Changed it though from a lot timers to using only one timer. Then creates new timer every time the previous one is activated. How’s that sound?

Thanks for the reply guys.
Last question, on the previous post I noticed there is a negative number as it was paused. Why is that?

Thanks,

*Edited [import]uid: 149900 topic_id: 27020 reply_id: 110378[/import]

#10

For more performance I would use one timer repeatedly. The third value to performWithDelay is the number of repetitions - passing 0 makes it loop infinitely, so you don’t need to kill it and recreate, just have it fire over and over again. [import]uid: 8271 topic_id: 27020 reply_id: 110397[/import]