"Run, and run" E block (READ THE ENTIRE OP BEFORE POSTING)

_ReykjaviK_

_ReykjaviK_ wrote:
There are ways around this, but yes support! It can be helpful! (´▽`ʃ♡ƪ)

Hi! I meant to say that yes you can do workarounds with the available blocks, but not with Custom Blocks.
so yes support

Last edited by _ReykjaviK_ (June 25, 2020 20:06:20)

Waffletron_IX

ioton wrote:
No support. I also think this is a dupe, I can't find it though.
You can just use broadcasts.
b r u h.

-_-

you can’t receive a broadcast in a custom block.

Last edited by Waffletron_IX (June 25, 2020 19:49:06)

xXRedTheCoderXx

ioton wrote:
No support. I also think this is a dupe, I can't find it though.
You can just use broadcasts.
b r u h.

I want you to know that in real life, right now, I an extremely triggered.

BRUH!

First off, if you don't support things for the only reason being there's a workaround, you need to be more constructive and get better reasons for non-supporting/supporting.

Like, so many good suggestions have workarounds, as well as already implemented features!

And, can you read a couple posts? Seriously! Broadcasts do not workaround this, how many times do I have to say it!?

xXRedTheCoderXx wrote:
This block's main use is to make custom blocks able to run multiple scripts.

And, as you may know, custom blocks are different from broadcasts because with custom blocks you can add boolean inputs and string inputs. You could only use those inputs when you define the custom block.

So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.

xXRedTheCoderXx wrote:
DownsGameClub wrote:
xXRedTheCoderXx wrote:
So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.
As a person who hasn't used custom blocks in a while, why would using variables be an issue?
Having to make a variable for every single argument in your custom block is beyond tedious and isn't ideal. Having so many variables could cause your variable list to clutter up.

Also, using variables means that you can only run a custom block when it isn't already running, otherwise your variables will change from the other custom block of the same type running, and you'd be left scratching your head wondering why your game doesn't work.

It's hard to put into words, at least for me, but trust me, using variables restricts you, which could lead to the breaking of your game, as well as clutters your variable list making your game as a whole just that bit more unorganized.

I'm sorry for using exclamation points and such, but seriously, people need to READ.

_ReykjaviK_

ioton wrote:
No support. I also think this is a dupe, I can't find it though.
You can just use broadcasts.
b r u h.

what? Don't just say that…
1. broadcasts don't work, that is the reason for wanting this block
2. yes, there are many ways to do things so it that a reason to non-support? Just because there is an option to use broadcasts (and that doesn't even work..)?

Sorry, but you don't really have any reasoning
note: i'm not mad or anything, we all make mistakes. Just thought i would point that out.

coder2045

Support. I've had to use eight broadcasts and ten scripts in an animation which is a huge load of typing and complications just to have characters fight over a paper airplane and I could just do:

set [marker v] to [0]
run{
line 1:: #0000dd
set [marker v] to [1]
}while running{
run{
wait until <(marker) = [1]>
line 2:: #f00000
set [marker v] to [2]
}while running{
run{
wait until <(marker) = [2]>
line 3:: #f0f000
set [marker v] to [3]
}while running{
...
}:: control
}:: control
}:: control

Last edited by coder2045 (Aug. 14, 2020 17:21:59)

xXRedTheCoderXx

coder2045 wrote:
Support. I've had to use eight broadcasts and ten scripts in an animation just to have characters fight over a paper airplane and I could just do:
set [marker v] to [0]
run{
line 1:: #0000dd
set [marker v] to [1]
}while running{
run{
wait until <(marker) = [1]>
line 2:: #f00000
set [marker v] to [2]
}while running{
run{
wait until <(marker) = [2]>
line 2:: #f0f000
set [marker v] to [3]
}while running{
...
}:: control
}:: control
}:: control

Wow! 10 scripts compressed into 1! Impressive!

Glad to know you'd find this useful.

xXRedTheCoderXx

#Bumpathon 4!

EpicGhoul993

Just in case this block got implemented, will this crash Scratch?

forever
run {
move (1) steps
} while running {
move (-1) steps
} ::control

Waffletron_IX

EpicGhoul993 wrote:
Just in case this block got implemented, will this crash Scratch?
forever
run {
move (1) steps
} while running {
move (-1) steps
} ::control

This shouldn’t, its already possible and would cause the sprite to stay in one spot without any movement.

LankyBox01

Semi-Support
Everything would be easier, but there's even easier workarounds and i don't see how this would fit

MeowyTitan08

you mean an E block, not a branching C block ( ͡° ͜ʖ ͡°)

Support, This is a great idea. This would definitely be helpful when you're doing stuff like @coder2045 said. Why have 10 scripts when you can just have one by implementing a single block?

xXRedTheCoderXx

LankyBox01 wrote:
Semi-Support
Everything would be easier, but there's even easier workarounds and i don't see how this would fit

Bruh.

Read, please!

You can't workaround this!

xXRedTheCoderXx wrote:
This block's main use is to make custom blocks able to run multiple scripts.

And, as you may know, custom blocks are different from broadcasts because with custom blocks you can add boolean inputs and string inputs. You could only use those inputs when you define the custom block.

So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.

xXRedTheCoderXx wrote:
DownsGameClub wrote:
xXRedTheCoderXx wrote:
So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.
As a person who hasn't used custom blocks in a while, why would using variables be an issue?
Having to make a variable for every single argument in your custom block is beyond tedious and isn't ideal. Having so many variables could cause your variable list to clutter up.

Also, using variables means that you can only run a custom block when it isn't already running, otherwise your variables will change from the other custom block of the same type running, and you'd be left scratching your head wondering why your game doesn't work.

It's hard to put into words, at least for me, but trust me, using variables restricts you, which could lead to the breaking of your game, as well as clutters your variable list making your game as a whole just that bit more unorganized.

MeowyTitan08 wrote:
you mean an E block, not a branching C block ( ͡° ͜ʖ ͡°)

Support, This is a great idea. This would definitely be helpful when you're doing stuff like @coder2045 said. Why have 10 scripts when you can just have one by implementing a single block?

Thank for supporting my E block. ( ͡° ͜ʖ ͡°)

Waffletron_IX wrote:
EpicGhoul993 wrote:
Just in case this block got implemented, will this crash Scratch?
forever
run {
move (1) steps
} while running {
move (-1) steps
} ::control
This shouldn’t, its already possible and would cause the sprite to stay in one spot without any movement.

Yup! That is correct, thanks!

Last edited by xXRedTheCoderXx (July 1, 2020 15:20:16)

EpicGhoul993

MeowyTitan08 wrote:
you mean an E block, not a branching C block ( ͡° ͜ʖ ͡°)

*Laughs* Yep!

Yeetoburro1

Mr_PenguinAlex wrote:
I support.
There's not a workaround if you are using custom blocks.

For these reasons, support!

Squashyfishy

SUPPORT! This could be useful if you want to play a sound while running another function in the same script.
It's also kinda similar to an “all at once” C block.

MrFluffyPenguins

it seems that pretty much all no supporters read the OP

kc021

Semi-support.
This would be a great block for multithreading. However, there is a (complicated) workaround. You can create a list to store all of the custom block’s inputs, and then receive all of them through the broadcast. Also, there are some combinations of blocks that would not work. The simplest I can think of would be to run

set x to (0)

and

change x by (5)

parallel. Which one would happen first? If you ran change x by 5 first, then the resulting x position would be 0; if you ran set x to 0 first, the resulting x would be 5.

xXRedTheCoderXx

kc021Also, there are some combinations of blocks that would not work. The simplest I can think of would be to run [scratchblocks wrote:
set x to (0)
and
change x by (5)
parallel. Which one would happen first? If you ran change x by 5 first, then the resulting x position would be 0; if you ran set x to 0 first, the resulting x would be 5.

What do you mean? That works fine, and is already possible.

when green flag clicked
forever
set x to (0)
end

when green flag clicked
forever
change x by (5)
end

When I did that in Scratch “set x to 0” would always go first, no matter it's position, no matter what script was built first, “set x to 0” always went first.

I don't know what algorithm Scratch used to decided for “set x to 0” to go first, but I'm assuming Scratch would use that same algorithm with these blocks.

Maximouse

xXRedTheCoderXx wrote:
I don't know what algorithm Scratch used to decided for “set x to 0” to go first, but I'm assuming Scratch would use that same algorithm with these blocks.

There is no algorithm – you could change the order by editing project.json.

BosenChang

I think @xXTheRedCoderXx should add “please read everything before making a post”

Discuss Scratch