Those of us who were here first might remember there was a block called “clone me” that was replaced by “create clone of: sprite”. While that removed the need for a sprite to check if it is not a clone before it makes a copy, it created a problem:

“clone me” would always copy the object it was put in.
but “create clone of: sprite” always creates another copy of the original parent sprite.

- - - - - - - - - - -

Example:

If I first clone this sprite:
resulting in two:
then I change the second one to a different costume:
and then the second sprite uses “clone me” to copy itself again:

The result is this: … this is correct because the clone copied itself, it didn't copy its parent.

Now lets use the new “create clone of: sprite” block:

I first clone this sprite:
resulting in two:
then I change the second one's costume:
and then the second sprite uses “create clone of: sprite”

The result: The clone just made another copy of its parent.

This is exactly what should happen if I use “create clone of: sprite”. The problem is that there is no longer an option to clone “Me”.

- - - - - - - - - - -

Problem:

This makes it impossible for successive generations to pass on their properties to their children, and then to their grandchildren, etc. Any problems relating to variables are caused by this.

These properties include:

-costume
-graphic effects
-size
-layer
-variables
-lists
-direction
-pen properties

- - - - - - - - - - -

Solution Proposal:

All that is needed to fix this is the option to clone the object the block is put in, like this:



Please give feedback! Thanks!

+1 This would also allow for recursion and recursive scripts, like the following (s is a local var):

when cloned:
change s by -1
turn left 10 degrees
pen down
move s steps
create a clone of self
move s * -1 steps
turn right 20 degrees
move s * 0.5 steps
create a clone of self
move s * -1 steps

Totally. [create clone of ] is a must.

Bump

This hasn't gotten ST attention since the old forum.

That would be great. I think this personally, because I copy a lotlotlot[/b of sprites when making my games.

I agree

I agree that a sprite should be able to clone itself with all variables and costumes intact.

Any form of feedback/acknowledgement would be much appreciated…just give me a sign!

Support. Like Hardmath123 said, this would allow for recursive and dynamic scripting.

illusionist
Any form of feedback/acknowledgement would be much appreciated…just give me a sign!

This ^^ is exactly why I started this thread: http://alpha.scratch.mit.edu/forums/topic/161/

It sounds like “clone self” is a possibility for addition to the block. Would that be enough– or are there related changes that would need to be made?

Another question is what you think of where the clone is positioned? Currently the clone by default takes the position of the cloner (rather than the sprite being cloned). Which do you think new users of clones will expect?

When I clone something I would expect it to show up where the item being cloned is located–it is a perfect copy after all.

Another idea might be:

Clone [mysprite v] at (0), (0)

Or you can have two different blocks; one would clone at the location of the item cloned, and the other would clone at an (x, y) location:


Keep in mind the “clone startup” block would also have to be modified to keep up with the new blockspecs.

Of course, it might not really matter where the clone shows up if the programmer puts a GOTO block and a SHOW or HIDE block in the CLONE STARTUP script.

Thanks for the replies about where the clone should go.

About “clone me” or “clone self” is a different “clone startup” hat needed, like that one below?

Vista4563
Keep in mind the “clone startup” block would also have to be modified to keep up with the new blockspecs.

[clone {clone ?} startup]

Vista4563
Keep in mind the “clone startup” block would also have to be modified to keep up with the new blockspecs.

[clone {clone ?} startup]

Disagree.

Remember, a “CLONE STARTUP” script is located inside the sprite that is being cloned. And, it gets fired off only for that specific clone when that clone is created.

So that won't be necessary.

@Natalie:

I like that clones go to their creator, that eliminates the need for a “go to: creator” option in the “go to: sprite” block…or a much much more complicated mechanism.

If clone didn't go to their creator regardless of the type of clone, this could not happen: http://alpha.scratch.mit.edu/projects/10001737/?mode=player

My only suggestions:

Clones should have the ability to copy themselves (not the sprite they are a clone of) and
Clones should go to their creator upon creation (keep it the way it is now)

I am totally satisfied with Scratch 2.0 if this is added.

illusionist
Clones should go to their creator upon creation (keep it the way it is now)

No, clones should inherit everything from their parents: pen color/shade/size, position, direction, speech bubble, temporary variables' current values, size, volume, current answer from ask block, etc.

Hardmath123

illusionist
Clones should go to their creator upon creation (keep it the way it is now)

No, clones should inherit everything from their parents: pen color/shade/size, position, direction, speech bubble, temporary variables' current values, size, volume, current answer from ask block, etc.

I think that would be ok if there was a way for a clone to go to its creator upon creation. A “go to: creator” option in the “go to: sprite” block would do the trick, but I'm not sure that is necessary.

If all properties except location were inherited, I think that would be much easier.

illusionist

Hardmath123

illusionist
Clones should go to their creator upon creation (keep it the way it is now)

No, clones should inherit everything from their parents: pen color/shade/size, position, direction, speech bubble, temporary variables' current values, size, volume, current answer from ask block, etc.

I think that would be ok if there was a way for a clone to go to its creator upon creation. A “go to: creator” option in the “go to: sprite” block would do the trick, but I'm not sure that is necessary.

If all properties except location were inherited, I think that would be much easier.

If location wasn't inherited, where would it go? No, location should also be inherited.