Unclear if there is a programmatic way to make a clone permanent

[ToonTalk]

I see the documentation for how to make change a clone from temporary to permanent but don't see a way for a program to do so.

[ToonTalk]

Also it is unclear how to test if a clone has been deleted. E.g. if one sets a global variable to a temporary clone, saves, and restores I would have expected "is sprite" to return false. But it doesn't. Is there a way to test if a clone has been deleted?

[kephas]

If you run this to produce a deleted sprite:

The following code should report true:

(you'll find safely try in the Catch errors in a script library)

[brianharvey]

Responding to the original issue: This is a deliberate decision by Jens. Permanent clones are much more costly in efficiency than temporary ones, mainly because of having to update them in the sprite corral. So Jens wants you to have to make each permanent clone deliberately, not have your program create a zillion in a loop.

[ToonTalk]

Here's my use case. The temporary clones are board positions (9 or 64 typically) and if while playing the game one saves the project the clones are destroyed. Or someone presses the stop button and then wants to play some more.

[jmoenig]

yes, the problem I'm trying to avoid is a sorcerer's apprentice one, where a script creates a zillion permanent clones that can't be deleted programmatically. Now, y'all are going to say "just let permanent clones be deletable programmatically", but that's going to make kids loose their work really quickly and unrecoverably.

In the meantime, there is an experimental way to change the "temparary" setting of a clone, but it's only available in dev mode:

I put it in for exactly the use case you're describing, where you want to create 64 chess figures, and don't want to do it all by hand.

Das that help?

[ToonTalk]

Yes, it does, thanks.

My personal preference is that rather than disabling dangerous features to put in the effort that warnings are produced when they are used and when they cause trouble that a clear error message helps users avoid the problem next time. E.g. "Warning: Snap! is nearly out of memory [or running very slowly] because you've created 23...45 sprites and turned off their temporary status". But I'm not suggesting that addressing this should have higher priority than many other outstanding issues especially because it might not be easy to implement.