Section 1: Is this topic rejected? (Short answer: No)

This suggestion is not a rejected suggestion. Keep in mind that a boolean block that reports true or false if a message has been received is rejected, because it has way too many problems. See this quote in the list of rejected suggestions:

Za-Chary wrote:

1.1 “Broadcast received” boolean block
The block below would allow a project to detect when a broadcast is sent. But, there is a lot of ambiguity on how this would work. Would it return true if the broadcast was fired since the project was created, since the green flag was clicked, or since something else was broadcasted? The workaround is simple: use variables that change when a broadcast is received, then use the “equals” block.

However, the blocks “repeat until broadcast received” and “wait until broadcast received” are NOT rejected; you can discuss them on this topic.

Section 2: What are you suggesting?
I am suggesting two new blocks:

repeat until [broadcast v]

end

wait until [broadcast v]

The first one repeats itself until that message is broadcasted.The second one waits until the message is broadcasted.
Because you can do

broadcast (join [] []) 

by dragging things into the broadcast dropdown menu, you should also be able to drag things into these new blocks too:

repeat until (join [] [])

end

wait until (join [] [])

If the broadcast doesn't exist, then the most obvious solution would to keep repeating indefinitely or waiting indefinitely.
But wait! Is there a workaround?
Yes! There is!
Section 3: But why add this block if there is a workaround?
Argument 1: The workaround isn't as simple as you think.
Any workaround involves variables. Variables are great. But in scratch, because of the block-building environment, too many variables can cause problems. It isn't fun scrolling through a large list of variables in a big and/or complex project just to get the right one. Message broadcasts are made to not have to do their workarounds, which will mean more variables. If message broadcasts are there to make the quality of life easier for scratchers who don't want to do these workarounds, then why not make them more useful?

I agree, it is a subjective statement whether to say “The workaround is simple”, or “The workaround is not simple”. Just understand that making a variable, scrolling to find the right variable, and placing multiple blocks isn't so good. A lot of blocks in Scratch are already workaroundable, and these blocks exist for quality-of-life improvements that save time.

This brings us to our next major argument,
Argument 2: Existing blocks have easier workarounds, or workarounds that take the same amount of time.
The forever block has the easiest workaround ever. And in fact, All message broadcasts have a similar workaround. Why just reject some block because of a workaround that isn't as simple to do?

Argument 3: The workaround can't do everything.
That's right, the workaround does not have the potential of these blocks. This means that there is something that the workaround can't do that these blocks can do.
What?
Let me explain, you can broadcast anything you want, but you can't create a variable. For example, the below block is completely possible:

broadcast (join [] [])

But you can't do this: (Excluding hacked blocks, I don't even know if this works anymore, but if it still does, this thing creates variables)

set (join [] []) to (join [] [])

Meaning if you want to have 1000 broadcasts (which can be useful), but don't want to create them by hand, you can just use this special broadcast block functionality to use. If you want the workaround, then you must create 1000 variables manually.

Sure, there may be a much more complex workaround involving lists or stuff like that, but then it gets too complex. There are existing blocks with complex or time consuming workarounds like

(length of [])

or even

repeat until <> 
end

, but such blocks have a very good reason to exist in Scratch. And so are these two blocks I am suggesting.

gamebeater187 wrote:

A: This workaround is:
NOT simple.

I didn't realise that flags were complicated

In all seriousness, though, the workaround is actually incredibly simple, and is the sort of thing you'd see all the time in other languages. (in case you're unaware, a flag is just a variable that tracks if a specific thing's happened)
For the problems with your computer, well, those are problems with your computer. I've never heard about anything like that, and it's never happened to me, so I have no idea what's going on there.
(side note: with “i need lots of variables for games”, do you use local variables a lot? because if you're using global variables for everything no wonder your variable list is always super long)

DaEpikDude wrote:

for the problems with your computer, well, those are problems with your computer. I've never heard about anything like that, and it's never happened to me, so I have no idea what's going on there.

No, it is YOUR computer that is good, not my computer that is bad.

List0RejectSuggest wrote:

DaEpikDude wrote:

for the problems with your computer, well, those are problems with your computer. I've never heard about anything like that, and it's never happened to me, so I have no idea what's going on there.

No, it is YOUR computer that is good, not my computer that is bad.

Huh?
Variables and right clicks don’t work like that for me, and the latter is probably something that should be looked into

Also yeah, the workaround is super simple. It has only two more blocks than this would
Like DaEpikDude said, you can use local variables. When you make one, click the box that says “for this sprite only” (or it’s something similar to that) and it won’t show up on the main list in other sprites

No support considering how simple the workaround is and, as DaEpikDude said,

DaEpikDude wrote:

the workaround is -snip- the sort of thing you'd see all the time in other languages.

Even though the workaround is simple in my opinion, I do agree that having these would make things easier.

Support

Wahsp wrote:

List0RejectSuggest wrote:

DaEpikDude wrote:

for the problems with your computer, well, those are problems with your computer. I've never heard about anything like that, and it's never happened to me, so I have no idea what's going on there.

No, it is YOUR computer that is good, not my computer that is bad.

Huh?
Variables and right clicks don’t work like that for me, and the latter is probably something that should be looked into

Also yeah, the workaround is super simple. It has only two more blocks than this would
Like DaEpikDude said, you can use local variables. When you make one, click the box that says “for this sprite only” (or it’s something similar to that) and it won’t show up on the main list in other sprites

Yeah, set zoom to 100%. Right click issues are totally unrelated to the variables.

It's a really simple workaround.

simple workaround:

when green flag clicked
set [yeetRecieved? v] to [0]

broadcast [yeet v] // broadcasts the broadcast "yeet"
when I receive [yeet v] // receives the broadcast, transmits broadcast into a variable
set [yeetRecieved? v] to [1] //1=true, 2=false

when green flag clicked
repeat until <(yeet) = [1]>
do some stuff :: motion

No support.
People could use it like the Boolean block, like this:

 
...
repeat until [broadcast v]{

} ::events
set [Why is this text here v] to [I dunno]

openPoll wrote:

No support.
People could use it like the Boolean block, like this:

 
...
repeat until [broadcast v]{

} ::events
set [Why is this text here v] to [I dunno]

I don't understand how example is like using the Boolean block. The main difference between the “repeat/wait until broadcast recieved” and the “if broadcast recieved?” is that the former is less ambiguous and clear on how it's used, which is why it wasn't rejected.

Support! I have encountered situations in which I would want to use this kind of block many times before! And another upside - clones won't receive broadcasts with these blocks so we could prevent clones from accidentally performing a script you want the sprite to do.

Support, this is something I have wanted to see in Scratch for a while.

If this is such a good idea, why hasn't scratch added it yet?

St23_BD420 wrote:

If this is such a good idea, why hasn't scratch added it yet?

Scratch doesn't add every single idea. They also don't add every single idea immediately.

The wait block is unambiguous. The repeat block, on the other hand, could replicate the ambiguity of the boolean like this:

when [space v] key pressed
if <[broadcast v] ::events> then
say [it broadcasts]
else
say [it does not broadcast]

when [space v] key pressed
repeat until [broadcast v] ::control
say [it does not broadcast]
wait (1e5000) secs
stop [this script v]
end
say [it broadcasts]

While there is a simple workaround, that is true of many blocks like wait until, repeat () times etc.
Support

Support bump. This is something that I MYSELF need to see. I am currently working on recreating a scrolling project I accidentally deleted (don't ask) and this is one of the things that really would help.

In a project where broadcasting is very necessary, using lots of variables can be a hassle. I want my codes to be nice and neat. I want to save time. Of course some things will require a lot of work, but they can be shortened as well.

ItzSh0ckerz wrote:

In a project where broadcasting is very necessary, using lots of variables can be a hassle. I want my codes to be nice and neat. I want to save time. Of course some things will require a lot of work, but they can be shortened as well.

I have the exact same feeling. And you spoke my mind.

when green flag clicked
spin me right round like a cw (record) baby
click green flag
broadcast [ message]
<message>

The block at the bottom is not accepted. see the list of rejected items to know why