So, lets say we have a bunch of clones, that all switch to a costume that's multicoloured to detect each other, and you want them to change back. It be nice to make the code of each clone wait until a message is broadcasted to continue, so if you have a counter to count all the clones, once the last one has moved or whatever, it broadcasts said message, making all clone switch back to their original costume.

xlk wrote:

So, lets say we have a bunch of clones, that all switch to a costume that's multicoloured to detect each other, and you want them to change back. It be nice to make the code of each clone wait until a message is broadcasted to continue, so if you have a counter to count all the clones, once the last one has moved or whatever, it broadcasts said message, making all clone switch back to their original costume.

Yes! I support!

xlk wrote:

So, lets say we have a bunch of clones, that all switch to a costume that's multicoloured to detect each other, and you want them to change back. It be nice to make the code of each clone wait until a message is broadcasted to continue, so if you have a counter to count all the clones, once the last one has moved or whatever, it broadcasts said message, making all clone switch back to their original costume.

Couldn't you just use this?:
wait until (clones)>number

yes, but that skips a frame, making it an epileptic blinking spasm of sorts…
So, basically, something more instant.

Why not make a global variable, set it to 0, have a “wait until var = 1” block for all of the clones, then set it to 1 when you're ready for all of them to continue?

I haven't run into this specific problem, but whenever i want a wait until block i use a variable so it's “Wait until variable=” whatever you would have named the brodcast

(Every user has the rights to bump a SUGGESTIONS topic).

No Support, because that block would be like this:

wait until <[ v] received? :: events >

And this Boolean:

<[ v] received? :: events >

Is rejected.

Charles12310 wrote:

(Every user has the rights to bump a SUGGESTIONS topic).

No Support, because that block would be like this:

wait until <[ v] received? :: events >

And this Boolean:

<[ v] received? :: events >

Is rejected.

Not necessarily. This block does not introduce ambiguity, actually. “Wait until” works because it states that it will wait until the NEXT time the broadcast is sent. Support for this.

wait until I receive [broadcast v]::control

wait until I receive [broadcast v]::events

Support. It's certainly easier than doing the variable thing, and it definitely isn't vague.

xlk wrote:

So, lets say we have a bunch of clones, that all switch to a costume that's multicoloured to detect each other, and you want them to change back. It be nice to make the code of each clone wait until a message is broadcasted to continue, so if you have a counter to count all the clones, once the last one has moved or whatever, it broadcasts said message, making all clone switch back to their original costume.

Rather than

when green flag clicked
... :: grey
wait for [broadcast v] :: events
... :: grey

you could just use

when green flag clicked
... :: grey
when I receive [broadcast v]
... :: grey

FancyFoxy wrote:

Charles12310 wrote:

(Every user has the rights to bump a SUGGESTIONS topic).

No Support, because that block would be like this:

wait until <[ v] received? :: events >

And this Boolean:

<[ v] received? :: events >

Is rejected.

Not necessarily. This block does not introduce ambiguity, actually. “Wait until” works because it states that it will wait until the NEXT time the broadcast is sent. Support for this.

Same.



So,i think support,even if this is workaroundable with variables,but it's very annoying to have a lot of variables only for sending and receiving messages.

wait until [message1 v] received::events

Botcho_Otkho wrote:

FancyFoxy wrote:

Charles12310 wrote:

(Every user has the rights to bump a SUGGESTIONS topic).

No Support, because that block would be like this:

wait until <[ v] received? :: events >

And this Boolean:

<[ v] received? :: events >

Is rejected.

Not necessarily. This block does not introduce ambiguity, actually. “Wait until” works because it states that it will wait until the NEXT time the broadcast is sent. Support for this.

Same.



So,i think support,even if this is workaroundable with variables,but it's very annoying to have a lot of variables only for sending and receiving messages.

wait until [message1 v] received::events

Alright then. Could be useful in some instances.

wait until broadcast [ v] received :: events

I assume this could also be useful because it can't be passed by:

repeat until broadcast [ v] is received {
...
} :: events

An if block can be passed by, introducing ambiguity, unless it has an else part.

blazefang21 wrote:

I haven't run into this specific problem, but whenever i want a wait until block i use a variable so it's “Wait until variable=” whatever you would have named the brodcast

Yeah, use variables. Adding a new block is not necessary.

Charles12310 wrote:

An if block can be passed by, introducing ambiguity, unless it has an else part.

An if and if-else would have the same problem.

walkcycle wrote:

blazefang21 wrote:

I haven't run into this specific problem, but whenever i want a wait until block i use a variable so it's “Wait until variable=” whatever you would have named the brodcast

Yeah, use variables. Adding a new block is not necessary.

Charles12310 wrote:

An if block can be passed by, introducing ambiguity, unless it has an else part.

An if and if-else would have the same problem.

The only exception if that if an event happens, it will either power one broadcast or the other. If one broadcast is activated, or the second broadcast is activated, it wouldn't be a problem unless a few exceptions.

I think I'll direct the conversation over here since it has more discussion.

Feel free to continue the conversation in the thread I linked above.