Possible solution to overlap delay (courtesy of BartekB)

So [MENTION=14816]BartekB[/MENTION] posted a neat idea in the Fusion 2.5+ thread when I mentioned the Overlap Delay bug.

Quote from BartekB

[MENTION=14381]casleziro[/MENTION] Not related to the question's answer, but have you considered having invisible hitbox actives at 0,0, moving the first object in relation to the second* and checking against that instead? I started wondering of other workarounds when you have listed yours. I have not tested this yet, but in theory it should work.

* By "Moving the first object in relation to the second" I mean:

then... in another event:

lastly...

This makes use of the fact that collision masks don't move, therefore, you move the first object in relation to how the collision would actually happen.

In another similar solution, you could save the position at start of event loop, then when you want to overlap, you move the first object negative of what the second object moved with this expression:

Same for Y. This solution has the advantage of not using an additional object as the collision mask.

I do not want to derail this thread that is about 2.5+. So perhaps a new thread should be opened up if this is going to be discussed further.

Display More

At first I thought his solution wouldn't work, similar to the "prediction" method that had been tried previously, but I threw something together anyways and I think I might have been wrong: Please login to see this attachment.

This appears to be working 100%.

The only downfall I can see is that in order to use this method, you would need to iterate through each object that can be collided against, and move the initial testing object through all of their delta positions and back in order to test collision, and do this for every testing object. This might end up being more expensive than the "create new object" method in the grand scheme of things

But unless anyone finds a situation where this method fails, I think it can be added to the list of solutions to this problem.

Tagging [MENTION=18866]schrodinger[/MENTION] and [MENTION=15682]Volnaiskra[/MENTION] since we all brainstormed hard about solutions to this in the past X)

Realized I had the "move" events under the "move relative" events. Switched them around:Please login to see this attachment.

Hmm, am I doing something wrong here? In your example, I'm trying to move the "A" object back a pixel when overlapping the "B" object, but it doesn't seem to be interacting correctly: Please login to see this attachment.

I tried the method in my original example too, but the same thing happened. I even tried moving A back, moving B back by offset, then closing the group entirely so nothing else could be run, but it still happened.

Figured it out. I needed to move the second object to its original position before I move the first object back a pixel for collision, otherwise the second object will always slide through the first. It's simpler to use another value, "x original" for the second object, and set that to its initial position before the offset for collision, then move it back to that value after.

Please login to see this attachment.