1. Bring back the user id block
2. Cloud broadcasts- as a separate block, not as a replacement for normal broadcasts.
3. View count reporter block
4. Active players reporter block- relatively low priority, a more complicated solution is already possible with cloud variables
5. A join block with extendable inputs, as per BYOB extendable inputs - again, relatively low priority, you can just use multiple normal join blocks, but would still be helpful
6. Custom reporter and boolean blocks
7. Temporary variables (declared at the start of a script or block definition, exclusive to that script or block, deleted at the end of the block or script)
8. (Idea by jvclincoln) “<recieving (messsage)>” boolean block. (Appended: OR a “message” reporter like in Snap 4.0)
9. Flash cookie variables- look like cloud vars, but with a cookie instead of a cloud. Stores the variable locally as a flash cookie. (Probably limit it to ~5 variables and/or 1 list here)
10. Increase the tag limit
11. Possible special cloud variables in addition to normal cloud- apply to all projects by user
12. “print (text) at x (x) y (y)” pen block
13. You should be able to log into the bugtracker with your regular scratch account. I see no reason to require a seperate account for that.
14. **Images from http://internetometer.com/ should be allowed. Myself and, most likely, the other scratchers with internetometers, would like to be able to use them properly.** (A workaround is possible thanks to the scratchr.org api, but takes longer to load among other problems) (scratchr.org no longer exists, so there is no longer a functional workaround)
15. You should be allowed to put reporter blocks in more dropdowns than you currently can. It's more helpful than the scratch team seems to think.
16. BRING BACK “EXPORT SCRIPTS TO IMAGE”!
17. Maybe bring back single stepping?
18. Allow images from Creative Commons.
19. <[string] contains [other string]> boolean.
20. Say [] until <> block.
21. Bring back the Scratch API.
22. (Index of [string] in [list v]) and (Index of [string] in [other string]) reporter blocks
23. greyshift graphic effect
24. Negative color mode
25. Colored variables!
26. Can Scratch please have a built in text-to-speech engine?

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

gvclincoln wrote:

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

+1

I agree with all of these!

(Idea by jvclincoln) “<recieving (messsage)>” boolean block.

You can use a complicated system with lists and custom blocks to do that.
You would still need a reciever for each message.

An inbuilt block would be better.

How about a run script <javascript code> block?

kidomat43 wrote:

How about a run script <javascript code> block?

No. There are so many possible abuses for that.

Problem with the <recieve> boolean is that the script has to reach the boolean and check for it at the EXACT same time as the broadcast is being sent. There could be ways to make it work, such as keeping track of when it was broadcasted and whether it happened soon enough to be considered “true.” But I would like to see it if they can work it out.

If that didn't make any sense, try single stepping in 1.4 and see if that helps.

Failord wrote:

Problem with the <recieve> boolean is that the script has to reach the boolean and check for it at the EXACT same time as the broadcast is being sent. There could be ways to make it work, such as keeping track of when it was broadcasted and whether it happened soon enough to be considered “true.” But I would like to see it if they can work it out.

If that didn't make any sense, try single stepping in 1.4 and see if that helps.

Yep! Thanks for explaining.

Failord wrote:

Problem with the <recieve> boolean is that the script has to reach the boolean and check for it at the EXACT same time as the broadcast is being sent. There could be ways to make it work, such as keeping track of when it was broadcasted and whether it happened soon enough to be considered “true.” But I would like to see it if they can work it out.

If that didn't make any sense, try single stepping in 1.4 and see if that helps.

True…

…any other comments?

Updated.

Updated again. Any more comments?

Lightnin wrote:

Failord wrote:

Problem with the <recieve> boolean is that the script has to reach the boolean and check for it at the EXACT same time as the broadcast is being sent. There could be ways to make it work, such as keeping track of when it was broadcasted and whether it happened soon enough to be considered “true.” But I would like to see it if they can work it out.

If that didn't make any sense, try single stepping in 1.4 and see if that helps.

Yep! Thanks for explaining.

Wait until < > only, or an automatic break for repeat until < >? For if, it's a bit more tricky…

Add single stepping again?

OrcaCat wrote:

Lightnin wrote:

Failord wrote:

Problem with the <recieve> boolean is that the script has to reach the boolean and check for it at the EXACT same time as the broadcast is being sent. There could be ways to make it work, such as keeping track of when it was broadcasted and whether it happened soon enough to be considered “true.” But I would like to see it if they can work it out.

If that didn't make any sense, try single stepping in 1.4 and see if that helps.

Yep! Thanks for explaining.

Wait until < > only, or an automatic break for repeat until < >? For if, it's a bit more tricky…

Add single stepping again?

Might be helpful.

Any other comments?

gvclincoln wrote:

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

Yeah, that would be great!

+1

gvclincoln wrote:

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

There is a very simple workaround for this. Make a variable and name it whatever you want. Go to the sprite that was broadcasting whatever and replace the broadcast block with a set variable block. For example:
Turn this:
__________________________________
| forever if <whatever condition you want>|
| ||broadcast ______________
|_________________________________|
Into this:
__________________________________
| forever if <whatever condition you want>|
| ||set variable to_________________
|_________________________________|
Then make another sprite respond whenever the variable is equal to 1, or the condition of the one sprite is true. You have to have the variable 0 when the condition is false, though.

mitchboy wrote:

gvclincoln wrote:

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

There is a very simple workaround for this. Make a variable and name it whatever you want. Go to the sprite that was broadcasting whatever and replace the broadcast block with a set variable block. For example:
Turn this:
__________________________________
| forever if <whatever condition you want>|
| ||broadcast ______________
|_________________________________|
Into this:
__________________________________
| forever if <whatever condition you want>|
| ||set variable to_________________
|_________________________________|
Then make another sprite respond whenever the variable is equal to 1, or the condition of the one sprite is true. You have to have the variable 0 when the condition is false, though.

That's a good workaround. Sometimes it's better than broadcasts, actually.

Failord wrote:

mitchboy wrote:

gvclincoln wrote:

you should make a
<when I receive (message)>
to put in if, wait until, etc blocks

There is a very simple workaround for this. Make a variable and name it whatever you want. Go to the sprite that was broadcasting whatever and replace the broadcast block with a set variable block. For example:
Turn this:
__________________________________
| forever if <whatever condition you want>|
| ||broadcast ______________
|_________________________________|
Into this:
__________________________________
| forever if <whatever condition you want>|
| ||set variable to_________________
|_________________________________|
Then make another sprite respond whenever the variable is equal to 1, or the condition of the one sprite is true. You have to have the variable 0 when the condition is false, though.

That's a good workaround. Sometimes it's better than broadcasts, actually.

Yeah. I never use broadcasts anymore. I prefer to have one extremely long script over a bunch of small scripts. Using this workaround, it helps make a bunch of scripts into one.