This suggestion would allow pen actions (sprite movements, pen down/up, pen size, perhaps pen color) to be stored in a variable so that they can be quickly repeated elsewhere.

All blocks should work like normal (including the pen blocks, so that the strokes are drawn on screen like normal) so that variables and if-blocks can affect what pen strokes are stored. This would be different from using a custom block, since variables are re-read and if statements are re-evaluated every time they are executed, which would not be the case with this suggestion.

save pen strokes to [drawing v] { 
go to x: (0) y: (0)
pen down
move (10) steps
...
pen up
} :: pen
draw [drawing v] with direction (90 v) and size (50) % :: pen // the starting point is the same as the sprite's current position

I think the “variables” for pen strokes could be a new data, in addition to variables and lists.

Example usage:

save pen strokes to [drawing v] {
repeat until (key [space v] pressed? :: boolean)
wait until <mouse down?>
go to [mouse-pointer v]
pen down
repeat until (not (mouse down? :: boolean) :: boolean)
go to [mouse-pointer v]
end
pen up
end
} :: pen
wait until (not (key [space v] pressed? :: boolean) :: boolean)
... // draw it wherever you want

Data size might be a problem if used this way, though.

I think that you could accomplish exactly this with My Blocks. What makes this feature different from My Blocks?

Can't this be done with custom functions?

define Pen1
pen strokes here :: #808080

when green flag clicked
Pen1 :: custom

No support.

edit: lol while i was typing this out i got sniped

Flipped_ wrote:

I think that you could accomplish exactly this with My Blocks. What makes this feature different from My Blocks?

This would theoretically be simpler and faster if you want to store dynamically-generated data.

CKCG wrote:

Can't this be done with custom functions?

define Pen1
pen strokes here :: #808080

when green flag clicked
Pen1 :: custom

No support.

edit: lol while i was typing this out i got sniped

The problem is that if you want to store pen strokes that are dynamically-generated, you have to implement some way to interpret a list or string, which many Scratchers may not want to do.

-Rex- wrote:

CKCG wrote:

Can't this be done with custom functions?

define Pen1
pen strokes here :: #808080

when green flag clicked
Pen1 :: custom

No support.

edit: lol while i was typing this out i got sniped

The problem is that if you want to store pen strokes that are dynamically-generated, you have to implement some way to interpret a list or string, which many Scratchers may not want to do.

What do you mean by dynamically-generated pen strokes?

Do you mean in an ordinary variable? Would the watcher become blank?

(Snap! has first-class procedures which make this easy. There is an example project called Vee which you can find by going File->Open…->Examples.)

Jonathan50 wrote:

Do you mean in an ordinary variable? Would the watcher become blank?

(Snap! has first-class procedures which make this easy. There is an example project called Vee which you can find by going File->Open…->Examples.)

Seeing as how even lists aren’t first-class, I don’t think a new first-class data type should be added. I also don’t think regular variables should be used.

This would vastly simplify PTEs. Support.

-Rex- wrote:

Seeing as how even lists aren’t first-class, I don’t think a new first-class data type should be added. I also don’t think regular variables should be used.

Okay. But first-class procedures are much more general, for example, if you wanted to use this to make a PTE like -Snipet- mentioned, unless the Scratch Team were to allow dropping reports into the dropdowns, you'd need an IF block for every possible character, whereas with first-class procedures you could use the Unicode codepoint as an index into a list of scripts for drawing characters. First-class procedures even make message passing simple (no broadcasts or clone IDs.) However, your example use case would be much less clear.

Jonathan50 wrote:

-Rex- wrote:

Seeing as how even lists aren’t first-class, I don’t think a new first-class data type should be added. I also don’t think regular variables should be used.

Okay. But first-class procedures are much more general, for example, if you wanted to use this to make a PTE like -Snipet- mentioned, unless the Scratch Team were to allow dropping reports into the dropdowns, you'd need an IF block for every possible character, whereas with first-class procedures you could use the Unicode codepoint as an index into a list of scripts for drawing characters. First-class procedures even make message passing simple (no broadcasts or clone IDs.) However, your example use case would be much less clear.

I know what first-class procedures are. However, I don't think the Scratch Team would agree to implement it in Scratch.

This can be kind of done with lists. It's something that I'm still working on, but if you want to see what I did, look here: https://scratch.mit.edu/projects/292671535/editor

But, I can see how this could be very useful, so Support.

LegoManiac04 wrote:

This can be kind of done with lists. It's something that I'm still working on, but if you want to see what I did, look here: https://scratch.mit.edu/projects/292671535/editor

But, I can see how this could be very useful, so Support.

I know it can be done with lists, but my point is that many Scratchers may not want to use lists for something like this.