I think we should have a new block that can run scripts inline, but not block the main script. Here's an example of what it could look like:

new thread {

} ::control

And here's an example of how it would work:

when flag clicked
switch costume to (costume1 v)
new thread {
forever
glide (pick random (2) to (7)) secs to x: (10) y: (20)
end
} ::control
new thread {
repeat (3)
wait (1) seconds
next costume
end
} ::control
say [This is cool!] for (5) seconds

Basically, the first forever loop is ran, but while it is running, it immediately continues the script following it. The same goes for the repeat loop.

Sorry, but I don't support.
Scratch is supposed to be for beginners, and the concept of threading is not only kinda complex but also can create so many possible bugs that it really isn't worth it.
For instance, many game engines that have multithreading have many limitations put on secondary threads.For example, many game engines don't allow you to move/modify objects on a secondary thread to prevent issues. This would be pretty hard to enforce in Scratch, because it is supposed to be an extremely fault tolerant engine (and moving/modifying sprites in Scratch is pretty important).
Also, it creates many issues, such as this:

when green flag clicked
set [yay v] to [0]
new thread{
set [yay v] to [1]
}::control
new thread{
if <(yay) = [1]> then
say [Yay!]
end
}::control

This would create what is called a “race condition” in which 2 possible outcomes are possible:
a. The variable is changed before it is checked, and the sprite says “Yay!”
b. The variable is changed after it is checked, and the sprite says nothing.
This would be very confusing for new Scratchers, since they would be confused as to why the sprite sometimes says something and why it sometimes doesn't.

In conclusion, this would create too much confusion, and so I don't think it should be added.

how is this dfferent from a custom block with run without screen refresh on?

I_wantasheep wrote:

how is this dfferent from a custom block with run without screen refresh on?

It's not meant to be an “all at once” block — it's meant to be a “run at the same time” block. A workaround for this block would be to use broadcasts and run multiple scripts at the same time with the same broadcast:

when green flag clicked
switch costume to [costume1 v]
broadcast [new thread v]
say [This is cool!] for (5) secs

when I receive [new thread v]
forever
glide (pick random (2) to (7)) secs to x: (10) y: (20)
end

when I receive [new thread v]
repeat (3)
wait (1) secs
next costume
end

That may be more cluttered though, depending on who you ask.

I_wantasheep wrote:

how is this dfferent from a custom block with run without screen refresh on?

Run Without Screen Refresh blocks don't allow for time-consuming actions, like wait for seconds or a forever loop. For example:

when flag clicked
switch costume to (costume1 v)
move around ::custom
change costumes ::custom
say [This is cool!] for (5) seconds
define move around //without screen refresh
forever
glide (pick random (2) to (7)) secs to x: (10) y: (20)
end
define change costumes //without screen refresh
repeat (3)
wait (1) seconds
next costume
end

The custom blocks will run, but it will cause a lot of lag because it tries to complete in one frame.

ploppiedog wrote:

when green flag clicked
set [yay v] to [0]
new thread{
set [yay v] to [1]
}::control
new thread{
if <(yay) = [1]> then
say [Yay!]
end
}::control

This would create what is called a “race condition” in which 2 possible outcomes are possible:
a. The variable is changed before it is checked, and the sprite says “Yay!”
b. The variable is changed after it is checked, and the sprite says nothing.
This would be very confusing for new Scratchers, since they would be confused as to why the sprite sometimes says something and why it sometimes doesn't.

The first “new thread” block will always run first, before the next one.

CSwitch wrote:

ploppiedog wrote:

when green flag clicked
set [yay v] to [0]
new thread{
set [yay v] to [1]
}::control
new thread{
if <(yay) = [1]> then
say [Yay!]
end
}::control

This would create what is called a “race condition” in which 2 possible outcomes are possible:
a. The variable is changed before it is checked, and the sprite says “Yay!”
b. The variable is changed after it is checked, and the sprite says nothing.
This would be very confusing for new Scratchers, since they would be confused as to why the sprite sometimes says something and why it sometimes doesn't.

The first “new thread” block will always run first, before the next one.

then it's not simultaneous

I_wantasheep wrote:

then it's not simultaneous

It actually is, because in this example:

when green flag clicked
set [yay v] to [0]
new thread{
set [yay v] to [1]
}::control
new thread{
if <(yay) = [1]> then
say [Yay!]
end
}::control

1. “yay” is set to 0
2. “new thread” block reached
3. “yay” set to 1 and second “new thread” block reached
4. Check “yay” = 1, true
5. Say “Yay!”

Or in my example from earlier:

when flag clicked
switch costume to (costume1 v)
new thread {
forever
glide (pick random (2) to (7)) secs to x: (10) y: (20)
end
} ::control
new thread {
repeat (3)
wait (1) seconds
next costume
end
} ::control
say [This is cool!] for (5) seconds

1. switch to costume “costume1”
2. “new thread” block reached
3. forever loop and second “new thread” block reached
4. glide block in forever loop and repeat loop and say “This is cool!” for the next 5 seconds

CSwitch wrote:

I_wantasheep wrote:

then it's not simultaneous

It actually is, because in this example:

when green flag clicked
set [yay v] to [0]
new thread{
set [yay v] to [1]
}::control
new thread{
if <(yay) = [1]> then
say [Yay!]
end
}::control

1. “yay” is set to 0
2. “new thread” block reached
3. “yay” set to 1 and second “new thread” block reached
4. Check “yay” = 1, true
5. Say “Yay!”

that does the same thing as the code without thread blocks

I_wantasheep wrote:

that does the same thing as the code without thread blocks

See the second example I just added.

CSwitch wrote:

I_wantasheep wrote:

that does the same thing as the code without thread blocks

See the second example I just added.

that one's a better example

SIT3

Having it as a C block looks kind of cluttered. I think (maybe) a better way to implement it would be to have it as a normal block with a hat block “attached” to it, with a line connecting the two similarly to a comment.

Kind of like this (I can't 100% recreate my idea here)

when green flag clicked
new thread :: control // pretend there is a line between this block and the hat block
say [I'm spinning!] for (5) secs

 :: hat control
forever
turn cw (15) degrees
end

knowitall1237 wrote:

Kind of like this (I can't 100% recreate my idea here)

when green flag clicked
new thread :: control // pretend there is a line between this block and the hat block
say [I'm spinning!] for (5) secs

 :: hat control
forever
turn cw (15) degrees
end

This makes it feel more cluttered.

CSwitch wrote:

knowitall1237 wrote:

-snip-

This makes it feel more cluttered.

Well, it depends. If you don't mind long scripts, then it's better as a C block. If you like spreading your scripts out horizontally, then it would be better as a hat block. Plus, I think the hat block would make its function a bit more clear to beginners (by visualizing that it's running the script as if it was a separate line of code)

knowitall1237 wrote:

CSwitch wrote:

knowitall1237 wrote:

-snip-

This makes it feel more cluttered.

Well, it depends. If you don't mind long scripts, then it's better as a C block. If you like spreading your scripts out horizontally, then it would be better as a hat block. Plus, I think the hat block would make its function a bit more clear to beginners (by visualizing that it's running the script as if it was a separate line of code)

Wait, that actually makes a lot of sense! I like this better!