Better Custom Blocks

AonymousGuy

There are quite a few improvements I have noticed that could be made to custom blocks.
Please read entire post, especially if you are skeptical about it.

*NOTICE: Some of these are in other topics, but I feel I should mention them here as well.

IDEAS 1 & 2: (Can you guess what they are?

)

#1: CUSTOM REPORTER BLOCKS
Custom reporters. If you don't know what a reporter is, here is a helpful wiki article. Basically, these would work similar to how they work in other programming languages. In other languages, it would look something like this:

int getWaffles()
{
   if (waffles == tasty)
   {
      return 20; //This tells you what "getWaffles()" is equal to. So if I were to say x = getWaffles(); x would either be equal to 20 or 0.
   }
   else
   {
       return 0;
   }
}

So obviously there would need to be some way to return a value.
That is where the “report” block comes in. This is based slightly off of BYOB, which uses the same statement. The reason for this is that report might be easier to understand then return, but it is possible to make it return as well. The bottom report block could be dragged and placed elsewhere in the block. (Thanks @TimothyLawyer for suggesting that!)

So how this would work is that when a custom reporter was used in a block, it would run the code and find the return / report value. If there was none, it would report the value at the bottom.

#2: CUSTOM BOOLEAN BLOCKS
These are obviously the same as custom reporter blocks, but are booleans. A function this could be used for is making a “is a multiple of” block or something similar. They could be used to say “string contains other string” and other functions that are too simple to be made into a full-fledged block, but good enough to make custom.

#3: LOCAL VARIABLES
These would be variables that were completely local to the block. No other part of the program could use them. How would these work?
There are 2 ideas:

This is the first one. But how would this work? Somewhere there would have to be something like a “create local variable” button. Obviously, a “create variable” block wouldn't work so well, because that would make it possible to lag out scratch. However, the idea of getting the set, change, etc. blocks by right clicking and pushing “get block…” is plausible.

I think this is the better solution. How it would work is similar to custom blocks. Only the blocks inside of the C-Block could use the variables. The weird looking variables and lists that look like “+” are just a quick sketch of how the using block could create more than one variable. However, I think it should only be able to hold either variables or lists.

The inspiration for this idea came from a language I use called C#, in which you can say this:

void doStuff()
{
   using (int x)
   {
      do stuff that uses int x
   }
   do stuff that doesn't use int x
}

I think that maybe these should also have different colors, and they should use the right-click functions to get the other blocks.

NOW: THE ISSUES
There are a few problems with implementing these features.
a) New Scratchers might find them difficult - this is true. When I started doing real line-by-line coding, I found it hard to understand WHY a return value was needed. This was because I was calling the things as functions and not as values - so maybe it would make more sense here.

b) Hard to implement - this is the worst problem. Because they would be hard to use for new scratchers, it is not on the scratch team's list. Also, for custom variables, there would probably have to be a block editor. Otherwise, when would the variables you needed show? When you clicked on the script you were editing? Who knows?

c) Most of these features are already in BYOB, so you can just use that.

THE ADVANTAGES
a) This would allow people to make much more organized projects, make blocks that other scratchers could use to perform well-made functions, and make scripts much easier.

b) This would be a good way to learn about more advanced programming topics.

c) Even if they are in BYOB, it is much more advanced than Scratch, so this would make it easier for more people to learn about this kind of thing.

Last edited by AonymousGuy (Nov. 27, 2016 06:53:47)

Firedrake969

Support all! All are used in real coding; why not here?

'17 rickoid

bf97b44a7fbd33db070f6ade2b7dc549

cobraguy

I like the Local Variables and have come across a few times when I could have used them. I'm sorta on the fence about this because it would be confusing for new scratchers.

LeadToGold

I support this suggestion as well.

I think the highest priority is the return value. (boolean is sort of a special case of return value).

Function local variables would certainly be useful but the I worry that the implementation would add more confusion for beginning programmers.

Sean

set (TheQuestion) to <<(2b) = [0]> or <not <(2b) = [0]>>>

mathfreak231

AonymousGuy wrote:
#1: CUSTOM REPORTER BLOCKS

Not the best mock-up I've ever seen. The oval should be outlined subtly and not colored in, like the define shape. (is this clear)

Also, the return thing shouldn't be at the end; what if I wanted to use if blocks to first report and stop if one condition is true before another? (is this clear)

Otherwise, support.

Last edited by mathfreak231 (Nov. 22, 2013 01:58:56)

i have grown as a person. and ive grown, literally. none of my posts from before 2022 represent me accurately.

AonymousGuy

mathfreak231 wrote:
AonymousGuy wrote:
#1: CUSTOM REPORTER BLOCKS
Not the best mock-up I've ever seen. The oval should be outlined subtly and not colored in, like the define shape. (is this clear)

Also, the return thing shouldn't be at the end; what if I wanted to use if blocks to first report and stop if one condition is true before another? (is this clear)

Otherwise, support.

1) The mock-up was rushed - but built from screenshots taken directly from the editor (I used a colored IF … THEN block to make the bar to the side, and a define block and a custom block to build the rest)
2) Well… there are ways around this (especially if there were local variables) but I understand
3) OK.

Last edited by AonymousGuy (Nov. 22, 2013 02:16:03)

TimothyLawyer

1. Support
2. (1) takes care of this with other blocks already in Scratch.
3. I support local variables in principle, but do not see a way to add this to Scratch that is easy enough.

Here is a mock-up extending the idea in (1) for custom reporters in Scratch:

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

AonymousGuy

TimothyLawyer wrote:
1. Support
2. (1) takes care of this with other blocks already in Scratch.
3. I support local variables in principle, but do not see a way to add this to Scratch that is easy enough.

Here is a mock-up extending the idea in (1) for custom reporters in Scratch:

Thanks for supporting!
Good mock-up art! I wondered how it would be good to implement making new return blocks.

Last edited by AonymousGuy (Nov. 25, 2013 16:21:44)

TimothyLawyer

AonymousGuy wrote:
Thanks for supporting!
Good mock-up art! I wondered how it would be good to implement making new return blocks.

Thank you for this thread and your ideas!

I have been thinking about how to simplify this.

From my mock-up, get rid of the Make a Reporter button and New Reporter dialog box.

Instead:

Add a “Return a value” checkbox to the New Block dialog box. (This could be at the top.)

If “Return value” is checked, the outline of the block becomes a reporter (capsule shaped) both in the dialog box and the define block (and after it is made).

The other change is to the define block. Like in the mock-up, it is a wrap block. And the blue return value cap block is affixed to it.

But the C (wrap) is collapsed so the return cap block is connected, at start, to the top tab of the define block.

Since the return block is connected like a normal stack block, it is obvious to Scratchers they can add new blocks in between.

Since the return block is connected like a normal stack block, it is obvious the definition returns whatever value is in the return cap block, if no other changes are made.

As in the mock-up, the return value cap block can be clicked-and-dragged from the define block to create new cap blocks to use elsewhere in the definition (like blue reporter blocks in Scratch block definitions).

When I get a chance, I'll create new mock-up art.

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

TimothyLawyer

TimothyLawyer wrote:
… new mock-up art.

Here it is.

Return value checkbox on left. Result of checking box on right.

To try:

adjust location of the return value checkbox
use a visual menu (reporter versus stack block) for the selection.
adjust the collapse, visual appearance of the C-block
etc

Any other ideas?

Last edited by TimothyLawyer (Nov. 27, 2013 18:43:48)

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

AonymousGuy

TimothyLawyer wrote:
TimothyLawyer wrote:
… new mock-up art.
Here it is.

Return value checkbox on left. Result of checking box on right.

Some things to try:
adjust location of the return value checkbox

use a visual menu (reporter versus stack block) for the selection.

adjust the collapse, visual appearance of the C-block

etc
Any more ideas?

Thanks for your ideas and input!
Mock-up art continues to be of good quality!

TimothyLawyer

AonymousGuy wrote:
Thanks for your ideas and input!
Mock-up art continues to be of good quality!

Thanks! I'm learning Paint.net

Last edited by TimothyLawyer (Nov. 27, 2013 18:49:05)

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

CodeLegend

Support!

If Scratch was made to help people learn to code in ‘real’ languages like Java and C, then it needs to have things like these!

“… your beard people are crazier than my hat people.”

AonymousGuy

I was looking at Snap! BYOB today and saw that for their custom reporters and booleans they had a block called "report []" to return the value.
I made some mock-up art to see what this would look like, also with @TimothyLawyer's suggestions:
Sorry, not everything is perfect, but I did my best.

My ideas were to have a small selector above the block (which you can see) and you can chose which type of block to make.

The reason I thought "report []" would be a good idea is because it would be easier to understand for younger / newer scratchers.

AonymousGuy

bump

TimothyLawyer

AonymousGuy wrote:
Sorry, not everything is perfect, but I did my best.

Looks good!

AonymousGuy wrote:
My ideas were to have a small selector above the block (which you can see) and you can chose which type of block to make.

I am going to write up my latest in another comment. It goes in a different direction than we have been: eliminates making a choice between block types, by only allowing one or the other. It depends on if you are looking at a sprite (custom stack block) or the stage (custom reporter block).

AonymousGuy wrote:
The reason I thought "report []" would be a good idea is because it would be easier to understand for younger / newer scratchers.

Both return and report work for me. Return is more computer science-y. But, yeah, report would be easier for our audience to understand. We could mention it returns in the tips (or on the wiki), for those who dig deeper.

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

TimothyLawyer

This would be nice:

The reason why this won't work is most of the blocks that appear in a normal custom block definition should not be in a custom reporter definition.

For example, this block with a custom reporter

 set [some everyday project variable v] to (custom [(base)] ^ [(power)] reporter)

should not result in Scratch Cat walking ten steps. Or a clone being made. Or all scripts being stopped.

Solution:

Make custom reporters only accept a limited set of blocks.

But how?

Make custom reporters be offered only from the Stage.
Make them the only custom block offered from the Stage.

Sprites get custom stack blocks. The stage gets custom reporter blocks.

(A custom reporter is available for any sprite to use, like a variable or list defined on the Stage.)

What else is unique about reporters?

They always run without screen refresh.

They do not contain any wait blocks. In fact, they do not contain most of the blocks in Scratch.

They are used (ideally) for quick calculations. They are like operator blocks.

They are operator blocks (or mathematical functions).

They have inputs (arguments) and one output (the return or report value).

They do not change anything else in Scratch when they run, not even variables that exist outside of them.

So they need their own local variables. These are temporary variables only accesible and change-able within a given custom reporter definition.

A set of stack blocks for a custom reporter definition:

branches: if-then, if-then-else

return variants: if-then–report, if-then–report-else-, if-then–else–report, if-then–report-else–report
loops: repeat-(), repeat-until-< >
local variables: set–to-[] change–by-()

Can less be used? Maybe less return branch variants?

Are more needed?

Comments? Ideas?

I will assemble another mock-up before too long.

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

AonymousGuy

TimothyLawyer wrote:
This would be nice:

The reason why this won't work is most of the blocks that appear in a normal custom block definition should not be in a custom reporter definition.

For example, this block with a custom reporter
 set [some everyday project variable v] to (custom [(base)] ^ [(power)] reporter) 
should not result in Scratch Cat walking ten steps. Or a clone being made. Or all scripts being stopped.

Solution:
Make custom reporters only accept a limited set of blocks.
But how?
Make custom reporters be offered only from the Stage.

Make them the only custom block offered from the Stage.
Sprites get custom stack blocks. The stage gets custom reporter blocks.

(A custom reporter is available for any sprite to use, like a variable or list defined on the Stage.)

What else is unique about reporters?

They always run without screen refresh.

They do not contain any wait blocks. In fact, they do not contain most of the blocks in Scratch.

They are used (ideally) for quick calculations. They are like operator blocks.

They are operator blocks (or mathematical functions).

They have inputs (arguments) and one output (the return or report value).

They do not change anything else in Scratch when they run, not even variables that exist outside of them.

So they need their own local variables. These are temporary variables only accesible and change-able within a given custom reporter definition.

A set of stack blocks for a custom reporter definition:
branches: if-then, if-then-else

return variants: if-then–report, if-then–report-else-, if-then–else–report, if-then–report-else–report

loops: repeat-(), repeat-until-< >

local variables: set–to-[] change–by-()
Can less be used? Maybe less return branch variants?

Are more needed?

Comments? Ideas?

I will assemble another mock-up before too long.

Who cares what it is supposed to and supposed not to do? Also, in other programming languages, all statements are perfectly valid.
For example, in C#, I could say:

int someInt(int a, int b)
{
    this.Text = "HELLO!"; //assuming this is some code for a windows form
    return 1;
}

and then I could say:

x = someInt(1, 1); //The inputs will not do anything in this situation, it will simply return x.

and it would be perfectly valid.
It would set this.Text to “HELLO!”, and then return 1, setting x to 1.

On an unrelated note, these custom reporters, if they had no inputs, could actually be displayed on stage with a watcher, although that would be complicated.

LordAzrael

#1 is huge in my mind. #3 would be pretty useful, #2 is easy to work without, but would clean up the code a bit. I support all of these, but number one is defiantly the priority.

AonymousGuy

LordAzrael wrote:
#1 is huge in my mind. #3 would be pretty useful, #2 is easy to work without, but would clean up the code a bit. I support all of these, but number one is defiantly the priority.

Do you mean definitely the priority?

Discuss Scratch