I want to know if I did:

when green flag clicked
forever
    
change [This v] by [1]
end

How large this will be in one second

Depends on program speed

FPS?

According to an experiment I did, the variable will be equal to about 900,000 after one second.

However, this isn't exactly accurate, as any block that causes a delay will slow it down significantly.

Putting the variable in a conditional:

when gf clicked
forever
if <not <>> //Always true
change [var v] by (1)
end
end

reduces the variable down to 500,000.

Putting in a wait block like this:

when gf clicked
forever
change [var v] by (1)
wait (0) secs
end

will make the var only go up to 30.

Really, forever loops are basically arbitrary.

AonymousGuy wrote:

According to an experiment I did, the variable will be equal to about 900,000 after one second.

However, this isn't exactly accurate, as any block that causes a delay will slow it down significantly.

Putting the variable in a conditional:

when gf clicked
forever
if <not <>> //Always true
change [var v] by (1)
end
end

reduces the variable down to 500,000.

Putting in a wait block like this:

when gf clicked
forever
change [var v] by (1)
wait (0) secs
end

will make the var only go up to 30.

Really, forever loops are basically arbitrary.

This is because 0.0= a very small number (in the scratch system)

For me 455327 when I did forever plain.
452802 When I broadcasted the stop
317542 With a if <Not> in it
33 with wait 0 secs inside.

If that is the only script then it will go as fast as your computer can. If you have any other scripts running that change the screen then the loop will convert to it's screen refresh rate which is 30 per second.

But why do seconds stay a second long?

duckboycool wrote:

AonymousGuy wrote:

According to an experiment I did, the variable will be equal to about 900,000 after one second.

However, this isn't exactly accurate, as any block that causes a delay will slow it down significantly.

Putting the variable in a conditional:

when gf clicked
forever
if <not <>> //Always true
change [var v] by (1)
end
end

reduces the variable down to 500,000.

Putting in a wait block like this:

when gf clicked
forever
change [var v] by (1)
wait (0) secs
end

will make the var only go up to 30.

Really, forever loops are basically arbitrary.

This is because 0.0= a very small number (in the scratch system)

No, it's because any wait block (even if it is 0) forces Scratch to draw a new frame, and Scratch runs at 30 fps. The 0.0 > 0 thing was fixed, and anyway the example AonymousGuy gave was with 0 secs, not 0.0.

Also, it depends on your computer speed. I tried the first example on my (very slow) computer, and only got about 30000/second.

duckboycool wrote:

But why do seconds stay a second long?

What do you mean?

CatsUnited wrote:

duckboycool wrote:

But why do seconds stay a second long?

What do you mean?

if it's program speed then why does a second stay a second long while shorter time periods don't

duckboycool wrote:

CatsUnited wrote:

duckboycool wrote:

But why do seconds stay a second long?

What do you mean?

if it's program speed then why does a second stay a second long while shorter time periods don't

Because of the FPS. If I did

wait (0.01) secs

, it would run for about 0.03 seconds.

Depends what's inside the loop, and comp speed, normal speed would be 60FPS