Hey guys, I’m trying to edit the FPS controller script to do some simple tests, as the level you are on is rotating horizontally 360 degrees with the level going upside down. The player falls off the map.
OK, I watched it a few times and this is my thought.
The CharacterController is checking collisions each frame, yet when the outside is rotating as well. When it rotates, it rotates up, past the bottom of the CharacterController, so the collision is not longer registered as being on the bottom and gravity is then applied (from the script, not Physics.Gravity).
This looks similar to the elevator probably many people have, “Why does my player fall through the elevator!” The answer is usually that the player didn’t fall through the elevator so much as the elevator went up through the player, then the player fell down because they no longer had a collision from below.
Look up some of the posts about elevators and give them a try. Basically, the character should be parented to the floor in many elevator implementations. Perhaps a downward raycast to find what is below it and parent it to that in a fashion similar to the elevator implementations, but without the collision zone that marks the elevator area.
I thought about it some more and realized that parenting wouldn’t work well, because it would move the player in an unnatural way.
The solution might be that you have to ditch the built-in scripts and do something entirely from scratch. You could use the character collider still for the data it brings you, but probably should avoid using the scripted gravity-like movement it provides.
Well. Going back to the raycasting business, it might be OK to make sure that the player cannot go lower than the point at which a hit occurred directly below them. The scripted gravity probably doesn’t account for that very well. Also, with clever use of LateUpdate, you could force some order into the updates.