An addition to the

(distance to [ v])

block that allows you to call a clone of the sprite, outputting the distance to the nearest clone of the sprite.

However, clones don't really have names, so what do you plan on putting in that box?

A workaround is marking the x and y positions using a list of every clone and using clone id. Then calculating the distance to each of those (using the distance formula).
And this is a duplicate then (oldest topic last):
https://scratch.mit.edu/discuss/topic/611446
https://scratch.mit.edu/discuss/topic/397575 (similar)
https://scratch.mit.edu/discuss/topic/272999
https://scratch.mit.edu/discuss/topic/174990 (similar)
https://scratch.mit.edu/discuss/topic/130392
https://scratch.mit.edu/discuss/topic/125386
https://scratch.mit.edu/discuss/topic/81732

blablablahello wrote:

However, clones don't really have names, so what do you plan on putting in that box?

the suggestion itself says “nearest clone of sprite”, so it will be searching for any clone and picking the one closest to the given sprite.

carteradams123 wrote:

blablablahello wrote:

However, clones don't really have names, so what do you plan on putting in that box?

the suggestion itself says “nearest clone of sprite”, so it will be searching for any clone and picking the one closest to the given sprite.

that sounds VERY specific, it only solves a single, extremely rare problem. What if I wanted to search for the distance to the other clones? this doesn't even provide a workaround for that

blablablahello wrote:

carteradams123 wrote:

blablablahello wrote:

However, clones don't really have names, so what do you plan on putting in that box?

the suggestion itself says “nearest clone of sprite”, so it will be searching for any clone and picking the one closest to the given sprite.

that sounds VERY specific, it only solves a single, extremely rare problem. What if I wanted to search for the distance to the other clones? this doesn't even provide a workaround for that

It can also pick the wrong clone of a sprite.

blablablahello wrote:

carteradams123 wrote:

blablablahello wrote:

However, clones don't really have names, so what do you plan on putting in that box?

the suggestion itself says “nearest clone of sprite”, so it will be searching for any clone and picking the one closest to the given sprite.

that sounds VERY specific, it only solves a single, extremely rare problem. What if I wanted to search for the distance to the other clones? this doesn't even provide a workaround for that

fair enough, but we get to a point where we're over complicating. My suggestion would be useful for clone pathfinding, such as an AI opponent seeking out the nearest enemy to fight.

carteradams123 wrote:

blablablahello wrote:

carteradams123 wrote:

blablablahello wrote:

However, clones don't really have names, so what do you plan on putting in that box?

the suggestion itself says “nearest clone of sprite”, so it will be searching for any clone and picking the one closest to the given sprite.

that sounds VERY specific, it only solves a single, extremely rare problem. What if I wanted to search for the distance to the other clones? this doesn't even provide a workaround for that

fair enough, but we get to a point where we're over complicating. My suggestion would be useful for clone pathfinding, such as an AI opponent seeking out the nearest enemy to fight.

it would be useful for and only for closest enemy pathfinding, which can be done in a more effecient way by simply storing the enemy data in a list, as otherwise you only know the distance, not the location anyways

I've looked at the workaround and believe that this is another case where the Scratch ceiling has been reached. Clones don't have names and even though a workaround has been described, it feels like a kind of Scratch microcode. I'm not trying to be argumentative but there is a lot of discrete processing of lists which also need to be created with discrete processes.

So, I think visiting SNAP for this feature would be worthwhile.



In case you're interested I have a SNAP program that moves the sprite toward its closest clone, which gets deleted, and then onto the next closest.

https://snap.berkeley.edu/embed?projectname=Nearest%20Clone&username=10goto10&showTitle=true&showAuthor=true&editButton=true&pauseButton=true

10data10 wrote:

I've looked at the workaround and believe that this is another case where the Scratch ceiling has been reached. Clones don't have names and even though a workaround has been described, it feels like a kind of Scratch microcode. I'm not trying to be argumentative but there is a lot of discrete processing of lists which also need to be created with discrete processes.

So, I think visiting SNAP for this feature would be worthwhile.



In case you're interested I have a SNAP program that moves the sprite toward its closest clone, which gets deleted, and then onto the next closest.

https://snap.berkeley.edu/embed?projectname=Nearest%20Clone&username=10goto10&showTitle=true&showAuthor=true&editButton=true&pauseButton=true

things like this are why I suggested the block- I don't want to make a list and several variables for trying to figure out where the nearest clone of a given sprite is.

carteradams123 wrote:

10data10 wrote:

I've looked at the workaround and believe that this is another case where the Scratch ceiling has been reached. Clones don't have names and even though a workaround has been described, it feels like a kind of Scratch microcode. I'm not trying to be argumentative but there is a lot of discrete processing of lists which also need to be created with discrete processes.

So, I think visiting SNAP for this feature would be worthwhile.



In case you're interested I have a SNAP program that moves the sprite toward its closest clone, which gets deleted, and then onto the next closest.

https://snap.berkeley.edu/embed?projectname=Nearest%20Clone&username=10goto10&showTitle=true&showAuthor=true&editButton=true&pauseButton=true

things like this are why I suggested the block- I don't want to make a list and several variables for trying to figure out where the nearest clone of a given sprite is.

This is an extremely uncommon use case for clones, using duplicate sprites would be better for a situation like this

cookieclickerer33 wrote:

This is an extremely uncommon use case for clones, using duplicate sprites would be better for a situation like this

But what if you wanted to do this with 50 sprites? Would you make 50 individual sprites? 300 individual sprites?

And even if it is uncommon if someone wanted to study how to manage the clones in a project shouldn’t they have a straightforward way to do that without using Scratch microcode?

10data10 wrote:

cookieclickerer33 wrote:

This is an extremely uncommon use case for clones, using duplicate sprites would be better for a situation like this

But what if you wanted to do this with 50 sprites? Would you make 50 individual sprites? 300 individual sprites?

And even if it is uncommon if someone wanted to study how to manage the clones in a project shouldn’t they have a straightforward way to do that without using Scratch microcode?

I think this may actually be a dupe as I remember seeing something similar
Let me try and find it