Add arguments to the event blocks

Kanyata

What would this accomplish?
A way to transfer data across sprites without variables, and a way to associate a specific value with an event.

Why this?
It is a good alternative to setting a variable when calling an event, which can cause problems if the event is called again before the variable is read.

How would it look?
Something like this:

broadcast [Event v] with Argument 1 [Hi] @delInput @addInput:: events

when I receive [Event v] with (Argument 1 ::events) @delInput @addInput:: events hat
say (Argument 1 ::events) for (2) secs

Other notes
Multiple arguments could be used
You can adjust the amount of arguments used on the block(Unlike custom blocks, which have you set the amount of arguments when creating them.)
As of now, there are 3 supporters

Last edited by Kanyata (Nov. 11, 2025 17:10:34)

d016

so something like

broadcase [message v] with data: [hi!] :: events
when I receive [message v] with data: [local var v] :: events hat
say (local var)

?

Support! This would make things easier.

Last edited by d016 (Nov. 10, 2025 18:02:43)

Kanyata

Yeah basically

Kanyata

Bump

d016

Kanyata wrote:
-snip-

Something like this:
broadcast [ v] with Argument 1 ()

The “Argument 1” implies that you can have more arguments:

broadcast [ v] with arguments: [input 1] [input 2] @delInput @addInput:: events

Kanyata

Bump

Kanyata

Im gonna edit the top to make it more clear.

Quantum-Cat

My first thought is that this idea is really close to global custom blocks.
But if this kind of system was to be implemented, it would be better as the events block suggested in the OP, because it is clear that blocks that influence local variables under the (when I receive broadcast block) affect the sprite they are in not the sprite they are called from.

dizzyboy42

support, but would there be a max argument limit? if not you could do this

broadcast [ v] with arguments: [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input]  @delInput @addInput :: control

d016

dizzyboy42 wrote:

support, but would there be a max argument limit? if not you could do this

broadcast [ v] with arguments: [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input]  @delInput @addInput :: control

I don't think you'ld ever need that many inputs
Even if you could just send one CSV input, broadcast arguments are supported by me!

Kanyata

dizzyboy42 wrote:

support, but would there be a max argument limit? if not you could do this

broadcast [ v] with arguments: [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input] [input]  @delInput @addInput :: control

Yeah there should probably be a max, although I'm not sure what it would be.

dizzyboy42

Kanyata wrote:
Yeah there should probably be a max, although I'm not sure what it would be.

I'd say 6 maybe 7 (no pun intended)

d016

dizzyboy42 wrote:
Kanyata wrote:
Yeah there should probably be a max, although I'm not sure what it would be.
I'd say 6 maybe 7 (no pun intended)

I feel like if there's a max people will keep suggesting “PLEASE INCREASE THE MAX BROADCAST INPUTS!!1!”
It's going to take a while to click all those arrows to get a potentialy damaging amount of inputs anyway.

FreshTheCat

d016 wrote:
dizzyboy42 wrote:
Kanyata wrote:
Yeah there should probably be a max, although I'm not sure what it would be.
I'd say 6 maybe 7 (no pun intended)
I feel like if there's a max people will keep suggesting “PLEASE INCREASE THE MAX BROADCAST INPUTS!!1!”
It's going to take a while to click all those arrows to get a potentially damaging amount of inputs anyway.

Also the 5mb .json limit…

Kanyata

Bump

d016

FreshTheCat wrote:
d016 wrote:
dizzyboy42 wrote:
Kanyata wrote:
Yeah there should probably be a max, although I'm not sure what it would be.
I'd say 6 maybe 7 (no pun intended)
I feel like if there's a max people will keep suggesting “PLEASE INCREASE THE MAX BROADCAST INPUTS!!1!”
It's going to take a while to click all those arrows to get a potentially damaging amount of inputs anyway.
Also the 5mb .json limit…

You can already reach the json limit by putting lots of blocks, and adding an event argument should only add a paragraph of data at most.

I do feel like a max input limit could be like 20 or something that's not too high but hopefully almost no one will use.

Kanyata

FreshTheCat wrote:
d016 wrote:
dizzyboy42 wrote:
Kanyata wrote:
Yeah there should probably be a max, although I'm not sure what it would be.
I'd say 6 maybe 7 (no pun intended)
I feel like if there's a max people will keep suggesting “PLEASE INCREASE THE MAX BROADCAST INPUTS!!1!”
It's going to take a while to click all those arrows to get a potentially damaging amount of inputs anyway.
Also the 5mb .json limit…

What does “the 5mb .json limit” refer to?

medians

Kanyata wrote:
What does “the 5mb .json limit” refer to?

https://en.scratch-wiki.info/wiki/Scratch_File_Format
https://en.scratch-wiki.info/wiki/Project_File_Size

DarthVader4Life

I think it should be called “broadcast and send” to keep with Scratch's desire to be easily understood.

broadcast [message v] and send (var) :: events

Last edited by DarthVader4Life (Nov. 14, 2025 20:26:57)

d016

DarthVader4Life wrote:
I think it should be called “broadcast and send” to keep with Scratch's desire to be easily understood.
broadcast [message v] and send (var) :: events

Nice idea, although I feel like “broadcast” and “send” are synonyms, so then this happens:

broadcast [data v] and send [message name] :: events

I'd use “with data:” instead:

broadcast [message v] with data: [cool idea! support] :: events

Discuss Scratch