just changes the speed of the script

set speed to [ v] :: events // fast, normal or slow

just like in scratch jr

How can this be useful?

How about cloud variables?

Moduds wrote:

How about cloud variables?

What about them

Knightbot63 wrote:

How can this be useful?

By making the script faster

Batyadzoantipelnavia wrote:

By making the script faster

How can this be useful on scripts?

Nah, There's way too much work arounds including

glide () secs to x: (0) y: (0)

Batyadzoantipelnavia wrote:

What about them

Scratch Wiki wrote:

If both Scratchers have a reasonably fast Internet connection (DSL/Cable), and there are no restrictive firewalls on the computers/network, updates should be transmitted in milliseconds. However, many computers have firewall software running in them, and if the firewall software blocks outgoing connections to TCP port 531 and TCP port 843, the time-lag becomes one-second.

Wouldn't that affect?

cs3868895 wrote:

Nah, There's way too much work arounds including

glide () secs to x: (0) y: (0)

no

the block speeds up the script

Knightbot63 wrote:

How can this be useful on scripts?

I made a test script for HwS and it was historically slow. If I would like to add it for a project I would have to wait for it to load and it's soo boring.
By the way it was for filling in squares.

I believe this wouldn't work, as script currently runs at (idk exactly how much) frames, and you cant really get shorter then a frame in computers

otherwise, this would literally just be a “activate turbo mode” block, which simply runs without refreshign the screen (or something like that)

gdfsgdfsgdfg wrote:

cs3868895 wrote:

Nah, There's way too much work arounds including

glide (120) secs to x: (0) y: (0)

no

the block speeds up the script

blablablahello wrote:

I believe this wouldn't work, as script currently runs at (idk exactly how much) frames, and you cant really get shorter then a frame in computers

otherwise, this would literally just be a “activate turbo mode” block, which simply runs without refreshign the screen (or something like that)

Then You have why this codeblock works also let me pull another work around-
(the one is where time doesn't matter but it slows down the sprite) And also you can make it slow too-

I support because it makes no sense that scratch jr has features not on normal scratch

cookieclickerer33 wrote:

I support because it makes no sense that scratch jr has features not on normal scratch

Huh, I think the fast normal slow is supposed to teach kids about the many speeds, just why do we need it if we have glide blocks and such-

No support definitely No support.

cookieclickerer33 wrote:

I support because it makes no sense that scratch jr has features not on normal scratch

There's a big difference between Scratch JR and Scratch 3.0, so not everything there could apply on Scratch.

Moduds wrote:

cookieclickerer33 wrote:

I support because it makes no sense that scratch jr has features not on normal scratch

There's a big difference between Scratch JR and Scratch 3.0, so not everything there could apply on Scratch.

I think a simplified version of something should not have things that can’t be archived on the normal version

cookieclickerer33 wrote:

Moduds wrote:

cookieclickerer33 wrote:

I support because it makes no sense that scratch jr has features not on normal scratch

There's a big difference between Scratch JR and Scratch 3.0, so not everything there could apply on Scratch.

I think a simplified version of something should not have things that can’t be archived on the normal version

While a feature is implemented on Scratch JR, It can destroy Scratch 3.0, Since, Scratch 3.0 Is much larger than JR, like how I've mentioned above:

Moduds wrote:

Batyadzoantipelnavia wrote:

What about them

Scratch Wiki wrote:

If both Scratchers have a reasonably fast Internet connection (DSL/Cable), and there are no restrictive firewalls on the computers/network, updates should be transmitted in milliseconds. However, many computers have firewall software running in them, and if the firewall software blocks outgoing connections to TCP port 531 and TCP port 843, the time-lag becomes one-second.

Wouldn't that affect?

Scratch 3.0 have cloud variables, and also server which they would just shut down (AFAIK), but Scratch JR does? - No, so I don't see any reason that the speed block would harm Scratch JR, but It still can harm Scratch 3.0.

Work arounds?

forever
Run without screen refresh :: more blocks
end
define Run without screen refresh
...

...
wait [0] secs
...
wait [0] secs
...

and I'm pretty sure you cant make scripts run any faster than it already does (except for RWSR)

8bitrkt wrote:

Work arounds?

forever
Run without screen refresh :: more blocks
end
define Run without screen refresh
...

...
wait [0] secs
...
wait [0] secs
...

and I'm pretty sure you cant make scripts run any faster than it already does (except for RWSR)

Doesn't that just run it at normal speed

Batyadzoantipelnavia wrote:

Doesn't that just run it at normal speed

Custom blocks that runs without screen refresh could run functions in a single frame if that's what you mean? - Also, perhaps, the “0” in the wait block was just a placeholder

8bitrkt wrote:

Work arounds?

forever
Run without screen refresh :: more blocks
end
define Run without screen refresh
...

...
wait [0] secs
...
wait [0] secs
...

and I'm pretty sure you cant make scripts run any faster than it already does (except for RWSR)

wrong

it runs at normal speed

and no option for fast