My idea:

repeat () {

} in () secs :: loop control

This would repeat the task () times over the length of () seconds.

Another variation of this would be

repeat {

} for () secs :: loop control

It would repeat over and over for however many seconds.

How does it work:

"But, Mica, what if someone would put the

wait () secs

block in there?“, I hear you asking!

My idea for the ”repeat for () secs" block would be that it checks how many times the normal

repeat ()

end

block would run in the span of () seconds, and runs that many times. That way, the

wait () secs

block would still work.

The “repeat () in () secs” block would be that it divides (number of seconds) by (number of times it repeats), and runs the script once every (time it divided into). Say you put “repeat (10) in (1) secs”. It would divide 1 by 10 (leaving us with 0.1), meaning every 0.1 seconds, it runs the script, meaning the

wait () secs

block would still work.

What this would be useful for:

Off the top of my head, animation.
You want your animation to be a certain frame rate. 30 fps? 24? Solution:

repeat (24) {
 next costume
} in (1) secs :: loop control

You're making a small animation using the "say " block instead of voice acting, and you need some better timing so as to not clutter up your broadcast list. Solution:
Sprite1:

when green flag clicked
repeat {
turn ccw (10) degrees
} for (3) secs :: loop control

Sprite2:

when green flag clicked
wait (3) secs
say [Wow! Nice backflip!] for (2) secs

Supporters:
-Reshiram-
Nambaseking01

Semi-Supporters:
mitzii
venyanwarrior
EZ-Games

Additional Suggestions (regarding these blocks):

Nambaseking01 wrote:

There should be a limit to how low the waiting time should go. Say someone does this:

repeat (1000) {
change [i v] by (1)
add (i) to [itineraryArray v]
} in (0.01) secs :: loop control

That would definitely crash the system.

Support for both, they would be really useful.

Also, I made scratchblocks code for you to use in your post:

repeat () {

} in () secs :: loop control

repeat {

} for () secs :: loop control

“repeat for () seconds” has a workaround:

set [limit v] to ((timer) + ()) // you have to put the number of seconds in the blank input
repeat until <(timer) > (limit)>
...
end

Edit: I was going to say that the workaround will make the page lag when “run without screen resfresh” is turned on, while the block you're suggesting won't, but I eventually decided that it will. You can read imfh's related post in this topic:

imfh wrote:

A run without screen refresh block prevents the screen and everything else from refreshing until it finishes running.
[…]
You should always make sure that Scratch will be able to finish running without screen refresh blocks quickly to prevent that [they meant the lag] from happening.

Because your suggested block can make the program finish the execution in a longer time, it will make the page lag.

-Reshiram- wrote:

I made scratchblocks code for you to use in your post:

repeat () {

} in () secs :: loop control

repeat {

} for () secs :: loop control

Thanks!

Bump

WindOctahedron wrote:

“repeat for () seconds” has a workaround:

set [limit v] to ((timer) + ()) // you have to put the number of seconds in the blank input
repeat until <(timer) > (limit)>
...
end

Edit: I was going to say that the workaround will make the page lag when “run without screen resfresh” is turned on, while the block you're suggesting won't, but I eventually decided that it will. You can read imfh's related post in this topic:

imfh wrote:

A run without screen refresh block prevents the screen and everything else from refreshing until it finishes running.
[…]
You should always make sure that Scratch will be able to finish running without screen refresh blocks quickly to prevent that [they meant the lag] from happening.

Because your suggested block can make the program finish the execution in a longer time, it will make the page lag.

The

repeat ()

end

block works the same.

WindOctahedron wrote:

“repeat for () seconds” has a workaround:

set [limit v] to ((timer) + ()) // you have to put the number of seconds in the blank input
repeat until <(timer) > (limit)>
...
end

-snip-

Semi-support. Support because a lot of programmers are too lazy to make a workaround script.
No support because you could just make the script above, or do this:

reset timer
repeat until <(timer) > []> // here you'd put how long the loop should run
...
end

I use this script often for animating ^^

Semi-Support. It does look like a worthwhile addition, however, this is a kids programming site, and I think it might be a little bit too complicated.

mica43683 wrote:

WindOctahedron wrote:

-snip-

The

repeat ()

end

block works the same.

The same as what?
If you mean the workaround, then you're not entirely correct. If you want to use the simple “repeat” to repeat something for a fixed amount of time, you'll have to do some division by 1/30 (or multiplication by 30). Why not just enter the number of seconds you want to repeat the action for? You can do so in the workaround I suggested.
But yes, they are both loops and it is possible to program one using the other.

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

-snip-

The

repeat ()

end

block works the same.

The same as what?
If you mean the workaround, then you're not entirely correct. If you want to use the simple “repeat” to repeat something for a fixed amount of time, you'll have to do some division by 1/30 (or multiplication by 30). Why not just enter the number of seconds you want to repeat the action for? You can do so in the workaround I suggested.
But yes, they are both loops and it is possible to program one using the other.

I meant the part about running without screen refresh.

venyanwarrior wrote:

Semi-Support. It does look like a worthwhile addition, however, this is a kids programming site, and I think it might be a little bit too complicated.

In what way is it too complicated? Please explain more.

mica43683 wrote:

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

-snip-

The

repeat ()

end

block works the same.

The same as what?
-snip-

I meant the part about running without screen refresh.

Oh, in that case…
The simple “repeat” block can be executed in a single instant (in the cases in which you don't put anything in it that prevents it from doing so, such as the “wait” block), because it is possible to know when the program will end judging only by internal conditions* (in the cases that i mentioned in the brackets/parentheses above). However, the “repeat until” block cannot be executed in a single instant, because the time at which it must stop is always set by external conditions* (that includes the timer).
*“External conditions” means anything other than the number input in the regular “repeat” block.

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

-snip-

The

repeat ()

end

block works the same.

The same as what?
-snip-

I meant the part about running without screen refresh.

Oh, in that case…
The simple “repeat” block can be executed in a single instant (in the cases in which you don't put anything in it that prevents it from doing so, such as the “wait” block), because it is possible to know when the program will end judging only by internal conditions* (in the cases that i mentioned in the brackets/parentheses above). However, the “repeat until” block cannot be executed in a single instant, because the time at which it must stop is always set by external conditions* (that includes the timer).
*“External conditions” means anything other than the number input in the regular “repeat” block.

As I said, it checks how many times the “repeat ()” block would run in the time you input, and runs that many times.

mica43683 wrote:

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

mica43683 wrote:

WindOctahedron wrote:

-snip-

The

repeat ()

end

block works the same.

The same as what?
-snip-

I meant the part about running without screen refresh.

-snip-

As I said, it checks how many times the “repeat ()” block would run in the time you input, and runs that many times.

Oh, okay.

Semi-Support for the following reason(s):

1. The “repeat () in () secs” block would indeed be very useful for animation.
   
2. The “repeat for () secs” block is also useful, but there is a simple workaround:
   

   WindOctahedron wrote:

   set [limit v] to ((timer) + ()) // you have to put the number of seconds in the blank input
   repeat until <(timer) > (limit)>
   ...
   end

mica43683 wrote:

"But, Mica, what if someone would put the

wait () secs

block in there?“, I hear you asking!

My idea for the ”repeat for () secs" block would be that it checks how many times the normal

repeat ()

end

block would run in the span of () seconds, and runs that many times. That way, the

wait () secs

block would still work.

I'm a little concerned about this. Usually “wait () secs” is my go-to for blocks which would cause this loop to not work, but there are many others:

broadcast [ v] and wait

repeat ()

end

ask [] and wait

play sound [ v] until done

The “play sound” block could be especially problematic if another script actively changes the pitch of the block while the loop is running. That might cause your math to break when deciding how many times this loop runs.

And then what if you put something like the “ask” or “forever” blocks in your proposed loop, or even “broadcast and wait” and have it broadcast a “forever” loop? Presumably I'd guess that your proposed loop would check to see if this would happen, and then not run the loop at all if it does.

This all gets into the idea of “Can a program determine whether an algorithm will stop or not before it actually runs the algorithm?” This is known as the Halting Problem, and it was proven that a program cannot determine whether an algorithm will run forever, before actually running the algorithm.

Or would your proposed loop just stop all the code in the broadcasts if it takes longer to run than desired? In that case, I could definitely see some confusion happening with this loop.

I'm not here to reject the suggestion or anything — but this sort of suggestion has come up before, and I still find these sorts of problems, which no one seems to have provided a reasonable solution for yet. (Not to mention that the workarounds are relatively easy and intuitive).

Za-Chary wrote:

mica43683 wrote:

-snip-

I'm a little concerned about this. Usually “wait () secs” is my go-to for blocks which would cause this loop to not work, but there are many others:

broadcast [ v] and wait

repeat ()

end

ask [] and wait

play sound [ v] until done

The “play sound” block could be especially problematic if another script actively changes the pitch of the block while the loop is running. That might cause your math to break when deciding how many times this loop runs.

And then what if you put something like the “ask” or “forever” blocks in your proposed loop, or even “broadcast and wait” and have it broadcast a “forever” loop? Presumably I'd guess that your proposed loop would check to see if this would happen, and then not run the loop at all if it does.

This all gets into the idea of “Can a program determine whether an algorithm will stop or not before it actually runs the algorithm?” This is known as the Halting Problem, and it was proven that a program cannot determine whether an algorithm will run forever, before actually running the algorithm.

Or would your proposed loop just stop all the code in the broadcasts if it takes longer to run than desired? In that case, I could definitely see some confusion happening with this loop.

I'm not here to reject the suggestion or anything — but this sort of suggestion has come up before, and I still find these sorts of problems, which no one seems to have provided a reasonable solution for yet. (Not to mention that the workarounds are relatively easy and intuitive).

What I was thinking is instead of the script strictly running in that length of time, the

repeat () {

} in () secs::control loop

block would divide the number of seconds by the number of times it repeats and use the result as a gap between when the loop finishes running the script it surrounds, and starts running the next time. Say you want it to run 10 times in a second. It would run every 0.1 seconds.
The

repeat {

} for () secs::loop control

block would check how many times the

repeat ()

end

block would run to reach that time, and runs that many times.

mica43683 wrote:

Za-Chary wrote:

mica43683 wrote:

(Bringing back the quote so that it is clear what Za-Chary means by the word “this”.)

"But, Mica, what if someone would put the

wait () secs

block in there?“, I hear you asking!

My idea for the ”repeat for () secs" block would be that it checks how many times the normal

repeat ()

end

block would run in the span of () seconds, and runs that many times. That way, the

wait () secs

block would still work.

I'm a little concerned about this. Usually “wait () secs” is my go-to for blocks which would cause this loop to not work, but there are many others:

-snip-

The “play sound” block could be especially problematic if another script actively changes the pitch of the block while the loop is running. That might cause your math to break when deciding how many times this loop runs.

-snip-

What I was thinking is instead of the script strictly running in that length of time, the

repeat () { 

} in () secs::control loop // Why are you talking about this now?

block would divide the number of seconds by the number of times it repeats and use the result as a gap between when the loop finishes running the script it surrounds, and starts running the next time. Say you want it to run 10 times in a second. It would run every 0.1 seconds.
-snip, because you are repeating what you've already said, and you are not answering to Za-Chary-

Yes, but Za-Chary is adressing the problem of the “repeat for () seconds”.
In the post that he quoted that you snipped, you talked about the “repeat for () seconds”, so why are you talking about “repeat () in () seconds” now?

WindOctahedron wrote:

mica43683 wrote:

Za-Chary wrote:

mica43683 wrote:

(Bringing back the quote so that it is clear what Za-Chary means by the word “this”.)

"But, Mica, what if someone would put the

wait () secs

block in there?“, I hear you asking!

My idea for the ”repeat for () secs" block would be that it checks how many times the normal

repeat ()

end

block would run in the span of () seconds, and runs that many times. That way, the

wait () secs

block would still work.

I'm a little concerned about this. Usually “wait () secs” is my go-to for blocks which would cause this loop to not work, but there are many others:

-snip-

The “play sound” block could be especially problematic if another script actively changes the pitch of the block while the loop is running. That might cause your math to break when deciding how many times this loop runs.

-snip-

What I was thinking is instead of the script strictly running in that length of time, the

repeat () { 

} in () secs::control loop // Why are you talking about this now?

block would divide the number of seconds by the number of times it repeats and use the result as a gap between when the loop finishes running the script it surrounds, and starts running the next time. Say you want it to run 10 times in a second. It would run every 0.1 seconds.
-snip, because you are repeating what you've already said, and you are not answering to Za-Chary-

Yes, but Za-Chary is adressing the problem of the “repeat for () seconds”.
In the post that he quoted that you snipped, you talked about the “repeat for () seconds”, so why are you talking about “repeat () in () seconds” now?

I also spoke about the “repeat for () secs.” I was solving the problem for both, as I noticed it's a problem that applies to both. What I meant was that the “repeat for () secs” block checks how many times it runs instead of running over the span of () seconds.

mica43683 wrote:

WindOctahedron wrote:

-snip-

I also spoke about the “repeat for () secs.” I was solving the problem for both, as I noticed it's a problem that applies to both. What I meant was that the “repeat for () secs” block checks how many times it runs instead of running over the span of () seconds.

Za-Chary already adressed this way of calculating the number of runs:

Za-Chary wrote:

The “play sound” block could be especially problematic if another script actively changes the pitch of the block while the loop is running. That might cause your math to break when deciding how many times this loop runs.
-snip-