leapinleopardstar wrote:

At snap.berkely.edu you can use

run {forever
end} :: stack control

(It's a stack block on Snap, but I'm just bad at scratchblocks )

But I'm talking about Scratch,not Snap or BYOB.

Botcho_Otkho wrote:

awsome_guy_360 wrote:

I suppose the stacking function in this case only applies to the “forever” blocks, correct?

Yep.

Mkay, I guess I support then…

wWSunPandaWw wrote:

Reduces the amount of scripts we need to use, shows extremely New Scratchers that the Forever loop doesn't need to be the end of a project, ideal for many genres, such as animation and games, and something I wish I had suggested.
I support!

Note that:

when gf clicked
forever {
first thing :: grey
} :: control
forever {
second thing :: grey
} :: control

is equivalent to:

when gf clicked
forever
first thing :: grey
end

when gf clicked
forever
second thing :: grey
end

The disadvantage to the suggested form is that it is not particularly clear or explicit. It would also uniquely be the only block in Scratch (with the possible exception of broadcasts) that begins a new thread inside the same script.

I've already posted in this topic, and I support because it would occupy less space.

Semi-support.
I see your thinking of how this could be useful by not confusing new Scratchers.
Isn't it easy enough to just put everything in one forever loop?

I still don't see anything wrong with just using messages. It takes up more space, true, but it's pretty simple.

I'll go with semi-support since I can still see how this suggestion might be useful.

No support. Because then the scripts under the forever block would Be cancelled. You know how the repeat block repeats its thing before going on to the next thing? Well the forever block is like that only it does it forever, so the scripts underneath wouldn't work. I learnt this from a book about scratch.

I'm sorry if I offended anyone. I wasn't trying to be offensive.

I’m not so sure - Scratch runs blocks after each other so that the timing stays how you want it. No support

FuturePr0 wrote:

No support. Because then the scripts under the forever block would Be cancelled. You know how the repeat block repeats its thing before going on to the next thing? Well the forever block is like that only it does it forever, so the scripts underneath wouldn't work. I learnt this from a book about scratch.

I'm sorry if I offended anyone. I wasn't trying to be offensive.

Basically this block executes the “forever” loop and without waiting jumps to the next script,while the forever loop keeps goin'.

TheMonsterOfTheDeep wrote:

Note that:

when gf clicked
forever {
first thing :: grey
} :: control
forever {
second thing :: grey
} :: control

is equivalent to:

when gf clicked
forever
first thing :: grey
end

when gf clicked
forever
second thing :: grey
end

The disadvantage to the suggested form is that it is not particularly clear or explicit. It would also uniquely be the only block in Scratch (with the possible exception of broadcasts) that begins a new thread inside the same script.

Hmm… I see your point.

i populatatate this idea

i think they daond g sg because fwe luhr.

DeleteThisAcount wrote:

i populatatate this idea

i think they daond g sg because fwe luhr.

???

YubNubEwok wrote:

<snip>
Isn't it easy enough to just put everything in one forever loop?

The example I wrote first is pretty clear,but here is the reason:
Imagine there are things that the sprite needs to do separately but at the same moment,for example,playing music,talking and rotate. With everything in the same loop,the events occour in order one before the other.
For example,if I do this:

when green flag clicked
forever
say [Hey!] for (2) secs
turn cw (15) degrees
play sound [soundtrack v] until done
end

It says “Hey!”,then rotates and then plays the soundtrack,while my block is mainly used to occupy less space and in the same time to do more things at once instead of using a lot of “green flag clicked” and then “forever”. Also,with that block,when the soundtrack starts,the other two scripts occour only when the soundtrack is over,when instead the actions should occour WHILE the soundtrack is playing. Hope I was clear.

DeleteThisAcount wrote:

i populatatate this idea

i think they daond g sg because fwe luhr.

What? I can't understand you!

Botcho_Otkho wrote:

YubNubEwok wrote:

<snip>
Isn't it easy enough to just put everything in one forever loop?

The example I wrote first is pretty clear,but here is the reason:
Imagine there are things that the sprite needs to do separately but at the same moment,for example,playing music,talking and rotate. With everything in the same loop,the events occour in order one before the other.
For example,if I do this:

when green flag clicked
forever
say [Hey!] for (2) secs
turn cw (15) degrees
play sound [soundtrack v] until done
end

It says “Hey!”,then rotates and then plays the soundtrack,while my block is mainly used to occupy less space and in the same time to do more things at once instead of using a lot of “green flag clicked” and then “forever”. Also,with that block,when the soundtrack starts,the other two scripts occour only when the soundtrack is over,when instead the actions should occour WHILE the soundtrack is playing. Hope I was clear.

Hmm, that makes sense, but I still don't see a problem with using broadcasts and green flag clicks beside lag. But I thought that was when you have a LOT of those.

YubNubEwok wrote:

Botcho_Otkho wrote:

YubNubEwok wrote:

<snip>
Isn't it easy enough to just put everything in one forever loop?

The example I wrote first is pretty clear,but here is the reason:
Imagine there are things that the sprite needs to do separately but at the same moment,for example,playing music,talking and rotate. With everything in the same loop,the events occour in order one before the other.
For example,if I do this:

when green flag clicked
forever
say [Hey!] for (2) secs
turn cw (15) degrees
play sound [soundtrack v] until done
end

It says “Hey!”,then rotates and then plays the soundtrack,while my block is mainly used to occupy less space and in the same time to do more things at once instead of using a lot of “green flag clicked” and then “forever”. Also,with that block,when the soundtrack starts,the other two scripts occour only when the soundtrack is over,when instead the actions should occour WHILE the soundtrack is playing. Hope I was clear.

Hmm, that makes sense, but I still don't see a problem with using broadcasts and green flag clicks beside lag. But I thought that was when you have a LOT of those.

It's to occupy less space too,as you can see on the main example in the first post of this topic,there's a big difference.

No support because jumping to the next block before the current one has finished is nonstandard behaviour, and attaching that functionality to the forever block might be confusing.

Instead I support having a block that explicitly starts a new thread, like Snap!'s run block. There's also a suggestion for adding this functionality as an option for custom blocks, I'm not going to look for it now but it's called something like “asynchronous/threaded custom blocks” if anyone else wants to look for it.

Once again,

-ShadowOfTheFuture- wrote:

I still don't see anything wrong with just using messages. It takes up more space, true, but it's pretty simple.

Botcho_Otkho wrote:

FuturePr0 wrote:

No support. Because then the scripts under the forever block would Be cancelled. You know how the repeat block repeats its thing before going on to the next thing? Well the forever block is like that only it does it forever, so the scripts underneath wouldn't work. I learnt this from a book about scratch.

I'm sorry if I offended anyone. I wasn't trying to be offensive.

Basically this block executes the “forever” loop and without waiting jumps to the next script,while the forever loop keeps goin'.

Hmmm, I don't see much use for that.

So you're saying the “forever” block kinda starts a new thread that loops the blocks inside it, then moves on to the next block? I'm not sure about that, it doesn't fit well with the logic. The point of the “forever” block is that it does the stuff inside it forever - it wouldn't make sense if it could move on. I think multiple when green flag clicked then forever stacks aren't a bad thing - this suggestion does effectively the same thing as that, but although it saves space it is a lot more confusing. Also, it actually doesn't save that much space - only maybe about a block's worth of space, nothing significant. I don't really support.