I Think there should be a id for each clone (Clone id) that you could use to separate what each clone does

when I start as a clone
if <Clone ID = [1]> then
Do Bla Bla Bla (4)

Before anyone says it, yes I know this thread said it was created by me. I transplanted this from a completely unrelated thread it was originally posted in, and that requires me to first make a thread and move the post to it, then delete my OP. Please keep discussion about the idea and not DjangoBB's quirks.

This is an interesting idea! Having some kind of way to identify clones is potentially useful and is a pretty common idea in other languages - I'm interested what similar solutions the community has already devised.

Harakou wrote:

Before anyone says it, yes I know this thread said it was created by me. I transplanted this from a completely unrelated thread it was originally posted in, and that requires me to first make a thread and move the post to it, then delete my OP.

This is an interesting idea! Having some kind of way to identify clones is potentially useful and is a pretty common idea in other languages - I'm interested what similar solutions the community has already devised.

Ohhhh. I got confused XD

Clone IDs are already possible using local variables, but it's not an obvious way.

red_king_cyclops wrote:

Clone IDs are already possible using local variables, but it's not an obvious way.

It's not that hard, I do it all the time

Whenever you create a clone you have to change the ID
Here's an example of what I would do:

set [clone ID v] to [0]
repeat (--)
create clone of [this sprite v]
change [clone ID v] by (1)
end

when I start as a clone
if <(clone ID) = [1]> then
...
end

when I start as a clone
if <(clone ID) = [2]> then
...
end

Wahsp wrote:

red_king_cyclops wrote:

Clone IDs are already possible using local variables, but it's not an obvious way.

It's not that hard, I do it all the time

Whenever you create a clone you have to change the ID
Here's an example of what I would do:

set [clone ID v] to [0]
repeat (--)
create clone of [this sprite v]
change [clone ID v] by (1)
end

when I start as a clone
if <(clone ID) = [1]> then
...
end

when I start as a clone
if <(clone ID) = [2]> then
...
end

I did not mean that it is hard to make clone IDs with local variables, I meant that it is not obvious that you use local variables to make clone IDs. It took me many months before I found out that local variables can be used to make clone IDs. How was I supposed to know that local variables have something to do with clones?

Wahsp wrote:

red_king_cyclops wrote:

Clone IDs are already possible using local variables, but it's not an obvious way.

It's not that hard, I do it all the time

Whenever you create a clone you have to change the ID
Here's an example of what I would do:

set [clone ID v] to [0]
repeat (--)
create clone of [this sprite v]
change [clone ID v] by (1)
end

when I start as a clone
if <(clone ID) = [1]> then
...
end

when I start as a clone
if <(clone ID) = [2]> then
...
end

Whether its easy is irrelevant to how obvious it is.
For example, it's easy to get the warp flute in Mario Bros 3, but to someone who wasn't told how, they most likely wouldn't be able to find it.

What I suggest is an easier way to find out about how local variables work with relation to clones, rather than adding a new feature entirely.

Support, it will help people who don't exactly know cloning yet, and also people who want the clones to do different things without using more sprites.
Just having a variable isn't the obvious way, and it would definitely take longer.

badatprogrammingibe wrote:

Whether its easy is irrelevant to how obvious it is.
For example, it's easy to get the warp flute in Mario Bros 3, but to someone who wasn't told how, they most likely wouldn't be able to find it.

What I suggest is an easier way to find out about how local variables work with relation to clones, rather than adding a new feature entirely.

^ Definitely this.
Although the help feature is kind of hidden I think that the help for the “create clone of ___” block should make a mention about local variables.

This kind of thing has been suggested numerous times before. Here are a few examples:
https://scratch.mit.edu/discuss/topic/6508/
https://scratch.mit.edu/discuss/topic/9318/
https://scratch.mit.edu/discuss/topic/124500/
https://scratch.mit.edu/discuss/topic/184244/
https://scratch.mit.edu/discuss/topic/244243/
https://scratch.mit.edu/discuss/topic/304387/


TBH, though, I don't understand how it's that different from just having a global counter that you increase by one for each clone that's made, and have a “this sprite only” variable that takes the value of that global when a clone gets created:

when GF clicked
set [clone counter v] to [0]
do some stuff... :: grey
create clone of [myself v] // at some point
do some other stuff... :: grey
when I start as a clone
change [clone counter v] by (1) // increase this for each new clone
set [clone ID v] to (clone counter) // now the clone has a unique ID
do some stuff based on (clone ID)... :: grey

However, I think what you really want to know isn't so much what a clone's number is, but what a clone is meant to *do* – and you can tell it that by setting a local ‘this sprite only’ variable (or several, if necessary) to some appropriate identifier info before starting a new clone.

This is much more general, allowing you to decide for yourself exactly how a clone identification system is going to work for your particular project.

For example:

when GF clicked
set [clone behaviour v] to [creator] // this is to identify the original sprite (that creates things as clones)
hide // the original sprite may not need to be visible – it just creates things that are shown
more initialisation for this creator sprite :: grey
when I receive [start game v] // perhaps a broadcast sent from some menu system (e.g. a "start" button)
repeat until <(game over)=[yes]>
if <it's time for a new enemy type 2 to appear :: grey> then
set [clone behaviour v] to [enemy type 2] // set it temporarily to tell new clone what type of thing it is
create clone of [myself v] // note that "clone behaviour" above is a local variable
set [clone behaviour v] to [creator] // now set it back for the creator sprite
end
whatever else the creator sprite does... :: grey
end
when I start as a clone
if <(clone behaviour)=[enemy type 1]> then
whatever initialisation is needed for this type of clone... :: grey // e.g. position, costume, etc.
show // probably needs to show at some point
repeat until <(game over)=[yes]> // could maybe do it like this...
whatever behaviour type 1 should have... :: grey
end
else
if <(clone behaviour)=[enemy type 2]> then
initialise this clone in whatever way... :: grey
repeat until <touching [edge v]?> // maybe this enemy does something like this...
whatever behaviour type 2 should have... :: grey
if <(game over)=[yes]> then // perhaps it also needs to go away once game is over
delete this clone
end
end
else
etc... :: grey
end
end
delete this clone // should usually delete clone once done with it
when I receive [tell everything something happened... v] // clones also respond to broadcasts
if <(clone behaviour)=[enemy type 1]> then // so you can have different types of clone react in different ways...
etc... :: grey
end

As others have mentioned above, though, I do think it's not immediately obvious that a ‘this sprite only’ variable also means each clone has its own independent value for such a variable. Too often a clone is kinda thought of as being a ‘part’ of the sprite it came from, rather than being a sprite in its own right. (I mean, a clone of a sprite is also a sprite, after all!)

It would be nice to see some reference to such things in the help, if possible.

Anyway, hopefully there might be some useful ideas somewhere in there.

TheLogFather wrote:

This kind of thing has been suggested numerous times before. Here are a few examples:
https://scratch.mit.edu/discuss/topic/6508/
https://scratch.mit.edu/discuss/topic/9318/
https://scratch.mit.edu/discuss/topic/124500/
https://scratch.mit.edu/discuss/topic/184244/
https://scratch.mit.edu/discuss/topic/244243/
https://scratch.mit.edu/discuss/topic/304387/
<snip>

Thanks for the link and the awesome work-arounds! It does look like this is a duplicate topic so I'll close it to keep the conversation all in one place.

Please use the oldest existing topic in the links above - I'll start consolidating them back to that one.