Is there a costume library of letters I can import as objects in Snap!?
So I can have students use their names and have the letter do different things?
there's a library that lets you turn text - including single letters - into costumes:
Then you can use a short script - and change it accordingly - to create a sprite for every letter in a name:
And then you can let them add interactive effects.
Does that help?
You answer to my question was just what I was looking for.
Thank you for your help.
here's a little starter project you might wish to use or remix:
The 
can be used as well.
no, they want to be able to move around the letters, the write block writes the text on the stage using pen, you can't move pen trails around, well, unless you switch costume to pen trails.
oh yeah about that
I tried something like this and ran into several layers of grief. I wanted to clone a sprite and then modify its costumes with a new 'nametag'. The thought was that I could then use the same costume names for each of the clones, each having a different label. Then I discovered that the costumes for the temporary clones were actually the original sprites costumes. So, I gave the new clone a name, thinking that would make it permanent (in the current Snap! reference), but that made no difference. Then I discovered the temporary? flag, and, by toggling that to false, things looked like they were starting to work. That failed, though, because I was also reparenting the clones, and I ended up trashing the costumes of the new parent sprite. So, clearly, there's some magic surrounding costumes that I don't understand. I solved the problem by creating a separate costume alist and populating it with on the fly generated costumes, but I think there should be an easy way to use the existing costume feature, with modified or newly-generated costumes.
Took me a while to figure out what you meant about the manual. It's the fact that you made the clone in the UI, not in a program (MAKE A CLONE etc), that makes the clone born-permanent.
The child shouldn't be able to change its parent's wardrobe. Do you know precisely what you did?
Right, but I was stumbling around trying to work around the issue, so, naming the clone was my first attempt at making the clone permanent, which I thought would cause the parents costumes to be copied to the clone. I was using 'replace' on the my.costumes list in the clone and that definitely modified the parents costumes: set costume, stamp, write, replace item n of my.costumes with pen trails. I also tried collecting the modified costumes, deleting the current set of costumes and then adding back the new ones, and also, simply replacing my.costumes with a new list of costumes. In general, these resulted in messed up costumes and an unstable project, so I abandoned trying to make it work. The home-built costumes alist is working as intended.
Huh. I appreciated the comment about the manual, by the way! It helps me improve it.
About the costumes, perhaps you should just SET MY.COSTUMES TO MY.COSTUMES which (I hope) would disconnect the clone's wardrobe from the parent's.
how do you set costume to my:costume?
Eh? My.costume reports your current costume, so you don't have to set costume to it.
It would be good to have an explanation either in the manual or on the new wiki about the steps involved in making a programmatically cloned sprite permanent, i.e. whether the costumes and sounds are copied in that case, whether the inherit block works (I've not tested this). Same for what happens when a clone is re-parented : do the sprite-local blocks get copied to the reparented sprite (I think they do, but I'm having difficulties with using this with the 'xxx of sprite' block), do they then inherit variables and custom blocks from the new parent (which may make no sense) ?
oh wait, sorry. I was thinking about setting the entire list of costumes not set costume to.
There was a recent topic on this; I had gone through the same process, thinking I could update the underlying current costume, but, as Brian says, that's a reporter, not a variable.
Yeah, it's vague in the 5.1 manual because at that time I hadn't yet won the argument with Jens about whether users should be allowed to do that programmatically. :~)