Push out Solid could have a parameter for defining max distance to test for or move.

Inside the custom behavior, the PushOutSolid action has a max distance it will attempt to resolve the collision before giving up. It is something like: max(3xSpeed, 100).

This is simply hard coded in. For one thing, I would prefer if it was a smaller number in many cases.

It would be very nice if this was exposed to the user. In addition, it would also be nice if there was a way to go ahead and have the object move to that max distance, even if the collision isn't resolved.

There are many reasons why you would want to only partially resolve a collision.

The best workaround is to ->

1.Test overlap. If colliding, save position, push from solid and compare the distance from the saved position to the new position.

2.If it hasn't moved, then move it manually whatever max distance you want. If it has moved, and if it has moved more than you want it to, move it back whatever distance is desired.

An alternate is ->

1. Test overlap, if colliding, move the object the desired max and test overlap again. If it is still overlapping (assuming things about level design and max distance to be moved), leave it as it is, if it isn't overlapping any more, reset the object and use the push from solid behavior to move it perfectly from collision.

I’d say the more common use case is for the push out actions to work successfully no matter what. Being able to specify a give up distance seems to needlessly make things more complex. And really if I wanted to do that I’d rather do it manually from the starting position and the pushed out position.

That said, I stopped using the push out actions after finding they weren’t as accurate as I would have liked. Construct likely leans on its very good collision detection functions, but probably does some kind of repeated move and overlap check. So limiting the distance sounds like a way to limit huge loops. Just a guess though.

There are other good solutions for resolving collisions though. A common one is utilizing overlap checks and iteratively moving stuff. If you treat the object you’re pushing out as a circle you can utilize sdfs. Then there’s SAT, GJK, or MPR if you want more deluxe solutions.

I’d say the more common use case is for the push out actions to work successfully no matter what. Being able to specify a give up distance seems to needlessly make things more complex. And really if I wanted to do that I’d rather do it manually from the starting position and the pushed out position.

That said, I stopped using the push out actions after finding they weren’t as accurate as I would have liked. Construct likely leans on its very good collision detection functions, but probably does some kind of repeated move and overlap check. So limiting the distance sounds like a way to limit huge loops. Just a guess though.

There are other good solutions for resolving collisions though. A common one is utilizing overlap checks and iteratively moving stuff. If you treat the object you’re pushing out as a circle you can utilize sdfs. Then there’s SAT, GJK, or MPR if you want more deluxe solutions.

That's the thing though, c3 pushouts fail if they are an arbitrary hard coded distance from the starting point if no solution has been found, and the user doesn't get to decide how far that point is... As you say, I am sure its for performance reasons, and unless things have change in the last 7 years, the old pushout routine was indeed simply moving and testing, and looping, so it obviously has to have a break point, but I'd rather set that myself.

For tilemaps, given a limited index of possible tile shapes, I use some linear algebra to solve push outs. Character on character is treated softer. But my current project is also retro in feel and I actually don't want perfect mathmatically accurate collisions. I like that corner slipping feel you get from a highly calibrated and personal collision engine (like you had in gb link's awakening or mario 3).

One day, I'll have a top down project where I treat everything as a circle and I'll be happy. lol.

To add, in many cases, in pursuit of an eventual solution, it is nice to be able to

a.) decide how far the hard coded "failure distance" is and,

b.) move the object that distance anyway because, overtime, a solution might be found.

Consider Super Mario Bro 3. (If anyone hasn't played it, and make games of the platforming variety, I'd argue some "research" is in order :) . If Mario becomes entrapped (which can occur for a number of reasons), the collision ejection routine will eventually successfully eject Mario from whatever wall he is stuck in. He ejects laterally at 1 pixel per frame. Construct ejects at an all or nothing 100pixels, or speedx3, whichever is greater.