Remember how these booleans introduced ambiguity?

<[ v] received? :: events >

Of course, we don't want ambiguity in our codes. We want a specific feature that is not very complicated.

My solution involves detecting broadcasts in certain ways:

<[ v] has been received since @greenFlag was clicked? :: events > // if the broadcast has been used since Green Flag was clicked. Contributes to the since Green Flag was clicked workaround.

<[ v] is in function? :: events > // if the broadcast is happening currently. 

<[ v] is activated? :: events > // not just if it is happening, but also if it was activated or if another one was activated. This would contribute to the 0.25 seconds workaround.

This is so nobody would get confused, and simply get rid of ambiguity since the options are now separate from it's old suggestion. Though it may be confusing to New Scratchers, please remember that even I didn't understand what some blocks meant, such as () mod () and floor of () and ceiling of ().

This is interesting… You might want to check out some of these, but I think these could work well and stop people from asking for boolean reporters

These blocks look pretty interesting, but I still don't see why

when I receive [ v]

can't be used in place of the boolean.

no support, this was rejected already, and stuff like this probably are too (to?)

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

alexphan wrote:

These blocks look pretty interesting, but I still don't see why

when I receive [ v]

can't be used in place of the boolean.

These suggested booleans they said, could be used in the middle of projects, and also for clones to receive broadcasts.

Auroura_Wolf wrote:

This is interesting… You might want to check out some of these, but I think these could work well and stop people from asking for boolean reporters

I feel like this post is trying to say that the topic will linked will prevent my suggestion from being accepted.

Or, it might be that this suggestion I made to be added so nobody would ask anymore.

Please be specific.

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

1. But that would be like rejecting the “wait until broadcast received” blocked. Prove it that it's rejected. Is there a section int he rejected topics that mentions separate booleans just to escape a reason? That's what we should do, try to prevent a difficult result. This suggestion was made to prevent ambiguity, not to keep complaining about Scratch Team rejecting the original block. What do you have to complain about my reason of preventing ambiguity in this case?
2. I've been taking English class for years.

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

You still understand, I made this topic to prevent the ambiguity! Don't you understand? The only reason why the original block was rejected was because it had too much ambiguity! This suggestion does not introduce that, and it actually goes through that obstacle!

I'm tired of this. -_-

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

You still understand, I made this topic to prevent the ambiguity! Don't you understand? The only reason why the original block was rejected was because it had too much ambiguity! This suggestion does not introduce that, and it actually goes through that obstacle!

I'm tired of this. -_-

all you are doing is breaking those blocks into smaller blocks, also, there are these things called WORKAROUNDS.

Its R E J E C T E D. Dont try to dig under the wall, just deal with it! (no offense)

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

You still understand, I made this topic to prevent the ambiguity! Don't you understand? The only reason why the original block was rejected was because it had too much ambiguity! This suggestion does not introduce that, and it actually goes through that obstacle!

I'm tired of this. -_-

all you are doing is breaking those blocks into smaller blocks, also, there are these things called WORKAROUNDS.

Its R E J E C T E D. Dont try to dig under the wall, just deal with it! (no offense)

It's not rejected. They only rejected a certain form of the block.

FancyFoxy wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

You still understand, I made this topic to prevent the ambiguity! Don't you understand? The only reason why the original block was rejected was because it had too much ambiguity! This suggestion does not introduce that, and it actually goes through that obstacle!

I'm tired of this. -_-

all you are doing is breaking those blocks into smaller blocks, also, there are these things called WORKAROUNDS.

Its R E J E C T E D. Dont try to dig under the wall, just deal with it! (no offense)

It's not rejected. They only rejected a certain form of the block.

but:

1. Workarounds

2. I really don't see how this could benefit Scratch,

3. Scratch doesn't need blocks for everything.

Guys, please try and trim the quote trains so we don't have to spend all our time scrolling past duplicate content.

Charles12310 wrote:

Randomness-TV wrote:

No support.
Fort reasons listed above


sssssssssssssssssssssssiiiiiiiiiiiiiiiiiiiiiiixxxxxxxxxxxxxxxxxxxxxttttttttttttttttttttyyyyyyyyyyyyyyyyyyyysssssssssssssssseeeeeeeeeeeeeecccccccccccccoooooooooooooooonnnnnnnnnnnnndddddddddrrrrrrrrrrruuuuuuuuuuuuulllllllllllllllleeeeeeeee

what reasons

The comment above that one is

alexphan wrote:

These blocks look pretty interesting, but I still don't see why

when I receive [ v]

can't be used in place of the boolean.

and above that is a link to a related thread.

I-Iz-A-Litten wrote:

FancyFoxy wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

I-Iz-A-Litten wrote:

no support, this was rejected already, and stuff like this probably are too (to?)

Excuse me, what part of, “Solution To Ambiguity In Broadcast Booleans” do you not understand?

I know it's rejected, but there is a reason.

This suggestion was made to prevent the ambiguity. You shouldn't always be thinking, “oh, there is a broadcast boolean topic, and it's already rejected. Lemme not support this”.

1. It's rejected, separating it into different blocks is just saying you want to dig under the wall.

2. Sorry I don't understand everything that comes out of your mouth no offense, but not everyone understands everything

-snip-

1,

List of rejected suggestions wrote:

8. <broadcast received> boolean
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.

2. Well I haven't, this is the same for a bunch of other people,

if it's rejected, its rejected, deal with it.

You still understand, I made this topic to prevent the ambiguity! Don't you understand? The only reason why the original block was rejected was because it had too much ambiguity! This suggestion does not introduce that, and it actually goes through that obstacle!

I'm tired of this. -_-

all you are doing is breaking those blocks into smaller blocks, also, there are these things called WORKAROUNDS.

Its R E J E C T E D. Dont try to dig under the wall, just deal with it! (no offense)

It's not rejected. They only rejected a certain form of the block.

but:

1. Workarounds

2. I really don't see how this could benefit Scratch,

3. Scratch doesn't need blocks for everything.

stop telling me what to do. Nothing is going to change my opinion, and you are just trying to complain.

These are not workarounds, these blocks don't even exist yet!

Workarounds are only for existing blocks. Saying these non-existent blocks are workarounds isn't going to help,

You keep saying it's rejected! Well, not these blocks I keep telling you these suggested blocks aren't the same as the original one because these blocks don't introduce ambiguity! Do I have to really report this?

@FancyFoxy is right. It's only a certain form of the block!

Charles12310 wrote:

-big snip-

thats it, I'm unfollowing this because you keep getting upset over my opinion on why this shouldn't be added, I feel like you are forcing me to support, no offense

I-Iz-A-Litten wrote:

Charles12310 wrote:

-big snip-

thats it, I'm unfollowing this because you keep getting upset over my opinion on why this shouldn't be added, I feel like you are forcing me to support, no offense

I Wasn't Forcing You To Change Your Vote!

I Was Telling You That Your Reasoning Is Wrong!

I Have A Large Headache Now Because Of This…

Charles12310 wrote:

Remember how these booleans introduced ambiguity?

<[ v] received? :: events >

Of course, we don't want ambiguity in our codes. We want a specific feature that is not very complicated.

My solution involves detecting broadcasts in certain ways:

<[ v] has been received since @greenFlag was clicked? :: events > // if the broadcast has been used since Green Flag was clicked. Contributes to the since Green Flag was clicked workaround.

<[ v] is in function? :: events > // if the broadcast is happening currently. 

<[ v] is activated? :: events > // not just if it is happening, but also if it was activated or if another one was activated. This would contribute to the 0.25 seconds workaround.

This is so nobody would get confused, and simply get rid of ambiguity since the options are now separate from it's old suggestion. Though it may be confusing to New Scratchers, please remember that even I didn't understand what some blocks meant, such as () mod () and floor of () and ceiling of ().

What does it mean that a broadcast is “happening currently”? A message is sent at a specific time - it doesn't continue for any length of time. It's essentially instantaneous.

What does it mean that a message “is activated”? Was sent sometime prior to the test on the boolean? What makes it no longer activated?

Charles12310 wrote:

I-Iz-A-Litten wrote:

Charles12310 wrote:

-big snip-

thats it, I'm unfollowing this because you keep getting upset over my opinion on why this shouldn't be added, I feel like you are forcing me to support, no offense

I Wasn't Forcing You To Change Your Vote!

I Was Telling You That Your Reasoning Is Wrong!

I Have A Large Headache Now Because Of This…

jeez, it was just my opinion, why are you raging about this?