Turtle sprite isn't an option in the clone block. if you mean to leave an empty sprite laying around, custom block libraries can't create sprites.
Aha, the "create a clone of [ v]" block does not have it, but the "a new clone of [ v]" does.
huh. how long has that feature been there? i'm sure i checked for this at some point a good while ago. i'm not sure why the other block doesn't have it, there's a sensing reporter to get all sprites so it would make sense to make a new sprite and do things with it later.
either way it still doesn't work. the stage still can't do it, and i would expect custom blocks to work from the stage.
new sprites also still can't be given hat blocks, which means they can't respond to broadcasts, keypresses (with proper key repeat), scrolling, etc. i would want these features to be able to, for example, make a library to create an old school terminal input for things like text adventures, os projects, etc. they seem to be already quite popular on the forums and i've seen people have plenty of trouble making them with a good featureset and performance.
you can't do either of these from custom blocks, as in custom blocks designed to be placed into other people's projects. the main use case i have for making a new sprite is that i could put it in a block and share it on the forum.
It's actually new to snap 10, so not a long time.
Sorry for reviving this old topic, but I recently discovered that you can, in fact, add hat blocks to a sprite programmatically with SciSnap! V3. I haven't figured out exactly how it works, but this should solve your problem, right @sarpnt?
Wow, I had no idea. do you know the premise of how it works/ blocks used so I can try to figure it out?
The example block above is pretty self explanatory, here is its definition:
I just figured out how it works, and now it stops working. Well, here is how it WAS working.
The "install eventhandler" block, when run, adds the hat block of your choice with the block below as its only script beneath it:
Inside of this block, you can define how each sprite responds to each event (menu item):
And, I suppose, you could use metaprogramming to do this all programmatically, and create custom blocks that do this more intuitively. I was about to do this when the "install eventhandler" block started producing an "Undefined!" block beneath the hat block rather than the "let [v] respond to [v]" block. I don't know what broke - but something did.