I think this might be better:

create clone of [person v] named [Joe] :: control
(clone name :: control)
<touching clone [name]? :: control> //Reports false if clone does not exist

Zparx wrote:

Currently, the workaround for clone identification is to change a global variable by 1 for each clone, and set a local variable to whatever number the global variable has reached at the time each clone is spawned. This is sort of a clone ID system. This is a great method of clone identification and very useful, but it isn't versatile enough. For example, the <if touching {sprite v}> boolean simply can't work with this method. I, personally, have tried a new method, which is to detect clone ID's through the ({cloneID variable} of {sprite 1}) operator but this doesn't work either. It only detects the cloneID variable of the sprite, and not of its clones.

I propose that we have the ability to name sprites according to a global variable. For example;



This would be so extremely useful in a number of ways. Firstly, I know that the “if touching {sprite v}” boolean wouldn't consist of Clone tags, but there is also a seemingly simple solution to this, being;



^ Of course, while the image above is custom made and only possible through various paint editors, it is there to get the point across. You could simply insert that operator into the “touching {sprite 1 v}” boolean!

This is only a rough sketch of the idea, and the operator I've constructed most likely will not be the solution to the detection method, but the way I see it, this should be somehow implemented immediately!

Does anyone else agree that this would be extremely useful?

- Z

Supporters:

Zparx
SFollis
7734f
firedrake969_test
dracae
MathManiac

There is an easier less tedious workaround using a list..

This is how I identify clones.

when green flag clicked
set [CloneId v] to [0]
repeat (10)
    
change [CloneId v] by (1)
create clone of [myself v]
end
set [CloneId v] to [0]

CloneId is a local variable for this sprite only. Creating the clone after changing the CloneId will ensure that the clone inherits the new value. I set the original CloneId back to zero at the end of the loop to indicate it is not a clone. Any sprite with a CloneId>0 is a clone.

One day I will need this.

Support.

HAHAAAA!!! I've been tackling a similar problem and I think I have just found a workaround. Each sprite has its individual “volume” variable (Sound menu), and I figured out that when you create a clone, its volume is local (other clones don't share it). That means that as soon as you generate a clone, you should set its volume to a unique number (I would suggest you set it to the total number of clones plus one), and you can then identify each clone by its volume. The clone doesn't actually need to make a sound; you can access its volume using the volume block all the way at the bottom of the “sound” menu. That being said, only the clone can access its own volume, but it would be able to make “announcements” by setting a global variable to equal its volume. The main code could then determine which clone the announcement came from by looking at that global variable. This method might not work so well if you actually need the clones to make sounds, since that would mean each clone is making its sound at a different volume, but you can also use the same method with costume#. There may also be other built-in variables that can be used to identify individual clones. Please reply if you have any questions/issues. Hope this helps!

Wait a minute… I just realized that what I said before works with any local variable. There was I, thinking I had found a genius workaround. Oh well, at least there is a viable way of identifying clones…

AonymousGuy wrote:

I think this might be better:

create clone of [person v] named [Joe] :: control

Having this block would be very helpful.

I know that people are very quick and fond of saying that the workaround of having local clone ID variables with constantly running forever loops in each clone that store its X position, its Y position, its direction, its costume, size, local variables and other information in a set of lists and then other sprites and clones can access those set of lists and using Pythagorean and trig they don’t have any need for using the native Scratch blocks to reference a clone.


But, wouldn’t it be better and more fair to the clones to allow them to be used in these blocks?

go to [ v]


point towards [ v]
<touching [ v] ?>
(distance to [ v])
([ v] of [Sprite1 v])

And I expect some will say that this would confuse beginners but what do beginners now think when they see this block:

create clone of [ v]

Do they just assume it has something to do with Star Wars?

I used this clone naming feature in a SNAP project https://snap.berkeley.edu/project?username=10goto10&projectname=SNAP%21%20Snake and even though it’s not how it would be done in Scratch it did make my Snake project easier to program and I think it is easier to read. Well, I did use some other SNAP features, such as a table, so that might be distracting if you happen to look inside (“i.e. edit”).

You can even click on each Snake segment and it will tell you its name.

10data10 wrote:

AonymousGuy wrote:

I think this might be better:

create clone of [person v] named [Joe] :: control

Having this block would be very helpful.

I know that people are very quick and fond of saying that the workaround of having local clone ID variables with constantly running forever loops in each clone that store its X position, its Y position, its direction, its costume, size, local variables and other information in a set of lists and then other sprites and clones can access those set of lists and using Pythagorean and trig they don’t have any need for using the native Scratch blocks to reference a clone.


But, wouldn’t it be better and more fair to the clones to allow them to be used in these blocks?

go to [ v]


point towards [ v]
<touching [ v] ?>
(distance to [ v])
([ v] of [Sprite1 v])

snip-

unless im understanding this wrong, clones can already use those blocks? its just that you have to run them in scripts that the clone is running, rather then scripts which the original sprite is running

blablablahello wrote:

unless im understanding this wrong, clones can already use those blocks? its just that you have to run them in scripts that the clone is running, rather then scripts which the original sprite is running

Yes they can use them but not fully and clones can not be the target. A sprite or a clone can't go to a clone or test if it touching a clone or point to a clone or get the local variables of a clone and so on.


Update: For example, better clone identification would help this user who just posted a request for help: https://scratch.mit.edu/discuss/topic/667530/?page=1#post-7033295

-Gato_ wrote:

I'm trying to find the closest clone for each specific clone,

I'm not going to tell him about “ the workaround of having local clone ID variables with constantly running forever loops in each clone that store its X position, its Y position, its direction, its costume, size, local variables and other information in a set of lists and then other sprites and clones can access those set of lists and using Pythagorean and trig” but I'm sure someone will because that's all we have.

Bump and I really wish I could change the title to “Let Clones Have Their Own Names”. I don’t see how “More solid identification for clones” is going to attract anyone’s attention.

Do you suppose if I reported the first post as a zombie topic because it has dead image links that the Scratch Team would scold me?

Or would they close this topic and let me start over with a better title:

Let Clones Have Their Own Names

If the Scratch Team added this feature would it show that they understood equity in a programming language? After all, if clones had names they could be used in these blocks just like Sprites now can.

go to [ v]


point towards [ v]
<touching [ v] ?>
(distance to [ v])
([ v] of [Sprite1 v])

Here's an example of how it would help Scratchers if the Scratch team would Let Clones Have Their Own Names

This is what we must currently do if we want a sprite or clone to point to the nearest clone:

Spentine wrote:

This code will point towards the nearest clone when it is used:

define Point towards nearest clone
set [index v] to (0)
set [closestclone v] to (0)
set [closestdist v] to [Infinity]
repeat (length of [Clones X v])
change [index v] by (1)
set [dist v] to ((((x position) - (item (index) of [Clones X v])) * ((x position) - (item (index) of [Clones X v]))) + (((y position) - (item (index) of [Clones Y v])) * ((y position) - (item (index) of [Clones Y v]))))
if <(dist) < (closestdist)> then
set [closestclone v] to (index)
set [closestdist v] to (dist)
end
end
point in direction (([atan v] of (((item (closestclone) of [Clones X v]) - (x position)) / ((item (closestclone) of [Clones Y v]) - (y position)))) + ((180) * <(item (closestclone) of [Clones Y v]) < (y position)>))

but in order to use that script you must first create this script:

when gf clicked
delete all of [activecloneids v] :: list
delete all of [lastactive v] :: list
delete all of [Clones X v] :: list
delete all of [Clones Y v] :: list
set [past v] to ()
set [cloneid v] to (0)
forever
check clones
wait (0) seconds :: control
end

define check clones
set [number of clones v] to (0)
set [overwritepast v] to ()
set [index v] to (0)
repeat (length of [lastactive v])
change [index v] by (1)
set [overwritepast v] to (join (overwritepast) (item (index) of [lastactive v]))
if <(item (index) of [activecloneids v]) = (1)> then
if <(item (index) of [lastactive v]) = (letter (index) of (past))> then
replace item (index) of [activecloneids v] with (0)
else
change [number of clones v] by (1)
end
end
end
set [past v] to (overwritepast)

when I start as a clone
set [cloneid v] to (item # of (0) in [activecloneids v] :: list)
if <(cloneid) = (0)> then
add (1) to [activecloneids v]
add (x position) to [Clones X v]
add (y position) to [Clones Y v]
add (0) to [lastactive v]
set [cloneid v] to (length of [activecloneids v])
else
replace item (cloneid) of [activecloneids v] with (1)
replace item (cloneid) of [Clones X v] with (x position)
replace item (cloneid) of [Clones Y v] with (y position)
end
forever
replace item (cloneid) of [lastactive v] with ((1) - (item (cloneid) of [lastactive v]))
replace item (cloneid) of [Clones X v] with (x position)
replace item (cloneid) of [Clones Y v] with (y position)
wait (0) seconds :: control
end

Hope this helps!

The following is all that would be needed if the Scratch Team would just budge a bit and let clones have their own names:



This is the script to make 10 clones with names and store them in the list “coins”



(These are pictures of a working SNAP script so the apperence is slightly different from Scratch - but the blocks are the same except for the create a clone with a name block.)

Bump

I really wish this topic could be closed and replaced.

I wonder how many people read the last few posts of a topic whenever it is bumped or do they just look at the first post — which in this case has a really bad title and includes broken image links in the OP that make it harder to understand the suggestion.

The discussion for the rest of this topic is mostly about techniques to use because clones don’t have names. These techniques are always more that just a few lines - so I won’t call them a workarounds — and people are constantly needing help with this issue.