JonathanSchaffer wrote:

support

Hi there, please add to the discussion

JonathanSchaffer wrote:

support

Hi there,
When you're replying to suggestions, please don't simply post ‘support’ or ‘no support’. Instead, be sure to give reasons behind your opinion; why you support or no support. Also, if you can please try to come up with ideas to improve the suggestion. To learn how to be constructive when replying to suggestions, read this sticky.

Sigton

EDIT: Ninja'd by JBS xP

https://scratch.mit.edu/discuss/topic/274129/?page=1#post-2790461

Support, but I also requested for booleans that could avoid this ambiguity too.

Since these blocks you suggested lead to the broadcast being received in any circumstances, I believe this will work out.

repeat until [ v] is broadcasted {
...
} :: control

wait until [ v] is broadcasted :: control

Suggesting broadcast booleans are hard. They are used to simulate the “When I Receive” block, except inside another script, just like key pressing and when backdrop switches to.

wait until is covered here

broadcasts are events, not continuous states; so using variables to track the info you want about them is the way to go
look up the subjects of concurrency and temporal logic
workaround for repeat until here

Support for

(last broadcast) ::events

workaround

when I receive [. . . v]
add [. . .] to [list v]

then

(item (last v) of [list v] :: list) 

walkcycle wrote:

workaround

when I receive [. . . v]
add [. . .] to [list v]

then

(item (last v) of [list v] :: list) 

True, but

go to x: (0) y: (0)

is a workaround

Failord wrote:

The problem with this one is that the scripts need to check for the broadcast at the top of the loop. It can't do that in the scripting in-between.

That would be no different to the current repeat until <> block, which only checks for the condition once per loop and doesn't skip if the condition becomes true halfway through the loop.

stickfiregames wrote:

Failord wrote:

The problem with this one is that the scripts need to check for the broadcast at the top of the loop. It can't do that in the scripting in-between.

That would be no different to the current repeat until <> block, which only checks for the condition once per loop and doesn't skip if the condition becomes true halfway through the loop.

The repeat until _ block requires a boolean, and the message _ received? block is rejected. Merging the two blocks together ensures that the boolean isn't used in ambiguous contexts

Sheep_maker wrote:

stickfiregames wrote:

Failord wrote:

The problem with this one is that the scripts need to check for the broadcast at the top of the loop. It can't do that in the scripting in-between.

That would be no different to the current repeat until <> block, which only checks for the condition once per loop and doesn't skip if the condition becomes true halfway through the loop.

The repeat until _ block requires a boolean, and the message _ received? block is rejected. Merging the two blocks together ensures that the boolean isn't used in ambiguous contexts

I meant the behaviour regarding when it exits the loop would be the same. The blocks would be different, as the OP says.

I'm going to redirect the conversation over to this thread. Although it's not as old as this topic, it has more discussion, a lot of which is quite recent.

Feel free to continue the discussion in the link above.