Do you even need two timers? Imo there's probably a different, simpler, way to do what you want…

I can't think of any need for two independent built-in timers.

And now that the “when timer” hat block understands variables, I can't think of any good reason to reset the timer…

I'm pretty sure that practically anything you would want to do could be done, quite easily, using a couple of variables that keep track of the single timer, and without ever doing resets of it.

Besides, we already have two timers. One is the “timer” and the other is “days since 2000”. Even that is overkill now. (The only reason I can think of to use them both would be to satisfy some kind of ‘challenge’ to do something without using any variables, where you want to know an absolute date and time that the project was last started, i.e. “86400 * days since 2000 - timer”.)

And, again, you shouldn't need to reset the timer for any reason (again, except maybe to satisfy a variable-free challenge, or something).

You could maybe be able to make timers.

bump

bring up my post (bump)

ZZ9PluralZAlpha wrote:

Workaround for the timers. You can have the current timer, but you can also have timers as variables:-

(Timer 2 :: variables)

and use this script:-

when green flag clicked
forever
wait (1) secs // Change this for how accurate you want the timer to be
change [Timer 2 v] by [1] // Keep this value the same as the other one
end

And if you wanted to pause or stop that timer, make something send a broadcast, then use

when I receive [Stop Timer 2 v]
stop [other scripts in sprite v]

I see where you are going with this, but due to the workaround, half support only.

I think that many of us would prefer not to have to create a whole new sprite just to get a new timer.

dvargasews wrote:

ZZ9PluralZAlpha wrote:

Workaround for the timers. You can have the current timer, but you can also have timers as variables:-

(Timer 2 :: variables)

and use this script:-

when green flag clicked
forever
wait (1) secs // Change this for how accurate you want the timer to be
change [Timer 2 v] by [1] // Keep this value the same as the other one
end

And if you wanted to pause or stop that timer, make something send a broadcast, then use

when I receive [Stop Timer 2 v]
stop [other scripts in sprite v]

I see where you are going with this, but due to the workaround, half support only.

I think that many of us would prefer not to have to create a whole new sprite just to get a new timer.

I never mentioned a new sprite, just a new variable.

ZZ9PluralZAlpha wrote:

dvargasews wrote:

ZZ9PluralZAlpha wrote:

Workaround for the timers. You can have the current timer, but you can also have timers as variables:-

(Timer 2 :: variables)

and use this script:-

when green flag clicked
forever
wait (1) secs // Change this for how accurate you want the timer to be
change [Timer 2 v] by [1] // Keep this value the same as the other one
end

And if you wanted to pause or stop that timer, make something send a broadcast, then use

when I receive [Stop Timer 2 v]
stop [other scripts in sprite v]

I see where you are going with this, but due to the workaround, half support only.

I think that many of us would prefer not to have to create a whole new sprite just to get a new timer.

I never mentioned a new sprite, just a new variable.

Regardless, the timing of scratch is horrendous. No way would this timer be accurate, at all.

Lataliat wrote:

ZZ9PluralZAlpha wrote:

dvargasews wrote:

ZZ9PluralZAlpha wrote:

Workaround for the timers. You can have the current timer, but you can also have timers as variables:-

(Timer 2 :: variables)

and use this script:-

when green flag clicked
forever
wait (1) secs // Change this for how accurate you want the timer to be
change [Timer 2 v] by [1] // Keep this value the same as the other one
end

And if you wanted to pause or stop that timer, make something send a broadcast, then use

when I receive [Stop Timer 2 v]
stop [other scripts in sprite v]

I see where you are going with this, but due to the workaround, half support only.

I think that many of us would prefer not to have to create a whole new sprite just to get a new timer.

I never mentioned a new sprite, just a new variable.

Regardless, the timing of scratch is horrendous. No way would this timer be accurate, at all.

It can be modified where I put the comment. I made the script, but the values are for demonstrative purposes only.

Lataliat wrote:

Regardless, the timing of scratch is horrendous. No way would this timer be accurate, at all.

Actually, it's not that bad. Scratch runs at a pretty steady 30fps.
And if you use the (days since 2000) block, you can actually make a really accurate timer.

Sigton

bump.

scratch team wrote:

Sorry, you have to wait 60 seconds between posts

Semi - Support. There is a workaround, but it does seem slightly complicated

Their are workarounds for this so really no need.

For those saying its work around able, some workarounds may be very complex for newer users


darn 120 second rule

-BeagleLover- wrote:

For those saying its work around able, some workarounds may be very complex for newer users


darn 120 second rule

agreed. While it may be easy for some people, others might not know how to do it.

ZZ9PluralZAlpha wrote:

-BeagleLover- wrote:

For those saying its work around able, some workarounds may be very complex for newer users


darn 120 second rule

agreed. While it may be easy for some people, others might not know how to do it.

Looking at the workarounds people wrote, they looked pretty confusing and complex.

(oh and hi XD)

-BeagleLover- wrote:

ZZ9PluralZAlpha wrote:

-BeagleLover- wrote:

For those saying its work around able, some workarounds may be very complex for newer users


darn 120 second rule

agreed. While it may be easy for some people, others might not know how to do it.

Looking at the workarounds people wrote, they looked pretty confusing and complex.

(oh and hi XD)

Some of them are.

ZZ9PluralZAlpha wrote:

-BeagleLover- wrote:

For those saying its work around able, some workarounds may be very complex for newer users


darn 120 second rule

agreed. While it may be easy for some people, others might not know how to do it.

And they don't need to know, either, because they can just copy the workarounds from this thread

Sigton

-stache- wrote:

JonathanSchaffer wrote:

I have ben making a cloud project lately, and I need two timers for it.
now my suggestion is that

(timer)

be changed to

(timer 1::sensing)

and

(timer 2::sensing)

added. both would function the same as the original, besides having individual times.

But it's workaround-able:

define create timer
add (days since 2000) to [timers v]  // run this block to create a timer and assign it an ID (which is put in the return variable)
set [return v] to (length of [timers v] :: list)

define reset timer (timer id) 
replace item (timer id) of [timers v] with (days since 2000) // this resets a timer given it's ID

define timer (timer id) 
set [return v] to (((days since 2000) - (item (timer id) of [timers v] :: list)) * (86400)) // assigns return the seconds since the timer has been reset/created

If you need this block, you're doing something wrong.

No support because of workaround.

I remember the delay being more like 0.05 instead of 0.01.