Maximouse wrote:

Hearst10 wrote:

so, would

 return value [] :: custom-arg cap 

be good?

That would be good.

gosoccerboy5 wrote:

ForumHelperNanoPiex wrote:

Maximouse wrote:

Hearst10 wrote:

so, would

 return value [] :: custom-arg cap 

be good?

That would be good.

Very good. But what about

report [] :: custom-arg cap

No, because first of all report might make you think it reports a player, and also it should be a cap block, and it shouldn't be red.

Marc92020 wrote:

gosoccerboy5 wrote:

ForumHelperNanoPiex wrote:

Maximouse wrote:

Hearst10 wrote:

so, would

 return value [] :: custom-arg cap 

be good?

That would be good.

Very good. But what about

report [] :: custom-arg cap

No, because first of all report might make you think it reports a player, and also it should be a cap block, and it shouldn't be red.

Yeah I don't think that. I think it should be good.
Also, return value sounds like it would only return a number

ForumHelperNanoPiex wrote:

Marc92020 wrote:

gosoccerboy5 wrote:

ForumHelperNanoPiex wrote:

Maximouse wrote:

Hearst10 wrote:

so, would

 return value [] :: custom-arg cap 

be good?

That would be good.

Very good. But what about

report [] :: custom-arg cap

No, because first of all report might make you think it reports a player, and also it should be a cap block, and it shouldn't be red.

Yeah I don't think that. I think it should be good.
Also, return value sounds like it would only return a number

Value can be letters, symbols, ect. any character.

return [] :: custom-arg cap

gosoccerboy5 wrote:

People could probably easily figure out that it can return words

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

AHypnoman wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

Yes. I'd prefer that. It's quite simple and quite understandable. Perfect for Scratch!

gosoccerboy5 wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

I think most of the recent discussion was around alternatives for that.

ForumHelperNanoPiex wrote:

AHypnoman wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

Yes. I'd prefer that. It's quite simple and quite understandable. Perfect for Scratch!

gosoccerboy5 wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

I think most of the recent discussion was around alternatives for that.

negative ninja

AHypnoman wrote:

ForumHelperNanoPiex wrote:

AHypnoman wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

Yes. I'd prefer that. It's quite simple and quite understandable. Perfect for Scratch!

gosoccerboy5 wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

I think most of the recent discussion was around alternatives for that.

negative ninja

Sorry, I can’t see to whom or to what you are referring to, and what you mean by “negative ninja”. Could you please explain?

ForumHelperNanoPiex wrote:

AHypnoman wrote:

ForumHelperNanoPiex wrote:

AHypnoman wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

Yes. I'd prefer that. It's quite simple and quite understandable. Perfect for Scratch!

gosoccerboy5 wrote:

Marc92020 wrote:

or how about just

return [] :: custom-arg cap

I think most of the recent discussion was around alternatives for that.

negative ninja

Sorry, I can’t see to whom or to what you are referring to, and what you mean by “negative ninja”. Could you please explain?

The second paragraph is because you should read that because it has a thing you should read, sorry if I sound rude. Negative ninja means that two or more posts are the exact opposite.

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.

gosoccerboy5 wrote:

ForumHelperNanoPiex wrote:

Maximouse wrote:

Hearst10 wrote:

so, would

 return value [] :: custom-arg cap 

be good?

That would be good.

Very good. But what about

Report []

No, because first of all report might make you think it reports a player, and also it should be a cap block, and it shouldn't be red.

define (delete and report item (num ::custom) of (list ::custom)
return (item (num  ::custom) of (list ::custom)) ::custom
delete (num ::custom) of (list ::custom)

-LekkerGames- wrote:

ive been asking for this for a long time. 100% support.

mazzadoobry wrote:

Agree and Support.

PATSATDAT wrote:

-snip-
We dont want it to be a cap block

define (delete and report item (num ::custom-arg) of (list ::custom-arg) :: custom) 
return (item (num  :: custom-arg) of (list ::custom-arg)) ::custom-arg
delete (num ::custom-arg) of (list ::custom-arg)

define (delete and report item (num ::custom-arg) of (list ::custom-arg) :: custom) 
use temporary var ((report) :: grey){
set [report v] to (item (num :: custom-arg) of [list v] :: list)
delete (num ::custom-arg) of (list ::custom-arg)
return (report) :: custom-arg cap} :: variables

 :: custom-arg 

TimothyLawyer wrote:

-snip-

ReversedServers wrote:

i dont think that the reporter would be inside the custom blocks, but the reporter maker would be a seperate thing.