Discuss Scratch

darkness3560
Scratcher
100+ posts

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

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)



someone disagreed with me on the internet
1234abcdcba4321
Scratcher
1000+ posts

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

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

I'd highly appreciate it if you were to follow me. Don't forget to go to my profile.
All of my programming suggestions <— You should really get the suggestions move back to the suggestions forum!
Five hundred posts! I never expected to get up there… In only 2-3 months.
Does anyone know what a signature is? I mean, I've already seen 6-7 people get confused.
darkness3560
Scratcher
100+ posts

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

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?


someone disagreed with me on the internet
AonymousGuy
Scratcher
1000+ posts

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

Those two blocks were mentioned elsewhere…
0bitasy0
Scratcher
76 posts

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

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
Scratcher
1000+ posts

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

Support neither. Both workaroundable and actually more confusing for me

'17 rickoid

bf97b44a7fbd33db070f6ade2b7dc549
1234abcdcba4321
Scratcher
1000+ posts

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

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.

I'd highly appreciate it if you were to follow me. Don't forget to go to my profile.
All of my programming suggestions <— You should really get the suggestions move back to the suggestions forum!
Five hundred posts! I never expected to get up there… In only 2-3 months.
Does anyone know what a signature is? I mean, I've already seen 6-7 people get confused.
ProdigyZeta7
Scratcher
1000+ posts

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

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
Scratcher
100+ posts

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

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.


someone disagreed with me on the internet
Photoguy77
Scratcher
100+ posts

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

Support!

-Photoguy77

“Without enjoying, one will never truly learn” ~Flome

“Finding happiness starts in you” ~ProdigyZeta7

mitchboy
Scratcher
1000+ posts

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

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

Capsicum annuum.
Failord
Scratcher
1000+ posts

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



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.

Thanks for the ride, Scratch Team and community! Unfortunately, the time has come for me to move on from Scratch, so I'll no longer be using the forums. Thanks again, and farewell!
Invisible text! This will show you if a profile I claim to be mine IS mine. Just remember to visit the profile and see if I confirmed in the comments.
For old time's sake, see the revolutionary Laser Battle 2.0! Also see Unstoppable Game!

And no, the evil kumquats didn't alter my signature…
AonymousGuy
Scratcher
1000+ posts

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

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
Scratcher
1000+ posts

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

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.

tosh · slowly becoming a grown-up adult and very confused about it
Failord
Scratcher
1000+ posts

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

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.

Thanks for the ride, Scratch Team and community! Unfortunately, the time has come for me to move on from Scratch, so I'll no longer be using the forums. Thanks again, and farewell!
Invisible text! This will show you if a profile I claim to be mine IS mine. Just remember to visit the profile and see if I confirmed in the comments.
For old time's sake, see the revolutionary Laser Battle 2.0! Also see Unstoppable Game!

And no, the evil kumquats didn't alter my signature…
TheUltimateCoder3279
Scratcher
18 posts

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

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)


Click!
Click!
Which one do you click?
Love and favorite my projects!
NeonFrostburn
Scratcher
100+ posts

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

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

WOL FY!
stickfiregames
Scratcher
1000+ posts

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

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)











If you can read this, my signature cubeupload has been eaten by an evil kumquat!




or you just used Inspect Element, you hacker

;
jokebookservice1
Scratcher
1000+ posts

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

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.

Powered by DjangoBB

Standard | Mobile