xXRedTheCoderXx wrote:

cooldude-222 wrote:

@xxRedTheCoderxx
can you make the block run while running it just sounds better and you don't to code you run code.

That was my logic, but people wanted it to change as it may be confusing to some new to coding and technology.

lisa_wolfgang wrote:

Also, this block would need a new name, as it might confuse people who are new to technology and don't know that “run” means something other than making the Scratch Cat run across the screen.

Mr_PenguinAlex wrote:

Maybe “do while doing” would be better?

Maximouse wrote:

And I think “do while” sounds less weird than “run while”.

define func1
forever
move (20) steps
broadcast [m1 v]
end
when I receive [m1 v]
do something

when green flag clicked
func1 

lovecodeabc wrote:

define func1
forever
move (20) steps
broadcast [m1 v]
end
when I receive [m1 v]
do something

when green flag clicked
func1

See

cooldude-222 wrote:

lovecodeabc wrote:

define func1
forever
move (20) steps
broadcast [m1 v]
end
when I receive [m1 v]
do something

when green flag clicked
func1

See

Did You read the op the point is to not need to use broad casts in custom blocks

lovecodeabc wrote:

Yes but until this is implemented we can do this At Least
Btw the OP is good but we’ll have to wait for implementation.

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

if you make 2 different custom blocks,
and do this:

when green flag clicked
custom block 1 :: custom
custom block 2 :: custom

it would work like this script, right?

No…

Custom blocks run code underneath them when the custom block is done running.

And with forever loops, that would be never.

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

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.

arvepro3579 wrote:

This isn't useful, you can just replace it.

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

if you make 2 different custom blocks,
and do this:

when green flag clicked
custom block 1 :: custom
custom block 2 :: custom

it would work like this script, right?

No…

Custom blocks run code underneath them when the custom block is done running.

And with forever loops, that would be never.

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

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.

arvepro3579 wrote:

This isn't useful, you can just replace it.

cooldude-222 wrote:

@xxRedTheCoderxx I recommend that you add read the entire op to the title

when green flag clicked
f
when green flag clicked
c
define f
...
define c
...

j3r0_plays wrote:

Oh and also i (A strong resistor(Xd) of this idea) just want to point out that this would make scratch soo much laggier… I mean it wouldnt be hard to abuse this to crash scratch….

lovecodeabc wrote:

when green flag clicked
f
when green flag clicked
c
define f
...
define c
...

https://scratch.mit.edu/projects/424934761/
That’s what I mean.

ipaddude wrote:

support
tho like
workarounds mentioned in earlier posts

lovecodeabc wrote:

when green flag clicked
f
when green flag clicked
c
define f
...
define c
...

https://scratch.mit.edu/projects/424934761/
That’s what I mean.