(timer)

(timer 1::sensing)

(timer 2::sensing)

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.

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

set [timer 2 v] to (timer) // resets timer 2
((timer) - (timer 2)) // gets the value of timer 2

stickfiregames wrote:

I do quite like dvargasews's idea of being able to create timers when you need them though.

-stache- wrote:

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

-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.

stickfiregames wrote:

I don't see why they should specifically have two timers - why not 3, or 10?

If you want to use multiple timers you can use this - make sure you don't reset the actual timer:

set [timer 2 v] to (timer) // resets timer 2
((timer) - (timer 2)) // gets the value of timer 2

I do quite like dvargasews's idea of being able to create timers when you need them though.

JonathanSchaffer wrote:

stickfiregames wrote:

I don't see why they should specifically have two timers - why not 3, or 10?

If you want to use multiple timers you can use this - make sure you don't reset the actual timer:

set [timer 2 v] to (timer) // resets timer 2
((timer) - (timer 2)) // gets the value of timer 2

I do quite like dvargasews's idea of being able to create timers when you need them though.

but I DO need to reset them BOTH

(Timer 2 :: variables)

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

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

JonathanSchaffer wrote:

who would ever think of that?

JonathanSchaffer wrote:

but I DO need to reset them BOTH

Sigton wrote:

JonathanSchaffer wrote:

who would ever think of that?

-stache-?
That's a great workaround, it's easy to use and allows unlimited timers.

JonathanSchaffer wrote:

but I DO need to reset them BOTH

-stache-'s workaround…

Sigton

JonathanSchaffer wrote:

who would ever think of that?

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.

-stache- 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.

This workaround is inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would say about 101 seconds…

Sigton wrote:

JonathanSchaffer wrote:

who would ever think of that?

-stache-?
That's a great workaround, it's easy to use and allows unlimited timers.

JonathanSchaffer wrote:

but I DO need to reset them BOTH

-stache-'s workaround…

Sigton

-stache- 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 (0.99) secs // Change this for how accurate you want the timer to be. @-stache-, this sorts your delay thing you mentioned.
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.

This workaround is (EDITED: FIXED)no longer inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would (no longer) say about 101 seconds…

-stache- 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.

This workaround is inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would say about 101 seconds…

JonathanSchaffer wrote:

-stache- 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.

This workaround is inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would say about 101 seconds…

wrong it would say 99. (no offense)

ZZ9PluralZAlpha wrote:

-stache- 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 (0.99) secs // Change this for how accurate you want the timer to be. @-stache-, this sorts your delay thing you mentioned.
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.

This workaround is (EDITED: FIXED)no longer inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would (no longer) say about 101 seconds…

Here you go @-stache-. Fixed it for you. In the quote.

-stache- wrote:

JonathanSchaffer wrote:

-stache- 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.

This workaround is inaccurate. The execution of one block takes an extra 0.01 seconds or so. That can change drastically between computers. In 100 seconds, that workaround would say about 101 seconds…

wrong it would say 99. (no offense)

oops but still