Shouldn't effects (e.g. ghost) be saved with a sprite or project?

[toontalk]

If I set the ghost effect to 100%, save and reload then the ghost effect is back to zero.

[loucheman]

You could save the ghost value into a var: the var content will be saved with the project...

or

You could save the ghost value into the browser with the database library

[toontalk]

But until the green flag is clicked the costume will be visible. And the green flag code needs to be more complex to restore the ghost effect.

[bh]

I don't know if there's a reason or not. Maybe Jens will say? I see your point, that it's as much part of the sprite's state as anything else is.

[loucheman]

@toontalk

But until the green flag is clicked the costume will be visible

Does the sprite should be invisible when you open the project ?

if yes, you can hide the sprite before saving the project

or

you can move the sprite outside the stage (ex: 500,500) before saving the project

[jens]

Snap projects preserve much of the state of objects, but not all of it (same as Scratch projects, but not quite as much as Smalltalk images). For example, processes and user state (which keys are currently pressed, the mouse pointer position, presentation mode etc.) are treated as transient, as are some properties of sprites and the stage, such as graphic effects, whether the pen is "down" or "up", etc. This facilitates sharing sprites among projects. But - like everything - the decisions where exactly to draw the line are debatable.

Basically Snap! wanted to cater to folks who are already familiar with Scratch, so I did the same thing as Scratch does. This is also one of the few strategies that help us evade endless teeth-clenching fights about design principles