[BUG] Character gets stuck in wall

JamesG

New member
This is not specific to the Climb pack but this is where I reproduced this:
  1. Open the Demo scene in the Climb pack
  2. In the Hierarchy, expand Nolan->Colliders and select the Capsule Collider gameobject
  3. In the Inspector, for the Capsule Collider component set the Center Z property to 0.2 This will move the capsule slightly forward.
  4. Run the game and select 3rd person
  5. Walk directly into a corner
  6. Attempt to walk away and notice that the character is now stuck
Not related to the bug but the reason I want to push the capsule collider forward a bit is to prevent the character from floating when inching off a ledge.
floating.png
 

Justin

Administrator
Staff member
When I tried this the collider was still slightly on the floor which causes the floating in the air. You can fix this by adding the slide ability.
 

JamesG

New member
Thanks for the reply Justin.
In the Climb Demo, the Slide ability is already applied to the character and the floating is still possible. Perhaps some of the properties need to be adjusted? Unfortunately my attempts did not yield results.

It fails the CanSlide() check in this bit of code:

C#:
// Don't slide if the character can step over the object.
var groundPoint = m_Transform.InverseTransformPoint(m_CharacterLocomotion.GroundRaycastHit.point);
if (groundPoint.y >= 0) {
    groundPoint.y = 0;
    groundPoint = m_Transform.TransformPoint(groundPoint);
    var direction = groundPoint - m_Transform.position;
    if (m_CharacterLocomotion.OverlapCount((direction.normalized * (direction.magnitude + m_CharacterLocomotion.Radius)) +
        m_CharacterLocomotion.PlatformMovement + m_CharacterLocomotion.Up * (m_CharacterLocomotion.MaxStepHeight - m_CharacterLocomotion.ColliderSpacing)) == 0) {
        return false;
    }
}
 
Last edited:

Justin

Administrator
Staff member
I was using the default settings from the demo. What is the cast overlapping with? If you remove that logic does it work?
 

JamesG

New member
I am also using the default settings from the Climb demo.

The slope check will also cause slide ability to fail. The following code screencap was taken while debugging so you can see the values(in grey next to the code) at the time it failed.
Slope.png

If it doesn't fail the slope check, it can fail the overlap check next:
overlap.png

The overlap object m_CharacterLocomotion.GroundRaycastHit(RoomWall3 (21)):
groundhit.png
 

Justin

Administrator
Staff member
What is the position/rotation of your character when this raycast is performed?
 

Justin

Administrator
Staff member
Perfect - I wasn't standing in the correct position. You can fix this by changing the step detection check to:

Code:
            if (groundPoint.y >= 0 && m_CharacterLocomotion.Moving) {

The Moving check is the new condition.
 

JamesG

New member
So after further testing in the demo room, I was able to still repro the issue because the Slide.CanSlide() function fails the slope check:
1653349376070.png
1653349272664.png

It appears that the m_CharacterLocomotion.GroundRaycastHit.normal is picking up the edge of the box collider for the ShortClimb object.
1653349351535.png
 

Justin

Administrator
Staff member
In that situation changing the minimum slope on the slide ability should fix it. When I tested it the slope was around 18 so if you decrease it to 15 then that situation should return true for can slide.
 

JamesG

New member
Thanks for the reply Justin.
The lower slope minimum limit does work in the situation above but in practical terms, the side effects may not be desirable. Low grade ramps will cause the character to slide down them, for example in the UCC Demo scene a minimum slope value of 29 or lower will cause the character to slide down this ramp:
1653408974426.png
 
Last edited:

Justin

Administrator
Staff member
In cases like those you will likely need to use the state trigger and change the slope based on the location. I know this isn't ideal but Unity is returning that angle value through the raycast and I can't think of a different way to approach it given that's the returned angle.
 

JamesG

New member
Understood about not being able to do anything about the Unity black box.

Another way to mitigate the feet hanging off the edge of a ledge is to push the capsule collider slightly forward in the z-axis. The problem with this solution is that the character will get stuck in the wall as described in the original post in the thread:

Is it a known issue or restriction that offsetting the capsule collider will break wall collisions?
 

Justin

Administrator
Staff member
You can move the capsule collider to any position and the raycasts will factor in at the location of that collider.
 

JamesG

New member
Justin,
As mentioned in the original post adjusting the capsule collider Center z-axis property results in the character getting stuck in walls. The repro steps are detailed in the original post but all you need to do is adjust the collider z axis property, run the game and walk into a corner and then attempt to walk away and the character will become stuck:

WallStick.gif
 

Justin

Administrator
Staff member
I looked into this and it wasn't an issue with the collider position. The character is using root motion and when you try to move backwards the rotation speed isn't fast enough so the character runs into the wall. You can fix this by increasing the rotation speed on the character locomotion component.
 

JamesG

New member
I adjusted the Motor rotation speed from 10->30 and this did prevent the character from getting stuck in the corner but this has a very noticeable side effect of no longer smoothly rotating when sliding along the wall:

Default values, character rotation along the wall is smooth:
Motor Rotation Speed = 10
Capsule Collider Center Z = 0
SmoothWall.gif

Adjusted values, character rotation snaps drastically and the input requirements to change direction feel extreme. This results in a negative player experience.
Motor Rotation Speed = 30
Capsule Collider Center Z = 0.2
StuckWall.gif
 

Justin

Administrator
Staff member
Yes, that looks correct. It's a tradeoff between smooth blending and responsiveness. You could also try not using root motion if you want more responsive movement.
 
Top