ocular rewritten

So, recently I had this problem of detecting clone collisions. In the past, it was a piece of cake for detecting clone collisions.
For clones of a sprite named ‘Sprite1’ this predicate does the trick:

<touching (join[Sprite1]()) ?>

However, now I am faced with detecting which clones collide.
Identifying clones is easy enough, just use a sprite-local variable:

(id)

And do this:

when green flag clicked
set [id v] to (0)
repeat [how many clones you want]
change [id v] by (1)
create clone of [myself v]
end

But detecting which clones collide is a serious problem.
I thought of storing the clone ids one after the other in a single variable called:

(clones collided)

For the sake of simplicity, I will assume at most 9 clones are created (which is enough for my purposes as of now and can be generalized later if needed), so that:

(letter (1) of (clones collided))

and

(letter (2) of (clones collided))

will give the id's of the clones collided.
Now to tackle the problem of storing the id's. The clones which collided at some instant will both report:

<touching (join[Sprite1]()) ?>

as true at that instant, as saying clone 1 is touching clone 2 is the same as saying clone 2 is touching clone 1, so in order one after the other is simply breaking this symmetry. We could do this:

when green flag clicked
forever
if <touching (join[Sprite1]()) ?> then
set [clones collided v] to (join(clones collided)(id))
end
end

Suppose we test this script with clone 1 and clone 2. Since both will report:

<touching (join[Sprite1]()) ?>

as true at the same instant, we run at the problem where both clones try to add their id's at the same time, so what does:

(clones collided)

even report? Because both of them do this at the same time, something must go wrong, I don't know what. So how do we detect which clones collide with each other if this solution doesn't work? This almost feels like a paradox.

The only thing you will be able to tell is if a clone is touching another clone and not which clone is touching which. The reason for this is because the only block you can use to detect clone collisions is the touching sprite boolean block which cannot tell clones apart from each other. You could try to track all of the collisions in a list and then detect which clones are close to each other, but it will not be foolproof.

legendary34678 wrote:

The only thing you will be able to tell is if a clone is touching another clone and not which clone is touching which. The reason for this is because the only block you can use to detect clone collisions is the touching sprite boolean block which cannot tell clones apart from each other. You could try to track all of the collisions in a list and then detect which clones are close to each other, but it will not be foolproof.

I have seen quite a few quite a few projects which CAN detect which clones collide, so it is definitely possible. But it is only a small part of massive projects, so looking at the code just wouldn't do any good.

I am not sure how the bigger projects do it, but one method you can apply is adding the coordinates (x and y) and the clone's name/use into a list. Each one will be given its own item. Then you have two options. You can have more clones that act as hitboxes, and detect collision that way, or have a sprite constantly looking at the list, looking for a collision based on how close the x and y coordinates of differents sprites are to each other. It would take a lot, but doable. I will look into how people like GRiffpatch and other big names do it for you.

Yep, that's the method I suggested: comparing coordinates to see how close clones are to each other. The only issue with this is what happens if there's a huge crowd of clones? Sure, comparing coordinates works for two clones, but probably not for twenty.

ABC124816 wrote:

So how do we detect which clones collide with each other if this solution doesn't work? This almost feels like a paradox.

I think I've solved this problem by inserting “wait 0 seconds” (basically, “yield”) in the procedure, to get another colliding clone a chance to also detect that collision.

Please see: https://scratch.mit.edu/projects/828819164/

vladfein wrote:

ABC124816 wrote:

So how do we detect which clones collide with each other if this solution doesn't work? This almost feels like a paradox.

I think I've solved this problem by inserting “wait 0 seconds” (basically, “yield”) in the procedure, to get another colliding clone a chance to also detect that collision.

Please see: https://scratch.mit.edu/projects/828819164/

Nice: Thanks for the tip! (I actually tried the ‘wait 0 seconds’ method, but turns out that I made the wait before adding the id's)

You also don't need the join trick for sprite1 clones to detect touching sprite1 clones, just copy the touching block from another sprite after changing it so sprite1 is selected in the drop-down.

I don't know if you are still looking, but I just shared a project that does clone-to-clone collision identification

grandpasp wrote:

I don't know if you are still looking, but I just shared a project that does clone-to-clone collision identification

dont necropost

kingKASEtheGREATalt wrote:

grandpasp wrote:

I don't know if you are still looking, but I just shared a project that does clone-to-clone collision identification

dont necropost

What's that mean?

grandpasp wrote:

kingKASEtheGREATalt wrote:

grandpasp wrote:

I don't know if you are still looking, but I just shared a project that does clone-to-clone collision identification

dont necropost

What's that mean?

It's posting in an old topic that hasn't received activity in a while and can be considered spam.

BigNate469 wrote:

grandpasp wrote:

kingKASEtheGREATalt wrote:

grandpasp wrote:

I don't know if you are still looking, but I just shared a project that does clone-to-clone collision identification

dont necropost

What's that mean?

It's posting in an old topic that hasn't received activity in a while and can be considered spam.

Thanks! I did not know that.