Objective:
User can click on any object and a selected indicator will appear on that object (working)
User can then drag the selected object to a new position, even if two objects overlap.
Types of overlap:
one object is partly or fully within the rectangle area of another object, but not in a collision state
two objects are in a collision state and the click occurs where the two objects overlap.
The .zip located at the URL below contains an example of 3 objects - orange square, blue U, green Z
square and U are examples of overlap type 1
U and Z are examples of overlap type 2
I tried using the disable behavior on draggable, but when it is re-enabled, it takes a second click before the object responds to the drag - not acceptable.
This is something that can be called “not optimal behavior” or in other word a “bug” depends on your perspective.
I think the draggable behavior should just work without any work around required but maybe there is a “logical” explanation why is it not working with the U shape but the problem is, because the collision check and mouse over object event also play up with the U shape and the Physics engine also seems to dislike the U shape, you can’t even create your own draggable behavior for this because you would get the same result…
So, the way I see it, unless the devs look in to this you are out of options with using events unless I missed something too which is possible.
In my searching of the forum on alternatives for the “non optimal behavior” (thanks for that @ddabrahim) of the draggable behavior, I discovered the following post:
So, I removed the Draggable Behavior from all of my objects and adapted the code from Lizard-13 (thank you!) to my purposes. Specifically, I didn’t want the shape to jump when the mouse was clicked, so I added the X and Y offset values. From the user’s perspective, it looks just like a normal drag and drop scenario, but underneath it really isn’t.
While it probably isn’t the most efficient way to handle this issue, at least I have a workaround. I hope that @4lan can come up with a fix to the draggable behavior that will eventually make this code unnecessary.
For those interested, the block of code is as follows:
This is going to be painful when I start dealing with all 10 shapes in the puzzle, but at least i don’t have to worry about shapes overlapping and/or overlapping hit boxes.
Since I’m still learning this system, is there a way to optimize my solution using External Events or Functions or custom Behaviors?
With a combination of using object groups and custom behavior and function, I managed to reduce all that in to a single event to use for all and any objects to drag.
All you need to do is add all your shapes to an object group, add the behavior to the objects as usual and then call a single event a single time to pick all the objects from the group to drag.
If you like it, you can export the behaviour from the project and import it in to your own.
The only problem is that the behavior pick and drag all objects overlapping. It could be worked around, but I think the objects not going to overlap in your project anyway and hopefully 4ian going to be able to fix the problem with the draggable behavior soon.
