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.

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.

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.

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.

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:

1. Change the return value in the custom reporter to “some value”.
   
   
2. 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?

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:

1. Change the return value in the custom reporter to “some value”.
   
   
2. 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"

AonymousGuy wrote:

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"

Okay, the way I am doing it now each of the stack blocks that should be used in a custom reporter (or custom operator) definition are in the same color and available from the More Blocks palette when the Stage is selected (and one or more custom reporters operators have been made). Because these blocks are not custom blocks themselves, they won't be the same color as a custom block or definition hat (they won't be purple).

if  <> then //color=grey
    
end

if <> then //color=grey
     
else
end 

report [  ] // category=grey 
stop [ ] // the report block will have a flat bottom like stop this script (like in the first mock up)

repeat () // color=grey 
    
end 

repeat until <> // color=grey
    
end

There is no restriction on using other blocks, but the recommended blocks are these (all the same color), the input values from the define hat (dark blue reporters), Scratch's built-in operators (light green reporters), and the new local variables and set/change blocks.

A custom operator can have its own variable(s).

Once a local variable is made, two stack blocks, unique to each custom operator, appear in the palette below that operator and its variable(s).

(i) // category=grey 
set [i v] to [0] // category=grey 

change [i v] by (1) // category=grey 

These are also the same color as the recommended control blocks.

A triangle button shows/hides the local variables and set/change blocks. One ▶ for each; the button is in the palette in front of the operator. It faces down ▼ when open.

One operator is open at a time; others close automatically. When open, appearing below a custom operator are: its local variables, its set/change blocks, and its add a variable button.

To accommodate making custom boolean blocks, the checkbox to Run without screen refresh is changed to Cast as boolean. When checked, the appearance of the custom block changes to boolean (<>) in the New/Edit Block window and, after OK is clicked, in the palette and in the definition hat. The script in a definition is unchanged by checking the box. (The flat bottom report block stays the same.) If casting does not give the desired report value, a Scratcher will have to update their script.

All operators are global: they can be used in stage scripts and in sprite scripts. So the custom operators also appear in the More Blocks palette of each sprite (below any sprite-specific custom blocks). In the sprite palette, the triangle button is not present. The operator can only be opened from the Stage, where its definition is kept.

Mock up is still in the works.

TimothyLawyer wrote:

AonymousGuy wrote:

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"

Okay, the way I am doing it now each of the stack blocks that should be used in a custom reporter (or custom operator) definition are in the same color and available from the More Blocks palette when the Stage is selected (and one or more custom reporters operators have been made). Because these blocks are not custom blocks themselves, they won't be the same color as a custom block or definition hat (they won't be purple).

if  <> then //color=grey
    
end

if <> then //color=grey
     
else
end 

report [  ] // category=grey 
stop [ ] // the report block will have a flat bottom like stop this script (like in the first mock up)

repeat () // color=grey 
    
end 

repeat until <> // color=grey
    
end

There is no restriction on using other blocks, but the recommended blocks are these (all the same color), the input values from the define hat (dark blue reporters), Scratch's built-in operators (light green reporters), and the new local variables and set/change blocks.

A custom operator can have its own variable(s).

Once a local variable is made, two stack blocks, unique to each custom operator, appear in the palette below that operator and its variable(s).

(i) // category=grey 
set [i v] to [0] // category=grey 

change [i v] by (1) // category=grey 

These are also the same color as the recommended control blocks.

A triangle button shows/hides the local variables and set/change blocks. One ▶ for each; the button is in the palette in front of the operator. It faces down ▼ when open.

One operator is open at a time; others close automatically. When open, appearing below a custom operator are: its local variables, its set/change blocks, and its add a variable button.

To accommodate making custom boolean blocks, the checkbox to Run without screen refresh is changed to Cast as boolean. When checked, the appearance of the custom block changes to boolean (<>) in the New/Edit Block window and, after OK is clicked, in the palette and in the definition hat. The script in a definition is unchanged by checking the box. (The flat bottom report block stays the same.) If casting does not give the desired report value, a Scratcher will have to update their script.

All operators are global: they can be used in stage scripts and in sprite scripts. So the custom operators also appear in the More Blocks palette of each sprite (below any sprite-specific custom blocks). In the sprite palette, the triangle button is not present. The operator can only be opened from the Stage, where its definition is kept.

Mock up is still in the works.

Good ideas! When I rewrite the main post, I will be sure to mention this.

@TimothyLawyer:

This is a good idea, but what about reporter blocks like…

(x position)
(size)
(volume)
(answer)

…these? They don't affect the sprite at all, and they can be used in calculations.

New idea for the local variables:

There is a block called “create variable ()” which you can access by right clicking on the custom block and getting a block.
To use the variable in calculations, drag one from the “create variable” block.

But how do you change / set the variable?

There is a little button in the right-click menu which says “get block…” and you click this then chose the block that you want.

AonymousGuy wrote:

New idea for the local variables

The problem with this is that some creative person will hack in a ‘variable variable’ creator and start making lambdas or whatever else they can to crash Scratch. (Although I find this very unlikely)

CodeLegend wrote:

AonymousGuy wrote:

New idea for the local variables

The problem with this is that some creative person will hack in a ‘variable variable’ creator and start making lambdas or whatever else they can to crash Scratch. (Although I find this very unlikely)

I don't exactly see the problem. But, to prevent people from constantly recreating the same variable, maybe the “create variable” block could be part of the custom block itself?

AonymousGuy wrote:

…
I don't exactly see the problem. But, to prevent people from constantly recreating the same variable, maybe the “create variable” block could be part of the custom block itself?

The problem I proposed was, mostly, a joke. But I do think it would be a good idea to have the variables within the custom block.
Although…
Sometimes, when you make a repeat loop and use a variable named ‘i’ or something as an incrementer, it would be more organized if ‘i’ was just a local variable. Or, as they're called in BYOB, a ‘script variable.’

I support ALL of them! All of them would help a lot, boolean blocks would be much better than using

<[1] = [1]>

or something like that :S

Interesting. I support better custom blocks.

<[] ^ []>

like that.

when green flag clicked
say [let's do this!!!]
dance

and that, my friends, is my script.

CodeLegend wrote:

AonymousGuy wrote:

…
I don't exactly see the problem. But, to prevent people from constantly recreating the same variable, maybe the “create variable” block could be part of the custom block itself?

The problem I proposed was, mostly, a joke. But I do think it would be a good idea to have the variables within the custom block.
Although…
Sometimes, when you make a repeat loop and use a variable named ‘i’ or something as an incrementer, it would be more organized if ‘i’ was just a local variable. Or, as they're called in BYOB, a ‘script variable.’

BYOB Hhahahhahaha

Wasdkeys123 wrote:

CodeLegend wrote:

AonymousGuy wrote:

…
I don't exactly see the problem. But, to prevent people from constantly recreating the same variable, maybe the “create variable” block could be part of the custom block itself?

The problem I proposed was, mostly, a joke. But I do think it would be a good idea to have the variables within the custom block.
Although…
Sometimes, when you make a repeat loop and use a variable named ‘i’ or something as an incrementer, it would be more organized if ‘i’ was just a local variable. Or, as they're called in BYOB, a ‘script variable.’

BYOB Hhahahhahaha

What do you mean by that?

Yes, this is the one reason I don't use scratch more often!!

AonymousGuy wrote:

Good ideas! When I rewrite the main post, I will be sure to mention this.

Thank you!

CodeLegend wrote:

@TimothyLawyer:

This is a good idea, but what about reporter blocks like…

(x position)
(size)
(volume)
(answer)

…these? They don't affect the sprite at all, and they can be used in calculations.

Yes. They do fall outside the set of blocks recommended to use in the definition of a custom operator block. The reason is to keep clear what value(s) the operator is working on.

To use these kinds of reporter blocks in the calculations, have them as inputs to the custom operator.

AonymousGuy wrote:

New idea for the local variables:

There is a block called “create variable ()” which you can access by right clicking on the custom block and getting a block.
To use the variable in calculations, drag one from the “create variable” block.

But how do you change / set the variable?

There is a little button in the right-click menu which says “get block…” and you click this then chose the block that you want.

Using the right-click menu to get a change or a set block from a variable reporter and (vice versa) to get a variable reporter from a change or a set block would be useful, even without custom blocks with return values.

AonymousGuy wrote:

But, to prevent people from constantly recreating the same variable, maybe the “create variable” block could be part of the custom block itself?

Yes, including the local variables in the define hat is an approach that could work.

meowflash wrote:

_meow_

I put the cap on Scratch cat in Paint.net and uploaded to use on the discussion forums.

Just link to http://i1366.photobucket.com/albums/r767/hctarcs/santahatscratchcattransparentbackground_zps40fddf43.png with the img tags.

I don't know if there is a way to use the image in a comment to a project.