yaya3156peppermintpatty5matey1234dude341liam48Ddavidovskidude341peppermintpatty5dude341Charmind

loading

Support all!

loading

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.

Firedrake969

loading

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

jontmy00

loading

Support.

DotDash

loading

SUPPORT

meowflash

loading

(unneeded quote text removed by moderator - please keep your posts concise)

Brilliant!

Mrcomputer1

loading

+1
Good idea.

AonymousGuy

loading

meowflash wrote:
*Collapsed*
Brilliant!

Does that mean you support?

cobraguy

loading

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

loading

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

k9lego

loading

Support! And my sister's account @v9lego Supports too! So please add us both to the support list.

k9lego

mathfreak231

loading

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.

AonymousGuy

loading

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.

TheGuyWithTheHat2

loading

Support!

AonymousGuy

loading

12 supporters! Can we get more?

conorb

loading

Nice Information

AonymousGuy

loading

conorb wrote:
Nice Information

Do you support?

TimothyLawyer

loading

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:

AonymousGuy

loading

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.

Photoguy77

loading

Supporting!

TimothyLawyer

loading

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.

billabobscratch

loading

SHUPPORT!!!

gregory9

loading

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

jaboyc

loading

SUPPORT! I wanted this for ages!

TimothyLawyer

loading

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?

AonymousGuy

loading

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

loading

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

Thanks! I'm learning Paint.net

meowflash

loading

I support all! (Gives you the ultimate pizza)

CodeLegend

loading

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!

FarAwayGames

loading

Support all!

AonymousGuy

loading

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

loading

bump

ninja_star

loading

Support.

Mozzi64

loading

Support all.

TimothyLawyer

loading

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.

TimothyLawyer

loading

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.

AonymousGuy

loading

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

loading

#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

loading

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?

TimothyLawyer

loading

AonymousGuy wrote:
Who cares what it is supposed to and supposed not to do?

The people who design Scratch and decide how reporters behave.

Scratchers who are accustomed to the behavior of reporters, or trying to learn what makes a reporter block different from a stack block.

I did not realize the importance of this originally, earlier in this thread, when considering whether or how to add a return statement to a custom block.

But there is the expectation, when seeing a block with the shape of a reporter, that it does things like other reporters.

So

(a custom reporter) //category=purple

should follow the example of other reporters in Scratch, such as

and not do the extra things a stack block does.

The role of a reporter block is described here:

http://wiki.scratch.mit.edu/wiki/Reporter_Block

Custom reporters should be consistent with the reporters already in Scratch; this limits how we can make a block definition for a custom reporter.

Here is the example from my earlier post:

… 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.

By setting a variable to the value returned by a custom reporter, as above, should a sprite also walk across the stage? Or a new clone be made? Or all scripts stopped?

If Scratch allows any blocks to be included in the definition of a custom reporter, then this single line could do all of those things.

It is only supposed to be setting a variable to the value returned by a reporter.

Someone who uses Scratch should be able to depend on a reporter behaving like a reporter and not doing extra things.

That is my purpose in trying to figure out the smallest set of blocks that can be used to create custom reporters that are able to do all the things expected of reporters in Scratch.

It is worth noting that we already have one type of custom reporter in Scratch: variables. So we do not need to duplicate that functionality.

AonymousGuy wrote:
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;
}

This means someInt behaves in a manner different from a reporter in Scratch.

AonymousGuy wrote:
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.

Valid C# code does not change that Scratch reporters do not behave in this way.

AonymousGuy wrote:
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.

It would. The way I see these custom reporters, they are not going to have a value until they return one. And that only happens when they are used in a script, not before or after. The workaround would be to set a variable equal to the operator. Then put the variable in the place in the script where the custom reporter would have been. And watch the variable.

However, a custom reporter with no inputs is not likely to be very different from a constant.

cool_dude_2

loading

### ###### # # ####### ##### ##### ###### #######
# # # # # # # # # # # # #
# ###### # # # # # # # # ###### #
# # # # # ##### ##### # # # # #
### ###### ### ## # # ##### # # #

AonymousGuy

loading

TimothyLawyer wrote:
*Previous post by @TimothyLawyer*

This whole thing is why, when a user made a new custom block, if the type was reporter, there would be a small box that says the following:
"It is recommended to not use any blocks that change the location, costume, etc. of a sprite. These blocks normally are not activated by reporters, so it is recommended to not activate them in yours." (or something similar)

And, what if I wanted to use these blocks / needed to use these blocks? It is really easy to debug something with a

say [some value]

block, but this would restrict me from doing so.

CodeLegend

loading

TimothyLawyer wrote:
…should not result in Scratch Cat walking ten steps…

Some functions (specifically trigonometry) are much easier to make with the motion blocks.
Also, I have seen custom blocks that set a variable to a pointer value of a newly created object, which could be made easier with custom reporters.

EDIT:
There are some restricted blocks (like motion blocks for the stage, or custom block parameters) that you can still put in the wrong spot.

AonymousGuy

loading

CodeLegend wrote:
TimothyLawyer wrote:
…should not result in Scratch Cat walking ten steps…
Some functions (specifically trigonometry) are much easier to make with the motion blocks.
Also, I have seen custom blocks that set a variable to a pointer value of a newly created object, which could be made easier with custom reporters.

EDIT:
There are some restricted blocks (like motion blocks for the stage, or custom block parameters) that you can still put in the wrong spot.

Oh yes, I just remembered! Even if you restricted it to the stage, you can still put those blocks in your backpack and bring them into the stage, completely defeating that restriction.

TimothyLawyer

loading

AonymousGuy wrote:
This whole thing is why, when a user made a new custom block, if the type was reporter, there would be a small box that says the following:
"It is recommended to not use any blocks that change the location, costume, etc. of a sprite. These blocks normally are not activated by reporters, so it is recommended to not activate them in yours." (or something similar)

It needs to be more than a recommendation to ensure Scratch reporters are like reporters and not like stack blocks.

One way to handle it could be for Scratch to ignore the extra blocks.

AonymousGuy wrote:
And, what if I wanted to use these blocks / needed to use these blocks? It is really easy to debug something with a
say [some value]
block, but this would restrict me from doing so.

Test the algorithm before adding it to the definition.

Or try:

Change the return value in the custom reporter to “some value”.
Put the custom reporter in a say block.

say (custom reporter)

The local variables of a custom reporter could – still working this out – be made available to watch (when viewing a project in the editor) by selecting the reporter in the palette.

The goal is to have these reporters made by Scratchers not behave unlike Scratch reporters.

But perhaps an exception could be made for using a say block in the definition of a reporter (to debug).

CodeLegend wrote:
…should not result in Scratch Cat walking ten steps…
Some functions (specifically trigonometry) are much easier to make with the motion blocks.

You can extract the math from the movement of a sprite to use in a reporter. Here is an example.

CodeLegend wrote:
Also, I have seen custom blocks that set a variable to a pointer value of a newly created object, which could be made easier with custom reporters.

I don't know what that means (“set a variable to a pointer value of a newly created object”) in this context. Could you give an example?

CodeLegend wrote:
EDIT:
There are some restricted blocks (like motion blocks for the stage, or custom block parameters) that you can still put in the wrong spot.

Scratch does handle this okay. Scripts with blocks in the wrong spot either don't run or ignore the non-functional block. Maybe reporter definitions could do the same thing.

AonymousGuy wrote:
Oh yes, I just remembered! Even if you restricted it to the stage, you can still put those blocks in your backpack and bring them into the stage, completely defeating that restriction.

You can also drag them from a sprite to the stage. I tried and the stage ignores some non-functional blocks (pen up) and won't go past others (both motion blocks and pen blocks). And some scripts stay highlighted even though they aren't doing anything. So it is restricted, but it is not apparent in that the block is there and looks like it will run (looks no different from any other block). So a Scratcher won't know until they try to run a script, if it works. And then they have to compare the sprite palette to the stage palette or mix-and-match to figure out which blocks do not work.

Maybe Scratch needs a better way to show a non-functional block?

AonymousGuy

loading

TimothyLawyer wrote:
AonymousGuy wrote:
This whole thing is why, when a user made a new custom block, if the type was reporter, there would be a small box that says the following:
"It is recommended to not use any blocks that change the location, costume, etc. of a sprite. These blocks normally are not activated by reporters, so it is recommended to not activate them in yours." (or something similar)
It needs to be more than a recommendation to ensure Scratch reporters are like reporters and not like stack blocks.

One way to handle it could be for Scratch to ignore the extra blocks.
AonymousGuy wrote:
And, what if I wanted to use these blocks / needed to use these blocks? It is really easy to debug something with a
say [some value]
block, but this would restrict me from doing so.
Test the algorithm before adding it to the definition.

Or try:
Change the return value in the custom reporter to “some value”.

Put the custom reporter in a say block.
say (custom reporter)
The local variables of a custom reporter could – still working this out – be made available to watch (when viewing a project in the editor) by selecting the reporter in the palette.

The goal is to have these reporters made by Scratchers not behave unlike Scratch reporters.

But perhaps an exception could be made for using a say block in the definition of a reporter (to debug).

CodeLegend wrote:
…should not result in Scratch Cat walking ten steps…
Some functions (specifically trigonometry) are much easier to make with the motion blocks.

You can extract the math from the movement of a sprite to use in a reporter. Here is an example.

CodeLegend wrote:
Also, I have seen custom blocks that set a variable to a pointer value of a newly created object, which could be made easier with custom reporters.
I don't know what that means (“set a variable to a pointer value of a newly created object”) in this context. Could you give an example?

CodeLegend wrote:
EDIT:
There are some restricted blocks (like motion blocks for the stage, or custom block parameters) that you can still put in the wrong spot.

Scratch does handle this okay. Scripts with blocks in the wrong spot either don't run or ignore the non-functional block. Maybe reporter definitions could do the same thing.

AonymousGuy wrote:
Oh yes, I just remembered! Even if you restricted it to the stage, you can still put those blocks in your backpack and bring them into the stage, completely defeating that restriction.
You can also drag them from a sprite to the stage. I tried and the stage ignores some non-functional blocks (pen up) and won't go past others (both motion blocks and pen blocks). And some scripts stay highlighted even though they aren't doing anything. So it is restricted, but it is not apparent in that the block is there and looks like it will run (looks no different from any other block). So a Scratcher won't know until they try to run a script, if it works. And then they have to compare the sprite palette to the stage palette or mix-and-match to figure out which blocks do not work.

Maybe Scratch needs a better way to show a non-functional block?

Remember how Scratch would run the script from the sprite using it?

Instead of doing anything to prevent people from using normal blocks, which will ultimately fail (someone will hack them in), just tell users to not use them unless absolutely necessary. Then you could have a list of blocks not to use, like:
"Don't use:
motion blocks
event blocks
sound blocks
pen blocks
looks blocks
hat blocks
cap blocks
create clone of
any custom blocks using these
unless absolutely necessary"

coler706

loading

AonymousGuy wrote:
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

#1: CUSTOM REPORTER BLOCKS

This is a very useful (in my opinion) suggestion. There is an image above this text that I made to represent them.
Basically, what these would be is custom reporters that allowed people to make their own functions (such as square (x), or to the power of, etc).
These would allow people to both make better projects and learn the basics of other programming languages (like JavaScript, and Java, and one I use called C#)

EDIT: As @mathfreak231 pointed out, return block image is inaccurate. Maybe there should be something like a block that returns so there is an easy way to have the value return one thing based on whether another thing or not

EDIT 2: @TimothyLawyer added greatly to these by suggesting:
A second button in More Blocks that said “Create a Reporter”
A default return block at the bottom
Extra return blocks that could be inserted elsewhere in the script, which would stop the rest of the script from running and return that value
The detail of the light purple outline of the block - which I wanted to do….

#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

This, in my opinion, is the most useful and possibly the hardest. Basically, as shown by the image above, there would be variables that only the block could use and access, and a new version of the variable was made for each instance of the block running. This would allow people to make blocks like the “string contains other string” and things like it that are impossible to do without variables that are, well, variable. (and not constant / read-only).

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. It hit me when I was scratching and I wanted to make a block that I could read the value of. I named the block “Return value of ” something
and I understood.
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)Edit: Not to mention that it might be difficult to code

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.

SUPPORTERS [25] (Individual: 1:[25], 2:[20], 3:[20])
AonymousGuy ALL
Firedrake969 ALL
jontmy00 ALL
DotDash ALL
Mrcomputer1 ALL
k9lego ALL
v9lego ALL
LeadToGold 1 & 2
mathfreak231 1
TheGuyWithTheHat2 ALL
TimothyLawyer 1 & 3
Photoguy77 ALL
billabobscratch ALL
gregory9 ALL
jaboyc ALL
meowflash ALL
CodeLegend ALL
FarAwayGames ALL
ninja_star ALL
Mozzi64 ALL
LordAzrael ALL
cool_dude_2 ALL
COLER706 ALL

WE NEED THIS

CJA4625

loading

Support

cobraguy

loading

Support the reporters.

King_Cat

loading

Support, of course!

ocular rewritten

Better Custom Blocks