scratch978654 wrote:

Semi-support because it would be a great and useful feature (especially for NSes) but it would lag out Scratch.

HTML-Fan wrote:

Did red said that or do you guess that that's what you assume?

Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Do stuff here
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control

DataLabGames wrote:

Wouldn't people be able to create lag with this block, by repeating it again and again and again and… Well you get the idea.

<snip>

define forkbomb
run {
forkbomb
} while running {
forkbomb
} :: control

DataLabGames wrote:

Wouldn't people be able to create lag with this block, by repeating it again and again and again and… Well you get the idea.

Note: the following script is shortened.

Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Run {
Do stuff here
} while running {
Do stuff here
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control
} :: control

broadcast [message1 v]

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

when I receive [message1 v]
Do stuff here

PkmnQ wrote:

Even worse:

define forkbomb
run {
forkbomb
} while running {
forkbomb
} :: control

define forkbomb
broadcast [forkbomb v]
broadcast [forkbomb v]

when I receive [forkbomb v]
forkbomb

xXRedTheCoderXx wrote:

scratch978654 wrote:

Semi-support because it would be a great and useful feature (especially for NSes) but it would lag out Scratch.

No it wouldn't. I don't think it will, at least. What makes you say that?

HTML-Fan wrote:

Did red said that or do you guess that that's what you assume?

I did.

Run {
broadcast [message1] and wait
recursion :: custom-stack
wait (5) secs
ask [Lag now?] and wait
recursion :: custom-stack
} while running {
recursion :: custom-stack
forever
wait (6) secs
recursion :: custom-stack
end
} :: control

And the custom block is
define recursion
repeat (10)
recursion
end

scratch978654 wrote:

For example.

Run {
broadcast [message1] and wait
recursion :: custom-stack
wait (5) secs
ask [Lag now?] and wait
recursion :: custom-stack
} while running {
recursion :: custom-stack
forever
wait (6) secs
recursion :: custom-stack
end
} :: control

And the custom block is
define recursion
repeat (10)
recursion
end

when flag clicked
broadcast [message2 v]
recursion
forever
wait (6) secs
recursion

when I receive [message2 v]
broadcast [message1 v] and wait
recursion
wait (5) secs
ask [Lag now?] and wait
recursion

define recursion
repeat (10)
recursion

EpicGhoul993 wrote:

The app-breaking scripts are always there. However, like how you guys present, they are all made intentionally(idk if I wrote it right). We should see both the good and the bad of the block, as every other ‘kinda duplicated’ blocks has the same problems.
Sorry for bad English

Posting content deliberately designed to crash the Scratch website or editor;

when green flag clicked
Run {
set [foo v] to [1]
} while running {
set [foo v] to [2]
} :: control

TheColaber wrote:

Question… If someone said…

when green flag clicked
Run {
set [foo v] to [1]
} while running {
set [foo v] to [2]
} :: control

would foo be 1 or 2?

when green flag clicked
set [foo v] to [1]

when green flag clicked
set [foo v] to [2]

Maximouse wrote:

scratch978654 wrote:

For example.

Run {
broadcast [message1] and wait
recursion :: custom-stack
wait (5) secs
ask [Lag now?] and wait
recursion :: custom-stack
} while running {
recursion :: custom-stack
forever
wait (6) secs
recursion :: custom-stack
end
} :: control

And the custom block is
define recursion
repeat (10)
recursion
end

—

when green flag clicked
forkbomb 1:: custom
define forkbomb 1
forever
forkbomb 1::custom
forkbomb 2::custom
end
define forkbomb 2
forever
forkbomb 2::custom
forkbomb 1:: custom
end

Mr_PenguinAlex wrote:

aren't branching C blocks called “E blocks”

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

aren't branching C blocks called “E blocks”

According to the wiki, they are called branching c blocks.

xXRedTheCoderXx wrote:

TheColaber wrote:

Question… If someone said…

when green flag clicked
Run {
set [foo v] to [1]
} while running {
set [foo v] to [2]
} :: control

would foo be 1 or 2?

Well, when I did this:

when green flag clicked
set [foo v] to [1]

when green flag clicked
set [foo v] to [2]

Foo became 2, no matter the position of the scripts.

So I think in this block, it'll just run code at the top first.

scratch978654 wrote:

Well, if it ran the script at the top it isn't really “running a script while running another” is it?

Maximouse wrote:

scratch978654 wrote:

Well, if it ran the script at the top it isn't really “running a script while running another” is it?

Because two scripts can't actually run at the same time, it would run a bit of the topi script, then the bottom one, and the top one again and so on.

Maximouse wrote:

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

aren't branching C blocks called “E blocks”

According to the wiki, they are called branching c blocks.

I couldn't find that on the wiki, but I imagine the if-else block could be called “branching” because it runs one input or the other. This one always runs both, so it isn't really “branching”.