I think you should make “when I receive” blocks be able to have boolean/var blocks in the drop-down. This would make it possible to have different x/y positions activate broadcast blocks, without having to enter them manually.

Technically, it is possible to stick booleans or reporters into blocks like when I receive, or when key pressed blocks, but its a sort of hackish way.
In case you want to learn how, here's how:
Download the project - it should be a .sb2 file
Change it to a .zip file and extract it
Open “project.json” or whatever it's called
Scroll down until you find your scripts - then change it (I suggest that you add some reporters or variables so you know what to change it to)
Recompress the files, then rename to .sb2 again
Voíla!

Dominic1 wrote:

Technically, it is possible to stick booleans or reporters into blocks like when I receive, or when key pressed blocks, but its a sort of hackish way.
In case you want to learn how, here's how:
Download the project - it should be a .sb2 file
Change it to a .zip file and extract it
Open “project.json” or whatever it's called
Scroll down until you find your scripts - then change it (I suggest that you add some reporters or variables so you know what to change it to)
Recompress the files, then rename to .sb2 again
Voíla!

Or just extract it without changing the filetype…

Or just use procedures.

+1, I had a lot of problems while creating my games that would require this feature and I needed to do some walkaraounds, this would be much easier and simpler.

You mean this ?

<[message v] recieved?::events>

If so, that’s rejected, could someone get the quote if this is indeed what this is suggesting?

starlightsparker wrote:

You mean this ?

<[message v] recieved?::events>

If so, that’s rejected, could someone get the quote if this is indeed what this is suggesting?

No, they mean something like adding a boolean/var into the broadcast block, like custom blocks work

973131413 wrote:

starlightsparker wrote:

You mean this ?

<[message v] recieved?::events>

If so, that’s rejected, could someone get the quote if this is indeed what this is suggesting?

No, they mean something like adding a boolean/var into the broadcast block, like custom blocks work

Like this?

when I receive [ v] with (a::control) <b::control> ::events hat
say (a::control)

when i receive [goto v] with (x::control) (y::control) ::events hat
go to x: (x::control) y: (y::control)

SpyCoderX wrote:

snip

No, I think the OP means

when I receive <some boolean :: operators>

// and 

when I receive (some variable)

But that doesn't make a ton of sense, when this happens why not use a custom block? The only way this would really work is with string concatenation, otherwise it's not all that useful.

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

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.

Yeah basically

Bump

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

Bump

Im gonna edit the top to make it more clear.

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.

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

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!

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.

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)