Discuss Scratch

Zparx
Scratcher
500+ posts

More solid identification for clones

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

Last edited by Zparx (June 26, 2013 00:56:53)

SFollis
Scratcher
500+ posts

More solid identification for clones

+111111!
blob8108
Scratcher
1000+ posts

More solid identification for clones

If the collision detection for your sprites is simple enough (eg. they're circular), then you can always just have each clone store its position in a global list, and have each clone calculate the distance to every other…

EDIT: wait, so you're thinking if <touching? ([clone 1 v] of [Sprite1 v])>? Maybe you should instead suggest a built-in (clone #) reporter, and a corresponding (clone of ) reporter that you can throw into the “touching?” block. Not that the ST are too keen on first-class sprites anyhow…

Last edited by blob8108 (June 6, 2013 22:09:44)

Zparx
Scratcher
500+ posts

More solid identification for clones

blob8108 wrote:

If the collision detection for your sprites is simple enough (eg. they're circular), then you can always just have each clone store its position in a global list, and have each clone calculate the distance to every other…

Well, that would be extremely complicated, but you are correct. My method would add to the simplicity of Scratch. It just seems like a standard that's missing, you know?
Zparx
Scratcher
500+ posts

More solid identification for clones

blob8108 wrote:

EDIT: wait, so you're thinking if <touching? ([clone 1 v] of [Sprite1 v])>? Maybe you should instead suggest a built-in (clone #) reporter, and a corresponding (clone of ) reporter that you can throw into the “touching?” block. Not that the ST are too keen on first-class sprites anyhow…

Yes! The idea dawned on me because of this project: http://scratch.mit.edu/projects/2678196/

You see, I want to make the algorithm I've used work with cloning, and the only way I can do that is with the method I'm suggesting here. More so, this is what I would be using.

blob8108
Scratcher
1000+ posts

More solid identification for clones

Zparx wrote:

Well, that would be extremely complicated
Aww, c'mon, it's not that complicated! project
blob8108
Scratcher
1000+ posts

More solid identification for clones

Zparx wrote:

this is what I would be using.
Sure. But I'm just saying, naming clones seems a lot more complicated than numbering them.
Zparx
Scratcher
500+ posts

More solid identification for clones

blob8108 wrote:

Zparx wrote:

Well, that would be extremely complicated
Aww, c'mon, it's not that complicated! project

Well not as far keeping track of the coordinates, but the detection methods would be a bit wanky for the project I'm aiming to construct! Also, naming them would be completely different from numbering because there would be a way to detect them by touch! :p

EDIT: Without extra scripting for a workaround!

Last edited by Zparx (June 6, 2013 22:32:37)

blob8108
Scratcher
1000+ posts

More solid identification for clones

Zparx wrote:

the detection methods would be a bit wanky for the project I'm aiming to construct!
True enough; collision detection gets complicated fast. But just approximate it anyway and pretend everything's a simple geometric shape!

Also, naming them would be completely different from numbering because there would be a way to detect them by touch! :p

EDIT: Without extra scripting for a workaround!
I don't understand what you mean by that. It would be feasible to invent a system for detecting clones based on touch that uses either naming or numbering to identify them.
DadOfMrLog
Scratcher
1000+ posts

More solid identification for clones

@Zparx:

Just to make a suggestion about your clone# variable…
You don't need a global, only a local. And you can avoid the wait 0.1 this way too.

Instead of getting the initial sprite to do all the cloning, get each clone to make the next clone. So, the first thing in the “When I start as a clone” is to increment that local variable (so its local copy is its clone number), and then check if the number of clones is still not at the desired limit (in which case the clone creates another clone), before getting on with the work it's meant to do.

In case that explanation wasn't very good (quite possible…), see my 3D Dot Map Demo for an example (it creates ten clones that act as dots for a 3D map, plus a final one that controls a checkbox button).

But yeah, having some way to detect which clone of a sprite you're touching could be handy (though it's often workable to do it the other way around instead - you can get the clone to do the checking if it is touching something rather than checking if something is touching a clone - and then maybe set some global var, with its clone number, that the first sprite can check).
blob8108
Scratcher
1000+ posts

More solid identification for clones

DadOfMrLog wrote:

it's often workable to do it the other way around instead
I thought Zparx was trying to do test if two clones of the same sprite were touching.
7734f
Scratcher
500+ posts

More solid identification for clones

I support.
Zparx
Scratcher
500+ posts

More solid identification for clones

DadOfMrLog wrote:

@Zparx:

Just to make a suggestion about your clone# variable…
You don't need a global, only a local. And you can avoid the wait 0.1 this way too.

Instead of getting the initial sprite to do all the cloning, get each clone to make the next clone. So, the first thing in the “When I start as a clone” is to increment that local variable (so its local copy is its clone number), and then check if the number of clones is still not at the desired limit (in which case the clone creates another clone), before getting on with the work it's meant to do.

In case that explanation wasn't very good (quite possible…), see my 3D Dot Map Demo for an example (it creates ten clones that act as dots for a 3D map, plus a final one that controls a checkbox button).

But yeah, having some way to detect which clone of a sprite you're touching could be handy (though it's often workable to do it the other way around instead - you can get the clone to do the checking if it is touching something rather than checking if something is touching a clone - and then maybe set some global var, with its clone number, that the first sprite can check).

If I'm incrementing each clone's local variable, won't all of the clones' local variables equal the same? For instance, if I set the local to 1, each clone would change it by 1, which, as you know, would equal 2. Your method seems to manipulate local variables as global variables..

Does that work?


Hmm, also, here is what I'm trying to accomplish in a nutshell:

There is a sprite on the map that constantly checks which specific clone it's touching and has a circular perimeter in which to do so. All of these clones are following a set path in line, no more than 10 steps apart. If a clone is BOTH within range of the sprite's perimeter AND closest to the front of the group of clones that the sprite can “see”, THAT is the clone it “selects”. This is how my algorithm for detection would work.

The list “Targets” would be filled will the clone names in any random order. Also, it's important to keep in mind that the clones can exit and re-enter the range of the sprite! Which is why the two variables have to be switching constantly to check if that has happened. Here is a project that has this exact code implemented and demonstrates what I'm trying to do flawlessly.

The purple things are separate sprites. I want to be able to do what I've done in that project with them, using clones instead.

Last edited by Zparx (June 7, 2013 19:47:07)

firedrake969_test
Scratcher
500+ posts

More solid identification for clones

+((sqrt -1)^4) * 3.1415926535897…..

And just realized this could be interpreted as spam. xD

Support. You could make one sprite be the whole game with this!

Last edited by firedrake969_test (June 7, 2013 22:18:47)

Zparx
Scratcher
500+ posts

More solid identification for clones

firedrake969_test wrote:

You could make one sprite be the whole game with this!

PRECISELY. This is another great reason to have this method implemented! Plus this would redefine 1s1s projects forever!

Last edited by Zparx (June 7, 2013 22:37:46)

DadOfMrLog
Scratcher
1000+ posts

More solid identification for clones

@Zparx:

“If I'm incrementing each clone's local variable, won't all of the clones' local variables equal the same? For instance, if I set the local to 1, each clone would change it by 1, which, as you know, would equal 2. Your method seems to manipulate local variables as global variables..”

No - local variables really are local - local to each clone.

What you do is have the local var (let's call it “myCloneID”) set to zero when gf pressed, so the original sprite has the value of zero. Then the first thing you put after “when I start as a clone” is “change myCloneID by 1”, and then have that clone create the next (if required number not yet reached).

So what happens is that you have the original sprite, which has myCloneID set to zero, start the first clone. That clone gets the value zero and adds one, so it has the value of one. That clone next goes on to make another clone (assuming more are needed).

The second clone starts up and it *inherits* the value of one from the first clone - but the first thing it now does when it starts up is add one, so it then has the value two. And it goes on to start up another clone (if the required number has not yet been reached).

The third clone then inherits the value two (from the second), but it adds one straight away, so it gets three.

And so on…


So the sequence is:

when GF pressed
set myCloneID to 0
create clone of myself
…do more stuff…

when I start as a clone
change myCloneID by 1
if myCloneID<requiredClones then
create clone of myself
endif
…do more stuff…

Hope that makes sense!
Zparx
Scratcher
500+ posts

More solid identification for clones

DadOfMrLog wrote:

@Zparx:

“If I'm incrementing each clone's local variable, won't all of the clones' local variables equal the same? For instance, if I set the local to 1, each clone would change it by 1, which, as you know, would equal 2. Your method seems to manipulate local variables as global variables..”

No - local variables really are local - local to each clone.

What you do is have the local var (let's call it “myCloneID”) set to zero when gf pressed, so the original sprite has the value of zero. Then the first thing you put after “when I start as a clone” is “change myCloneID by 1”, and then have that clone create the next (if required number not yet reached).

So what happens is that you have the original sprite, which has myCloneID set to zero, start the first clone. That clone gets the value zero and adds one, so it has the value of one. That clone next goes on to make another clone (assuming more are needed).

The second clone starts up and it *inherits* the value of one from the first clone - but the first thing it now does when it starts up is add one, so it then has the value two. And it goes on to start up another clone (if the required number has not yet been reached).

The third clone then inherits the value two (from the second), but it adds one straight away, so it gets three.

And so on…


So the sequence is:

when GF pressed
set myCloneID to 0
create clone of myself
…do more stuff…

when I start as a clone
change myCloneID by 1
if myCloneID<requiredClones then
create clone of myself
endif
…do more stuff…

Hope that makes sense!

I understood what you meant the first time, I just didn't know that local variables value could be “inherited” to the next clone. That's pretty neat!
blob8108
Scratcher
1000+ posts

More solid identification for clones

I still think your “clone () of ()” block needs to be a separate block – the ST couldn't overload the “of” operator in that way because otherwise a clone with a name “Bob” would hide a sprite-specific variable named “Bob” from being accessed through the “of” block.

Edit: URL-copy fail

Last edited by blob8108 (June 8, 2013 12:09:37)

DadOfMrLog
Scratcher
1000+ posts

More solid identification for clones

@Zparx:

Yeah, neat & useful - when you clone a sprite it inherits everything from the one it was cloned from - position, costume, show/hide, size, graphics effects, etc.

One thing I haven't tried, that I just thought of… what happens when you make a clone of a different sprite? i.e. you say “create a clone of something-else”. No idea where that clone gets its settings… something to investigate!
dracae
Scratcher
1000+ posts

More solid identification for clones

support, I guess?
I never knew that first method you said worked!
So cool!

Powered by DjangoBB