I ran into a bit of a weird problem with how the collision check is worked.
I’m currently working on a drag and drop system where it would always snap into a holder or snap back to its origin point before the drag.
This is what the event for that looked like :
For whatever reason it seemed that there is an inconsistency in deciding which one is in collision. The holder always prefer that the top half of the Dragged Object touch it with the exception of the second to last in the column, always. Where it seemed to prefer none at all or let all the surrounding holder have priority over it.
The “DragGroup is in collision with HolderGroup” generates a list of candidate HolderGroup objects. So when you release the mouse button while the DragGroup overlaps 2 CmdBlocks, those two get selected. For whatever reason, the other CmdBlock is being selected to the one you want - I believe the z-order take priority. When the z-order is the same, then it looks like it goes down to the order that the objects were created - first made, first served. In the case of the CmdBlocks, the second to last one in the scene has been created after both the CmdBlocks above and below it, so it loses out in both cases and doesn’t get picked.
I suggest that, as well as the theDragGroup-HolderGroup collision check, you add a second condition to choose the closest HolderGroup to the DragGoup. This will narrow it down to the CmdBlock that the dragged command is overlapping the most.
