I have a Character Controller component attached to the same Game Object as a script that moves the Character Controller on the XZ plane without applying gravity:
I’ve included (but commented out) the code to draw the debug lines, just to show where that comes from. It draws debug lines in alternating colors to show the delta movement of that frame.
The issue I’m having is that the Character Controller snaps up or down to unexpected heights in different scenarios:
Moving into a box from the air that is higher than the stepOffset, but lower than stepOffset + radius will snap the Character Controller down. The box is of height 2 and the Character Controller moves from 1.08 to 0.305 on contact with the box as seen at the end of the following video. It first steps up some smaller boxes that are lower than the stepOffset of 0.8 to reach the height of 1.08 (the second last box is 1 unit high + 0.08 skinWidth), before it hits the box that moves it down.
offensiveharmlessibis
Moving around a corner of a box that is higher than the stepOffset, but lower than stepOffset + radius, will snap the Character Controller up.
creamyhealthyhornedviper
This documentation for the step offset states that it will only move it up, not down. So i’m wondering what happens under the hood with the stepOffset as the Character Controller moves down in case 1.
Case 2 is also contradicting the documentation as the box is higher than the stepOffset.
I’m running this with unity 2018.3.7f1 and the character controller settings are:
The Slope Limit and Skin Width don’t affect this unexpected behaviour, it seems to be only linked to Step Offset and Radius.
It would be nice to get some more information on how the radius is affecting the height it can step up boxes that are higher than the Step Offset.
I’ve got the same issue (my character controller can climb the corner of a box that’s higher than the step height), looks like it’s still not fixed in Unity 2019.2. Anybody know of a solution?
Best workaround I can think of is to track the position from the previous frame and if the height jumps up more than the step height in one frame, snap back to the previous position. That’s just asking for something to break if there’s anything else moving nearby, though.
Has anyone had any experience dealing with these issues? A simple character controller (such as the one in Brackey’s recent FPS Controller video) will have the same issues. The best way I’ve found to reproduce the issues is jumping into probuilder stairs from the side. It only seems to “jerk” or “snap” down when close to the point where the player would be able to step up via the step offset.
Given the track record, I highly suspect that this will get addressed… This is yet another example of Unity’s “builtin” feature that “looks” like it can be used for the game production, but when you try something a little deeper, you get this kind of issues.
Is there any event handler from the Character Controller like an OnStepOffset or something that we can attach code to that would prevent this? Is there a better solution in the meantime?
Any drawbacks to just using a capsule collider and trying to code these behaviors of the character controller manually? Does anyone have a script they recommend for a replacement to the character controller that just uses a capsule collider as mentioned?
So far my jank solution is to just set Slope Limit to 90 and accept the fact that players will be able to scale every sloped surface, and just design my levels with vertical walls as the bounds. In some sense this isn’t so bad because it provides a lot of freedom of movement, and its very easy for the player to internalize that any sloped surface can be scaled, rather than be interrupted in the middle of scaling a slope by not being able to move forward when they hit the arbitrarily decided slope limit.
My advice to you, so that you do not lose weeks of development time like I have. Write your own, Come up with your own solution for this. You will more likely to win that way than trying to over come this.
I am out of town for the holiday but I do not have this issue in my project. A few things –
Set Minimum Move Distance to 0. I have no idea why Unity has this set to 0.001, their own documentation says that it should be 0 in most cases. It can cause problems. It only exists for performance reasons and the performance difference is minimal. When you start expanding your code with more complex mechanics, this minimum move distance will get in the way and you’ll spend an entire day trying to figure out whats wrong with your code and realize Unity doesn’t set the default values of things to their recommendations…
Skin Width should be lower. Unity recommends 10% of the radius which would be 0.03.
I don’t know if either of these are related or will fix the issue. But they will cause problems in other areas. I’ll do some more looking around when I get back. A simple thought - you could supplement your code with something that limits the y mobility of a move to the step height. Gimmicky fix, but shouldn’t be difficult. I imagine this is a collision resolution issue so you would need to manually move the gameobject after the move (look at location before and after the move and if it moved up in the y direction by equal to or greater than the stepheight set it directly back to the old y height. Code would break if you had an obnoxiously long tick during a jump but if your frame rate is that bad you wouldn’t expect the game to work anyways. May have issues with the player going through the floor if the floor is not flat around the corner of the step but considering this issue is probably only occurring in one tick as you’re gliding across the step I would think this is unlikely. If it does happen I can think of a more complex algorithm that would account for this. Though thinking about it, it is actually fairly likely that this issue ONLY occurs with a flat ground against a 90deg angled object perfectly perpendicular to the player. In other words, you may never even notice this bug in an actual project.
Nope. This kind of thing would involve writing your own collision detection and management algorithms. I have been down this road before and found myself reading scholarly white paper articles on it. This is possibly the single most complex thing to code in a game engine - up there with rendering.
Really annoys me that Unity neglects the character controller so much. I also have no idea why so many unity users think that rigidbody’s are the best way to handle character movement which is… objectively incorrect for 90% of games.
This works, somewhat, but using this I do get stuck from time to time.
Also, since this is based on the direction the player is moving, the player can only step up surfaces they are facing, which prevents them from going up stairs if they aren’t looking directly at them. The player should be able to walk up steps even when walking almost parallel to them.