Possible solution to overlap delay (courtesy of BartekB)

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

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

    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)

    Best person at writing incomprehensible posts. Edits are a regularity.

  • Hey, thanks for making it into an example!

    With your iterations downside, you could for each loop an object that requires testing. Then, move all the other possible objects negative delta of the object being for each looped. I think this way you only really need to iterate on one object type for this to work. The rest is taken care of by Fusion.

    To explain my idea here's an example. Please login to see this attachment. (Yes I know that the red objects don't move so it's not necessary here, but it's just proof of concept)

    However, I'm curious how fast both of the solutions are. If I'll get some results, I'll update on that here :)

    - BartekB

    Join the Click Converse Discord! - Please login to see this link.

  • 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.

    Best person at writing incomprehensible posts. Edits are a regularity.

  • 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.

    Best person at writing incomprehensible posts. Edits are a regularity.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!