These suggestions will enhance the custom block experience. There are 3 parts.

Part 1: Global Custom Blocks

Custom blocks and broadcasts are basically the same thing, but broadcasts are global and custom blocks have parameters. The fact that broadcasts do not have parameters can be a problem as well as the fact that custom blocks are not global. So why not combine them?

To make this change, you must remove the broadcast blocks, but they will be replaced with something much better.

When creating a new custom block, you have a new option to make the block global or keep it local. Local custom blocks act the exact same as they do now. Global custom blocks are affected by this suggestion
stion. There will also be an option of whether you want to wait when you call the block. If it is on, then the custom block will act as a broadcast and wait block instead of a regular broadcast block.

Essentially, for global custom blocks you have this in every sprite:

define your block here (parameter 1) (parameter 2)
...

Exactly how it is now. The difference is that upon calling this block, all of the sprites with this block defined will react instead of just the current sprite. So it acts like a broadcast. The parameters also travel, too, resembling a custom block.

This would solve at least 2 problems many people have.

Blocks as parameters

This suggestion allows you to add a block as a parameter. you can then call that block whenever you want inside of your 1 big block. The block parameter looks like this on a define block:

define test (callback []::stack) (number)

You can drag out the block parameter and use it in your script like so:

define test (callback []::stack) (number)
say [testing...] for (2) secs
callback ((number) + (5))::custom-arg

When calling this block, you define the block parameter like this:

test (callback (result::custom-arg) {
set [test said v] to (result::custom-arg)
wait (0.5) secs
}::hat custom) (1)::custom//sets "test said" to the result of test, which will be 6.

And that's basically the suggestion. The graphics may need tweaking, but it was the best I could do with the forum plugin.

Returning values

This is the most important thing. I will be fully content if this suggestion gets implemented even if none of my other suggestions do. I need it that bad.

On the custom block menu, you can choose a return type of none, string, boolean, or number. The none selection will act like the current custom block. the rest will have this block parameter on the define block (type of socket corresponds to type chosen):

define test (number) (return []::cap)
return (join [tested number ] (number))::custom-arg cap

When you use that block in your script, the custom block turns into the shape of either a boolean or a variable.

//either
(test (1)::custom)
//or
<test (1)::custom>

and you can put the custom block in a socket where it will act as whatever it returned.

I like your suggestions!

The first option is too similar to broadcasts, and the second option is just straight up confusing/wouldn't really work.
Custom reporters is a feature coming to 3.0.

KingOfAwesome58219 wrote:

The first option is too similar to broadcasts, and the second option is just straight up confusing/wouldn't really work.

I know that it is like the broadcast. It is supposed to be an upgrade to the current broadcast system we have now. This one can pass on individual values without having a global variable, which can get really inconvienient when you are doing it a lot. I will attempt to explain the second part better if you find it confusing.

1. Sorry, but no support. I'm satisfied with the current broadcast/custom block systems, and you can use variables to sort of simulate parameters in broadcasts.

2. Semi-support. I like how this could add more flexibility to custom blocks. The downside is that this could end up being confusing for new Scratchers.

3. Custom reporters are coming in 3.0, and you can simulate custom booleans by setting a custom reporter to 0 or 1.

I just had a new idea for my second suggestion that will greatly improve the interface. Instead of combining a hat block into the stack, why not turn it into a C block? i.e.

test the number (1) afterward: (result::custom-arg) {
set [test said v] to (result::custom-arg)
wait (0.5) secs
}::custom

everything else is basically the same.