I have a digging ability within my game where if the player has entered their digging state and then enter a wall, then on colliderEnter I set the collider to is Trigger and the player keeps moving. Then, after a certain amount of time, the digging state stops and if the player is still in the ground, they are forced in the opposite direction that they entered the wall. In OnTriggerExit, the collider is set back to non-trigger.
However, if the player enters a corner at a certain angle, when they are forced backwards, they can be forced backwards through the corner and into the ground forever.
I would assume the collision/trigger events to be coded as one frame the player is in, and call it if they aren’t the next frame.
The player upon moving backwards is moving at a fast velocity such that there is no intermediate frame where the player has fully exited the collider, even though the player does pass through that area.
One solution I thought could work was to make the force-out speed lower, which would make the issue less common but still there on lower framerates.
How could I make this work?
If the player is still in the wall and the digging state ends then instead of forcing them backwards and hoping for the best, you can move them to the exact position they initially started digging from.
Fixed it by doing this but also the cause of the problem was gravity being applied somewhere during the start of digging, it’s end, and the player being forced out resulting in the player being lower and not being where they should.
I can see you’ve marked this as solved but I think it’s worth mentioning some stuff either for you or others reading it:
You keep using the word “frame” when discussing physics so I can only assume here, you’re running physics per-frame. If not, there’s no relationship between frame-rate and physics.
There’s no such callback. I can only presume you meant OnCollisionEnter2D?
Note that manipulating the collider type is messing with the callbacks here, it’s not just a setting with no side-effects. Whilst Physics allows you to make drastic changes to a collider like this, changing it can cause complexities if you’re relying on the respective callbacks and its state. Changing layers or the layers it can contact are low-overhead / no side-effects way to control what can contact what here.
Also, changing it to trigger then later changing it back is forcing overlaps, something the solver is always trying to avoid in the first place; you should avoid creating these kinds of situations. Maybe this is all Kinematic though, not sure.
I think the best way to solve these kinds of situations is to not get into them in the first place. I’ve seen this kind of thing where it’s important for the visuals to look like they’re moving into something but the physics “gets in the way” and the answer is to only move the visuals or temporarily set the simulation of the Rigidbody2D to off while you’re doing it. Relying on callbacks though while doing this kind of manipulation is a bad idea, it should be done with queries/Kinematics.
Queries can tell you what might happen, callbacks tell you what has already happened and has already been processed by the physics system.