Solutions and viable alternatives to the <broadcast [] received> boolean

darkness3560

Many have suggested a <broadcast received> boolean. However, it's really ambiguous and confusing. As jvvg said:

There is way too much ambiguity to how this would work. Would it return true of the broadcast was fired at any point since the project was created, since the green flag was clicked, since something else was broadcasted, etc.? If you really want to do something like this, instead just make a variable and set it to 1 and use the equals block.

I have 2 solutions.
Solution 1:
A (last broadcast) reporter block which contains the name of the last broadcasted message.

This block gives you the last broadcasted message so you can do things like "wait until <(last broadcast) = >".

Supporters:
1234abcdcba4321

Solution 2:
2 blocks which are made to work with broadcasts: the "wait until received“ and the ”repeat until received" blocks.

As you can see, they're both “until” blocks and none of that crazy boolean stuff is used. A broadcast is an event, and these blocks are designed for that.

Supporters:
1234abcdcba4321
0bitasy0

You can support none, one, or both. Feel free to point out problems or other solutions!

Last edited by darkness3560 (Nov. 28, 2013 02:42:43)

1234abcdcba4321

I support both. (But I still think a boolean would be best.)

darkness3560

1234abcdcba4321 wrote:
I support both. (But I still think a boolean would be best.)

Thanks for the support! The reason a boolean wouldn't work is because a broadcast is an event. A boolean reporter doesn't measure events. Imagine your boolean being put inside an if block to make "if < received>". What would that do?

AonymousGuy

Those two blocks were mentioned elsewhere…

0bitasy0

The first might be a little confusing to begin with for newer/younger scratchers, as it has to do with recording names of methods and giving them as strings, which are different. But the 2nd solution you suggested I support entirely.

Firedrake969

Support neither. Both workaroundable and actually more confusing for me

1234abcdcba4321

Oh, I just noticed a problem with repeat until.
The current repeat until blocks only check for the status at the end of every loop. So that still won't work.

ProdigyZeta7

I like the first suggestion, but I still think it's kinda pointless to detect a broadcast when there are a million workarounds.

Last edited by ProdigyZeta7 (Nov. 28, 2013 04:26:30)

darkness3560

1234abcdcba4321 wrote:
Oh, I just noticed a problem with repeat until.
The current repeat until blocks only check for the status at the end of every loop. So that still won't work.

Maybe it could check continuously and keep running the script inside the loop until it reaches the end of the script.

Photoguy77

Support!

mitchboy

darkness3560 wrote:
2 blocks which are made to work with broadcasts: the "wait until received“ and the ”repeat until received" blocks.

wait until <(variable) = (certain number)>

repeat until <(variable) = (certain number)>

end

Failord

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.

AonymousGuy

0bitasy0 wrote:
The first might be a little confusing to begin with for newer/younger scratchers, as it has to do with recording names of methods and giving them as strings, which are different. But the 2nd solution you suggested I support entirely.

Maybe it could be a boolean, like <last broadcasted message is [message v]>
(sorry, I'm too lazy to make mock-up art / scratchblocks

)

Last edited by AonymousGuy (Nov. 28, 2013 23:47:51)

blob8108

Failord wrote:
It can't do that in the scripting in-between.

As long as the script doesn't yield (doesn't contain any loops), or you put the script in a custom block set to “run without screen refresh”, the script won't get interrupted while it's running.

Failord

blob8108 wrote:
Failord wrote:
It can't do that in the scripting in-between.
As long as the script doesn't yield (doesn't contain any loops), or you put the script in a custom block set to “run without screen refresh”, the script won't get interrupted while it's running.

It wouldn't interrupt the blocks in-between, it just wouldn't be able to check for broadcasts in-between. Which means it pretty much wouldn't work anyway.

TheUltimateCoder3279

Another way could be this: (Make sure the variable is for all sprites.)

when green flag clicked
set [ (variable)] to [0]

When you want to broadcast something, do this on the same sprite:

set [ (variable)] to [1]

On another sprite: do this!

when green flag clicked
forever


if <(variable) = [1]>
say [Broadcast complete!] for (2) secs
else
say [This broadcast has not yet been done.] for (1337) secs
end
end

Hope this helped!

Last edited by TheUltimateCoder3279 (Dec. 28, 2016 18:02:20)

NeonFrostburn

Shouldn't the “last broadcast” block be a <> one instead of a () one and in sensing?

stickfiregames

I support both as well as

(time since last [message1 v] :: events)

Failord wrote:
blob8108 wrote:
Failord wrote:
It can't do that in the scripting in-between.
As long as the script doesn't yield (doesn't contain any loops), or you put the script in a custom block set to “run without screen refresh”, the script won't get interrupted while it's running.

It wouldn't interrupt the blocks in-between, it just wouldn't be able to check for broadcasts in-between. Which means it pretty much wouldn't work anyway.

When a broadcast is sent, it could look for any wait/repeat until broadcast blocks that are running, and tell them to continue on the next tick or when they reach the end of the loop respectively. It wouldn't be that different to how broadcast hat blocks work: they don't constantly check for the broadcast, instead the broadcast triggers the scripts when it is sent.

Last edited by stickfiregames (Dec. 28, 2016 18:44:49)

jokebookservice1

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.

Actually, not really. Scratch's source code has the ability to remember what has been broadcasted, so it can still check, at the top, when it gets there, if a broadcast has been received since the last check.

JonathanSchaffer

support

Discuss Scratch