"Repeat for ___ secs" blocks

soarroying

removed–be polite

Last edited by spectre_specs (Oct. 14, 2023 22:20:29)

kennaminecraftz

If you dont want to reset timer you could do this instead:

set [time executed] to (timer)
set [execute time] to [number in seconds]
repeat until <(timer) = ((time executed) + (execute time))>
...
end

mumu245

kennaminecraftz wrote:
(#182)
If you dont want to reset timer you could do this instead:
set [time executed] to (timer)
set [execute time] to [number in seconds]
repeat until <(timer) = ((time executed) + (execute time))>
...
end

If another script resets the timer this one will break.

mumu245

kennaminecraftz wrote:
(#182)
If you dont want to reset timer you could do this instead:
✂

set [time executed] to (timer)
set [execute time] to [number in seconds]
repeat until <not <(timer) < ((time executed) + (execute time))>>
. . .
end

Replace “=” with “not <” for better stability.

medians

Bringing this topic up.

lgrov44

No support, very simple workaround.

when green flag clicked
wait (foo) secs
set [Temp v] to [1]

when green flag clicked
set [Temp v] to [0]
repeat until <(Temp) = [1]>
...
end

Last edited by lgrov44 (March 29, 2024 21:15:22)

Minoru07

No support. The workaround is super simple. Because scratch runs at 30 frames per second, you can just use a normal repeat script and multiply the number of seconds you want it to run by 30.

DangerPuppy10

VoltageGames wrote:
No support.
If I have a script like
repeat for 10 seconds,
with a wait 11 seconds in it, what happens?

If I have a script like wait 10 seconds
with blocks inside of it,
what happens when the 10 seconds are up and it's in the middle of the scripts?
Will the rest of the scripts inside continue even though the 10 secs are up? Or will they stop and skip ahead of the repeat?

Malicondi

VoltageGames wrote:
No support.
If I have a script like
repeat for 10 seconds,
with a wait 11 seconds in it, what happens?

then it will repeat the wait 11 seconds once, as thats how much time was allowed.

VoltageGames wrote:
If I have a script like wait 10 seconds
with blocks inside of it,
what happens when the 10 seconds are up and it's in the middle of the scripts?
Will the rest of the scripts inside continue even though the 10 secs are up? Or will they stop and skip ahead of the repeat?

The exact same thing will happen as what happens with repeat until blocks, once the input is met, the loop stops. If the loop stops in the middle of a script, then the rest of the loop will finish and just not start again.

Unithlees3

This is literally how easy the workaround is:

set [timer v] to (x)
broadcast (start timer v)
repeat until <(timer :: variables) = (0)>
…
end

when I receive [start timer v]
repeat until <(timer :: variables) = (0)>
change [timer v] by (-1)
wait (1) secs
end

This is very easy to do; therefore using a block for it is unnecessary.

Edit: I've just realised I've done a post about a different workaround like a year ago. But it really doesn't matter. This one doesn't use the timer.

Last edited by Unithlees3 (March 31, 2024 08:38:45)

thunderclwd

Support.

Unithlees3 wrote:
This is literally how easy the workaround is:
set [timer v] to (x)
broadcast (start timer v)
repeat until <(timer :: variables) = (0)>
…
end

when I receive [start timer v]
repeat until <(timer :: variables) = (0)>
change [timer v] by (-1)
wait (1) secs
end
This is very easy to do; therefore using a block for it is unnecessary.

Edit: I've just realised I've done a post about a different workaround like a year ago. But it really doesn't matter. This one doesn't use the timer.

While you are correct that that would work as a workaround it is counter-intuitive and making this block would help make it simple for new scratchers, as well as decreasing the amount of blocks and therefore the lag (Slightly, not by much, but slightly). Also, I'd like to point out that you'd need o make a new variable for each script you're running simultaneously.
Therefore, for all these reasons, I think that this block should be in scratch.

thunderclwd

SavetheAtlantic wrote:
Little_Mittle12345 wrote:
Stop No support easy workaround. its a HARD WORKAROUND. forever block has a workaround. Can you remove it? or many blocks?
It's nothing. And just because some blocks have an easy workaround doesn't mean that we should remove them, or that we should add more blocks with easy workarounds. With that justification, you could suggest ridiculous blocks like these:
play sound [ v] and then go to x: () y: () ::sound
broadcast [ v] until [var v] = () ::events
You get the point.

I think new scratchers can understand

play sound [ v]

go to x: () y: (0)

But I doubt New scratcher can understand these workarounds as easily as they could understand that or just the “Repeat for (x) seconds” block.

Unithlees3

thunderclwd wrote:
-snip-
While you are correct that that would work as a workaround it is counter-intuitive and making this block would help make it simple for new scratchers, as well as decreasing the amount of blocks and therefore the lag (Slightly, not by much, but slightly). Also, I'd like to point out that you'd need o make a new variable for each script you're running simultaneously.
Therefore, for all these reasons, I think that this block should be in scratch.

The workaround is not hard really. New scratchers can adapt to it.
Putting extra blocks doesn't make noticeable lag
You can make a list to convey every timer if you don't want to waste variables. Like this:

…
set [script id v] to (y)
repeat (script id)
wait (0) secs // Optional – for better manipulation of timer adding
end
add (x) to [timers v]
repeat until <(item (script id) of [timers v] :: list) = (0)> // "script id" referring to the id of the script. Set it to the placement of the timer of the list
if <(x) = (item (script id) of [timers v])> then
broadcast (timer v)
end
…
end
replace item (script id) of [timers v] with () // Or just delete the item entirely if this is the only script utilising this
when I receive [timer v]
repeat until <(x) = (0)>
wait (1) secs
change [x v] by (-1)

Perhaps backpack it for later use.

Last edited by Unithlees3 (April 13, 2024 05:29:13)

TheEpikGamer211

workaround.

repeat (12)
...
wait (1) secs
end

lapisi

TheEpikGamer211 wrote:
(#194)
workaround.
repeat (12)
...
wait (1) secs
end

that just runs the script and then waits a second before doing it again

julmik6478

repeat for (10) seconds{}::control

Workaround:

when green flag clicked
set [wait v] to [0]
wait (10) secs
set [wait v] to [1]
when green flag clicked
repeat until <(wait) = [1]>
...::grey
end

Last edited by julmik6478 (June 9, 2024 08:05:29)

Foldy_TPOT

For the

repeat for (secs::grey) seconds{
…
}::control

there is a workaround:

set [timestamp v] to (days since 2000
set [timer (variable ) v] to (0
repeat until <(timer \(variable\)) \> (secs::grey
…
set [timer (variable ) v] to ((86400)*((days since 2000) - (timestamp))
end

Last edited by Foldy_TPOT (June 12, 2024 15:43:06)

jmdzti_0-0

VoltageGames wrote:
No support.
If I have a script like
repeat for 10 seconds,
with a wait 11 seconds in it, what happens?

If I have a script like wait 10 seconds
with blocks inside of it,
what happens when the 10 seconds are up and it's in the middle of the scripts?
Will the rest of the scripts inside continue even though the 10 secs are up? Or will they stop and skip ahead of the repeat?

Like the repeaat <until>, it does its code each time until the condition is false, which means it would just finish it, or give it another lap.

For the idea, can be easily workarounded, so no support

set [t v] to ((timer)+[seconds])
repeat until <(timer)>(t)>
...::grey
end

Discuss Scratch