Here are some interesting things about broadcasts that I have found:

1. You can send a broadcast to a clone as pointed out in my project Clones can recieve messages!!!
   
2. Broadcasts are not case-sensitive.
   

   when I receive [a v]

   Will be activated by both
   

   broadcast [a v]

   and
   

   broadcast [A v]

3. You can use broadcasts to emulate switch statements in other languages. For example:
   

   when green flag clicked
   forever
      ask [Enter Command] and wait
       broadcast (answer) and wait
   end

   when I receive [walk v]
   move (10) steps

   when I receive [talk v]
   say [Hello, World!] for (2) secs

   If you enter walk, the sprite will walk, and if you enter talk, the sprite will talk.
   This is demonstrated in my project Dynamic Message Sending
   
   

The next 5 are by @TheLogFather

• The order that broadcasts get received across different sprites/clones is in layer order on the stage at the time of the broadcast (subsequent relayering will not change the order once the broadcast has executed, even if it's before the receivers start running) - the topmost sprite/clone runs any receiver(s) it has first, going on down to the bottom sprite/clone, and finally the stage.
  
  
• The order broadcasts get received for multiple receive scripts within a sprite is in script layer order in the script editing pane, but in the *reverse* order to above - so it starts running the bottom receive script first, moving up to the top one.
  
  
• If you broadcast something while receiver scripts for it are still running then those receiver scripts are terminated and restarted. This is the opposite behaviour to other event hat blocks such as “when key pressed”, “when loudness/timer>”, etc., which will not run again (even if the triggering event happens) while it is still running. (But “when sprite clicked” also behaves like broadcast receivers.)
  
  
• You can use a broadcast to make scripts start running *after* you've done “stop all”. If you put the broadcast just before the “stop all” block, then its receiver scripts get queued to be started up, and they still do that even after “stop all” executes - it's quite a fun way to destroy all clones of a project (as well as reset all effects), without sending any broadcasts to those clones!
  (It also means you can use that to get rid of an “ask-and-wait” block with “stop all”, and still continue the project without having to use the timer method, as I've done in the past…)
  
• Here's an extra one that I've said many times before (and I'm sure most here will be well aware of it) - but just for good measure…
  Never use “broadcast-and-wait” within a custom block that runs without screen refresh. Since a non-refresh script doesn't allow any other scripts to run until it is finished (up to a maximum of half a second), it means that broadcast-and-wait will be sitting around waiting for no reason, because those receiver scripts cannot run until the non-refresh script has finished (or half a second of non-refresh is up).
  

That is all that I have. Please post any others that you know!

I guess I kind of knew in the back of my mind that you could do that thing with the switch statements, but I never really thought about it! Good find!

ChocolatePi wrote:

I guess I kind of knew in the back of my mind that you could do that thing with the switch statements, but I never really thought about it! Good find!

Thanks! Also, do you like my signature?

BookOwl wrote:

ChocolatePi wrote:

I guess I kind of knew in the back of my mind that you could do that thing with the switch statements, but I never really thought about it! Good find!

Thanks! Also, do you like my signature?

Yes, it's good

ChocolatePi wrote:

BookOwl wrote:

ChocolatePi wrote:

I guess I kind of knew in the back of my mind that you could do that thing with the switch statements, but I never really thought about it! Good find!

Thanks! Also, do you like my signature?

Yes, it's good

Thanks!

I don't think that broadcasts are a good way to go about emulating switch statements. The lack of a way to provide a default case is a problem. Additionally, they create extremely messy code.

____                  _____  _______              
|   \  |     |     | |          |    |\    | | /
|___/  |     |     | |__        |    | \   | |/  
|   \  |     |     | |          |    |  \  | |\   
|    | |     |     | |          |    |   \ | | \  
|___/  L____  \___/  |_____  ___|___ |    \| |  \ 
               PRODUCTIONS

Blueinkproductions wrote:

I don't think that broadcasts are a good way to go about emulating switch statements. The lack of a way to provide a default case is a problem. Additionally, they create extremely messy code.

You are right about not having a default, but as far “messy code” I think that it is a matter of personal preference. I think that using broadcasts look better than having a 25+ level nested if/else blocks. For an example, check out my project stack at https://scratch.mit.edu/projects/65692742/

Just keep in mind that although its a cool way to emulate switch statements, whenever you invoke a broadcast call there's always a delay between the invocation and the time when the blocks underneath the “When I receive X” actually start to execute. This means that if you had this inside a loop, for instance, the code would execute much slower than if it was inside a traditional if/else chain.

But if speed isn't much of a concern then it is nice for organizational purposes (if you have a very large if/else chain).

TitaniumBlitz wrote:

Just keep in mind that although its a cool way to emulate switch statements, whenever you invoke a broadcast call there's always a delay between the invocation and the time when the blocks underneath the “When I receive X” actually start to execute. This means that if you had this inside a loop, for instance, the code would execute much slower than if it was inside a traditional if/else chain.

But if speed isn't much of a concern then it is nice for organizational purposes (if you have a very large if/else chain).

Speed wasn't much of a concern in my project Stack and since all the loop did was run through the commands and broadcast them, I think I'm good.

Here are a few other tips about broadcasts…

1. The order that broadcasts get received across different sprites/clones is in layer order on the stage at the time of the broadcast (subsequent relayering will not change the order once the broadcast has executed, even if it's before the receivers start running) - the topmost sprite/clone runs any receiver(s) it has first, going on down to the bottom sprite/clone, and finally the stage.

2. The order broadcasts get received for multiple receive scripts within a sprite is in script layer order in the script editing pane, but in the *reverse* order to above - so it starts running the bottom receive script first, moving up to the top one.

3. If you broadcast something while receiver scripts for it are still running then those receiver scripts are terminated and restarted. This is the opposite behaviour to other event hat blocks such as “when key pressed”, “when loudness/timer>”, etc., which will not run again (even if the triggering event happens) while it is still running. (But “when sprite clicked” also behaves like broadcast receivers.)

4. You can use a broadcast to make scripts start running *after* you've done “stop all”. If you put the broadcast just before the “stop all” block, then its receiver scripts get queued to be started up, and they still do that even after “stop all” executes - it's quite a fun way to destroy all clones of a project (as well as reset all effects), without sending any broadcasts to those clones!
(It also means you can use that to get rid of an “ask-and-wait” block with “stop all”, and still continue the project without having to use the timer method, as I've done in the past…)

EDIT:
5. Here's an extra one that I've said many times before (and I'm sure most here will be well aware of it) - but just for good measure…
Never use “broadcast-and-wait” within a custom block that runs without screen refresh. Since a non-refresh script doesn't allow any other scripts to run until it is finished (up to a maximum of half a second), it means that broadcast-and-wait will be sitting around waiting for no reason, because those receiver scripts cannot run until the non-refresh script has finished (or half a second of non-refresh is up).


Hope someone somewhere finds one or two of these snippets of info useful at some point…

TheLogFather wrote:

Here are a few other tips about broadcasts…

<snip>.

Those are neat! I will add them to the list

BookOwl wrote:

Those are neat! I will add them to the list

OK, great - I've added some bold tags in there to help emphasise the important ‘overview’ sentence for each point.

Blueinkproductions wrote:

I don't think that broadcasts are a good way to go about emulating switch statements. The lack of a way to provide a default case is a problem. Additionally, they create extremely messy code.

In practice I'd probs write it more like

forever
 ask [input] and wait
 if <[switch cases v] contains (answer)> then
  broadcast (join [switch-](answer))
 else
  broadcast [switch-default]
 end
end

NickyNouse wrote:

Blueinkproductions wrote:

I don't think that broadcasts are a good way to go about emulating switch statements. The lack of a way to provide a default case is a problem. Additionally, they create extremely messy code.

In practice I'd probs write it more like

forever
 ask [input] and wait
 if <[switch cases v] contains (answer)> then
  broadcast (join [switch-](answer))
 else
  broadcast [switch-default]
 end
end

That is basically what I do.

B.U.M.P.

BookOwl wrote:

NickyNouse wrote:

Blueinkproductions wrote:

I don't think that broadcasts are a good way to go about emulating switch statements. The lack of a way to provide a default case is a problem. Additionally, they create extremely messy code.

In practice I'd probs write it more like
…

That is basically what I do.

Actually it's probably easier to write like this:

when green flag clicked
forever
    
ask [switch?] and wait
set [var v] to (timer)
broadcast (answer) and wait
if <(var) = (timer)> then
broadcast [default v] and wait
    
end

end

The default statement will run whenever the answer broadcast doesn't exist or is completely empty (ie a floating ‘when I receive’ hat block or none at all). That way you don't even have to bother adding cases to a list.