Clones but with different concepts and workings

Okay, let me explain the title.

So basically, in Snap!, you can create clones in your scene and you can move them. You can even make buttons only with one "Button" sprite. HOWEVER, that's pretty much where all the functionality ends.

In Unity, which I will be comparing even though they are VERY different, with a clone, you can just create a whole new sprite which acts the same as the one original sprite but you can put different scripts in them.

So here's my idea: When you create a clone in Snap!, you it just copies one sprite and makes a different sprite which is similar, and you can put custom scripts into them as well.

You can "clone" a sprite from the coral. The sprite local blocks and variables can be declared as inherited or just overwritten.

i don't think you quite understand the purpose of clones or what they can do.

in this case i think you just want a second sprite, but clones can absolutely have their own variables and run their own separate scripts by using when started as clone, broadcasts, tell/ask, branches based on variables, calling variables, and all sorts of other things.
i often put tons of functionality in one sprite and use clones to do many unrelated things, since i'm used to scratch, where sharing code, costumes, and sound between sprites isn't possible.

Your feature already exists. You can make both temporary and permanent clones. By default, clones made programmatically, with A NEW CLONE OF or CREATE A CLONE OF, are temporary; clones made in the user interface, by right-clicking a sprite icon in the sprite corral and choosing "clone," are permanent. But you can change the temporariness of a clone programmatically.

Temporary clones are all deleted when you click either the green flag or the stop button. They don't have icons in the sprite corral.

In principle, clones share (not copy) all the attributes of their parent. In practice, some categories (most importantly, local variables) are copied rather than shared when the clone is created. Copying the local variables is important because of the common practice of giving each sprite an ID number, or an initial position, or something else that should be different for each clone.

But, and here's what's important for you, all shared attributes are shared with copy-on-write status. That is, if the clone does SET COSTUME TO or GO TO or SET for shared variables, or anything that changes its status, that attribute becomes unshared. A new copy in made in the child, and that's what gets SET. If the sprite wants to change some attribute for its entire family, it has to TELL (MY PARENT) TO (SET whatever). If the parent changes a shared attribute, all clones that are still sharing it automatically get the new value, because shared attributes are really shared, not copied.

So that's how you stop sharing; the clone just changes its copy. How you start sharing is with the INHERIT block. It requires a ringed input because it works on the attribute itself, not the attribute's value. You can put any one thing in the ring. Sometimes you have to struggle to find a single inheritable thing; you can say
untitled script pic
but not
untitled script pic (1)
because the position vector is made of two heritable things.

TL;DR: What you want already exists; read Chapter VII of the manual.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.