If you want to detect the drop onto the clone through “touching mouse-pointer” then that's fine. It's easy enough to get the other clones (i.e. the ones not being dragged) to detect when touching mouse-pointer once the dragged clone gets dropped – so you then know both the clone being dragged *and* the clone it was dropped onto (as long as you only take the first clone that's found to be touching mouse-pointer, and ignore later ones).

The problem comes if you want to detect drop onto a clone through “touching (clone of) sprite”. In that case you can't get the dragged clone to detect if touching another clone of the same sprite. (However, see my suggestion above about using another sprite for dragging, which temporarily ‘pretends’ to be the clone that was intended to be dragged.)

I decided to put together an example of how to do (robust & reliable) drag-and-drop of a clone onto other clones (of the same sprite).

As I mentioned above, the extra “Drag” sprite would be unnecessary if the drop target were to be detected only through the mouse-pointer being over it. But choosing to also make it detect when the dragged (pseudo-)clone is *touching* another clone means that the ‘extra sprite method’ I outlined above is probably the easiest way.


https://scratch.mit.edu/projects/131157377/


As I put this together, I realised more and more just how tricky it can be to make something in Scratch that doesn't suffer from potential race conditions…

I had to use various ‘tricks’ to avoid such problems – for example, the use of the “start click” broadcast in the “when sprite clicked” script to avoid the potential for that clicked script getting ‘cut off’ abruptly on the second of two quick clicks.

I also had to make use of my understanding of how Scratch schedules broadcast receiver scripts in order to make things run without a refresh happening between certain stages…

For example, between all the clones doing “touching mouse-pointer” tests, and then all doing “touching Drag sprite” tests, and then indicating which clone the drag is currently over. (The Drag sprite sends three broadcasts during each pass through the drag loop; the first schedules the clones to do a touching mouse-pointer test each, the second schedules the touching Drag sprite tests, while the third targets whichever clone is currently dragged over to make it indicate that by brightening. Only the LAST of those can be broadcast-and-wait, to avoid a refresh happening prematurely, and the reason is actually because of the “go to” block in the *Drag* sprite just *before* those three broadcasts.)

Also, something similar between the hiding of the Drag sprite and the re-appearance of the clicked clone (it creates a ‘broadcast chain’ between sprites, from “drag ended” to “animate combine stack” to “finish combine stack”.)

These things really don't end up being at all straightforward to do ‘properly’, and I can't see how inexperienced Scratchers could have a hope, really…


Anyway, I've included copious comments in the project to (attempt to) help explain what on earth I was thinking – especially for some of these more convoluted parts mentioned above.

Hope it (vaguely) makes some sense!

TheLogFather wrote:

I decided to put together an example of how to do (robust & reliable) drag-and-drop of a clone onto other clones (of the same sprite).

As I mentioned above, the extra “Drag” sprite would be unnecessary if the drop target were to be detected only through the mouse-pointer being over it. But choosing to also make it detect when the dragged (pseudo-)clone is *touching* another clone means that the ‘extra sprite method’ I outlined above is probably the easiest way.


https://scratch.mit.edu/projects/131157377/


As I put this together, I realised more and more just how tricky it can be to make something in Scratch that doesn't suffer from potential race conditions…

I had to use various ‘tricks’ to avoid such problems – for example, the use of the “start click” broadcast in the “when sprite clicked” script to avoid the potential for that clicked script getting ‘cut off’ abruptly on the second of two quick clicks.

I also had to make use of my understanding of how Scratch schedules broadcast receiver scripts in order to make things run without a refresh happening between certain stages…

For example, between all the clones doing “touching mouse-pointer” tests, and then all doing “touching Drag sprite” tests, and then indicating which clone the drag is currently over. (The Drag sprite sends three broadcasts during each pass through the drag loop; the first schedules the clones to do a touching mouse-pointer test each, the second schedules the touching Drag sprite tests, while the third targets whichever clone is currently dragged over to make it indicate that by brightening. Only the LAST of those can be broadcast-and-wait, to avoid a refresh happening prematurely, and the reason is actually because of the “go to” block in the *Drag* sprite just *before* those three broadcasts.)

Also, something similar between the hiding of the Drag sprite and the re-appearance of the clicked clone (it creates a ‘broadcast chain’ between sprites, from “drag ended” to “animate combine stack” to “finish combine stack”.)

These things really don't end up being at all straightforward to do ‘properly’, and I can't see how inexperienced Scratchers could have a hope, really…


Anyway, I've included copious comments in the project to (attempt to) help explain what on earth I was thinking – especially for some of these more convoluted parts mentioned above.

Hope it (vaguely) makes some sense!

I am so sorry as you have worked so hard on this, but this kind of confuses me and I have already received an answer to my topic… soz

sirfused wrote:

I am so sorry as you have worked so hard on this, but this kind of confuses me and I have already received an answer to my topic… soz

Sorry, yes, indeed – I think that was partly the point I was trying to make…

There are certain things in Scratch which really are tricky to do in way that is reliable/robust. You have to ‘jump through hoops’ to avoid running into potential issues under certain (perhaps rare) conditions, such as multiple quick clicks on a sprite, etc.

Sometimes the best way to deal with it might be to avoid it entirely by having the project work in a different way (e.g. rather than trying to use clone-to-clone touching tests to detect drop target, instead use mouse-pointer touching).


Anyway, I've made a little demo project about one of the things I was talking about above – the potential ‘race condition’ with a “when this sprite clicked” hat block.
It's something worth noting when using that: https://scratch.mit.edu/projects/131461567/

Can you simplify this Logfather? As an inexperienced scratcher, i have no clue what you guys are saying, my head is spinning!

I can only think of the most silly way of just creating a million sprites, but I am also having this crisis of making my clones stacked together when moving them together.

I am making a game where there are little black dots, and little green dots. The green dots turn the black dots into green ones, but the problem is, all the dots are clones of the same sprite, so they can't detect each other.

Mackshacks wrote:

I am making a game where there are little black dots, and little green dots. The green dots turn the black dots into green ones, but the problem is, all the dots are clones of the same sprite, so they can't detect each other.

If this topic hasn't answered your question please create a new topic. This topic is marked as ANSWERED so very few people are going to read your post.

In Scratch 3 clones of a single sprite can now detect each other - a sprite/clone is no longer considered to be touching itself.

I'm reading this reply. LOL the OP is more than years old.