-OctoSquid- wrote:

when green flag clicked
set [support v] to [95%]

gosoccerboy5 wrote:

elps8507 wrote:

I just cant really think of a reason apart from factorials where you would need anything besides the define and return block. also what stops people from snapping in other blocks that aren't temp variables or loops. just seems overly complex to add a section for code, and temp variables, and a system of keeping the other blocks out. maybe a new connector type? but that still seems a little shaky when you think or needing to implement loops and other control blocks into that system.

not saying that sometimes adding code could be nice but it seems very un-scratch to me to have such a clanky system that is hard to pickup and learn.

Well, Scratch doesn't have many specialized functions, so you could for example build a reporter that finds the distance between two points, or if you're making a game using WASD/arrow keys, you could make a boolean that detects if W or the up arrow key is pressed, saving you a bunch of

<<> or <>>

blocks.

Also, it might feel a little un-Scratch but these systems are prevalent in many text-based programming languages. And a few things in Scratch are hard to learn already, like the sin operator. Scratch has done a very good job of accomodating new programmers but many more advanced programmers (not saying that's me) would like to see more advanced things to do with Scratch, and this is a great building point.

elps8507 wrote:

To add more detail to my solution from my other post: I think that there should be a 4th section within each sprite (like code, costumes, and sound) called “blocks”. Each block you make would have its own code editor that only contains the blocks you can us inside that type of function. code functions would have almost everything you can use in the code editor besides the round top events while bools/round custom blocks would have access to only diagnostic, operator, and special function blocks like return.
I think that this is the best way to implement these new systems without them interacting with old ones in strange ways.
any critique is welcome as long as your not being rude about it.

Rendangbike2 wrote:

elps8507 wrote:

Rendangbike2 wrote:

elps8507 wrote:

I just cant really think of a reason apart from factorials where you would need anything besides the define and return block. also what stops people from snapping in other blocks that aren't temp variables or loops. just seems overly complex to add a section for code, and temp variables, and a system of keeping the other blocks out. maybe a new connector type? but that still seems a little shaky when you think or needing to implement loops and other control blocks into that system.

not saying that sometimes adding code could be nice but it seems very un-scratch to me to have such a clanky system that is hard to pickup and learn.

How hard is it? I think it's pretty explanatory but if they don't know what the block does, they just ignore it.

-schnip schnip-

Well in that case, they should remove the math reporter block which I don't even know how to use them

gosoccerboy5 wrote:

elps8507 wrote:

To add more detail to my solution from my other post: I think that there should be a 4th section within each sprite (like code, costumes, and sound) called “blocks”. Each block you make would have its own code editor that only contains the blocks you can us inside that type of function. code functions would have almost everything you can use in the code editor besides the round top events while bools/round custom blocks would have access to only diagnostic, operator, and special function blocks like return.
I think that this is the best way to implement these new systems without them interacting with old ones in strange ways.
any critique is welcome as long as your not being rude about it.

Interesting. I feel like if users were properly educated in the use of these blocks they wouldn't try to do silly stuff like a return statement in the middle of a normal script or calling a temporary variable outside of the area it's supposed to be in. Possibly, when one is making a project and they create a custom reporter/boolean or use a temporary variable, there should be a non-intrusive popup that links to somewhere that tells you how to use them.

I like having the define blocks in the same area as the rest of the code, too, it makes things more convenient.

And ideally, these new systems should be designed in a way that creates minimal project crashing. For example if you use a return function out of place, it should ignore the return function instead of creating a syntax error and crashing the project.

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.

elps8507 wrote:

cries in reporter blocks that run code

secretagent123 wrote:

gosoccerboy5 wrote:

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.

But that's exactly what it does. Reports something.

sathvikrias wrote:

AHypnoman wrote:

My support has changed slightly over the last few months. I think it would be best for everyone if we just have 4 new blocks. Those being:

define (Thing)

define <Thing>

define meant to be a loop:: custom loop


return [] :: custom-arg cap // I edited these so its in the right category and a string input

and these?????????????????????????????????????????????????????????????????????????????????????????????????????????????????

use temporary variables (. . .) @addInput{
} :: variables
use temporary lists (. . .) @addInput{
} :: list

Create variable (...) @addInput ::variables
Create list (...) @addInput ::list

PATSATDAT wrote:

sathvikrias wrote:

AHypnoman wrote:

My support has changed slightly over the last few months. I think it would be best for everyone if we just have 4 new blocks. Those being:

define (Thing)

define <Thing>

define meant to be a loop:: custom loop


return [] :: custom-arg cap // I edited these so its in the right category and a string input

and these?????????????????????????????????????????????????????????????????????????????????????????????????????????????????

use temporary variables (. . .) @addInput{
} :: variables
use temporary lists (. . .) @addInput{
} :: list

I prefer

Create variable (...) @addInput ::variables
Create list (...) @addInput ::list

And as someone said before it would be like let

PATSATDAT wrote:

sathvikrias wrote:

AHypnoman wrote:

My support has changed slightly over the last few months. I think it would be best for everyone if we just have 4 new blocks. Those being:

define (Thing)

define <Thing>

define meant to be a loop:: custom loop


return [] :: custom-arg cap // I edited these so its in the right category and a string input

and these?????????????????????????????????????????????????????????????????????????????????????????????????????????????????

use temporary variables (. . .) @addInput{
} :: variables
use temporary lists (. . .) @addInput{
} :: list

I prefer

Create variable (...) @addInput ::variables
Create list (...) @addInput ::list

And as someone said before it would be like let

forever
Create variable (...) @addInput ::variables
end

gosoccerboy5 wrote:

How about a 20 temporary variable limit?
(That is, per script)

AHypnoman wrote:

-snip-

define meant to be a loop:: custom loop

-snip-

define while <bool> (action :: stack) :: loop
repeat until <not <bool>>
action :: custom-arg
end

define (duration of {action :: custom-arg} :: sensing)
script variables variables ((old timer) :: grey) @addInput :: grey
set [old timer v] to (timer)
action :: custom-arg
return ((timer) - (old timer)) :: custom-arg cap