Context: BJC U1L1 Click Alonzo; one of my students interpreted the instructions as, if you click on the stage (i.e. try to click Alonzo but miss), Alonzo should restore to 0 ghost effect.
It's a pretty good idea in terms of gameplay actually, so I wanted to show my class how to do it.
On the Stage scripting area I did this:
But when the Stage scripting area is active, the say block is suppressed in the Looks palette (and is not found by ctrl-F). The only way I could make this happen is to make a custom block with 'say' inside it, and then from the Stage scripting area, drag it back out.
Is there a better way?
You can create the script in a sprite, then drag the script onto the stage.
Hmm, that actually worked, although the visual feedback of the say block bouncing back when I dragged it onto the Stage (thumbnail in the sprite corral), suggested to me otherwise. But when I went to the stage scripting area, there it was!
Also, when the sprite scripting area is active, I can drag the block all the way from the Looks palette to the Stage in the sprite corral -- it also bounces back (suggesting failure) but it works
The simple reason those blocks aren't in the Stage's palette is that users sometimes accidentally click on the Stage in the sprite corral, and a lot of experience with Scratch showed that they then get confused if they click on a Motion or Looks block and nothing happens. It's easier to debug if the user sees "the wrong" sprite move or whatever.
A more hidden reason is that those blocks, in a sprite's palette, have that sprite built into them as a sort of hidden input; the MOVE 10 STEPS block in Sprite(2)'s palette is, in effect, "really" MOVE SPRITE(2) 10 STEPS. If you drag such a block from one sprite to another, the block that appears in the target sprite's scripting area isn't "really" the same block you dragged; it is invisibly translated to the target sprite's block. So a Motion or Looks block in the Stage's palette wouldn't mean anything. Jens speaks eloquently about why it's sensible to think this way rather than to have one generic MOVE block that gets an implicit target sprite attached at the last moment, just as some sprite is running the block.
Interesting. So if it were possible to suppress irrelevant blocks in the Stage palette, but let them be discovered by CTRL-F, then it would really be "Stage-Say", which would lead to more confusion.
For ringified blocks I wonder if there's a sensible way to have the UI such that, when the tell block has Sprite or Alonzo selected, then you right-click on the ring, there could be an item called "sprite-specific palettes" that pops up a floating version of the palettes that could be chosen from.
Probably that's way too complex though.
Anything but Stage, actually. We thought about that sort of solution but yeah, it seemed too complicated.
The basic idea is that it's sprites and the stage that are active agents in Snap!, not blocks. The rest of the story follows from that.