Pawn drifts vertically when moving relative to rotating Parent

Before I start, I apologize if this is in the wrong area of the forums. I’ve made it by so far using the results of other people’s questions without having to post myself, so I’m not super familiar with how posting works. Also sorry for the wall of text. I’ve seen a lot of people ask specific questions with little to no detail, so I want to be thorough and as accommodating as possible.

I have an issue with movement in the Pawn I’ve created. My intended result is that as a platform moves and rotates the pawn will stay in place relative to the platform and that the pawn will be able to move on relative to that platform while it is moving. I’ve created a class of Volumes which interact with the Pawn to reorient the Pawn according to the downwards vector of whichever Volume the pawn is currently inside. The Pawn is also attached as a child of whichever of these Volumes it is currently inside. As of right now, everything works fine. I can stand on the platform, and the Pawn will move and rotate with it, making it appear as if the Pawn and platform are still, but the world is spinning or moving.

However, moving the Pawn while the platform is rotating causes issues. Moving the Pawn in the same direction as the platform is rotating causes the Pawn to drift upwards or downwards. For example, from the perspective of the pawn, if the platform is rotating clockwise (the right of the platform is moving down, and the left side of the platform is moving up), and the pawn moves left, the pawn will drift upwards off of the platform. If the pawn moves left, they will move downwards. Without collision, the pawn would clip through the ground slowly while moving left. This issue only occurs while the platform rotates, not when the platform is translated in any direction. If the platform stops rotating after the pawn has drifted, the pawn will stop drifting and will begin to move parallel to the platform again.

The pawn uses FloatingPawnMovement to work. Initially, I was using AddMovementInput, but I changed to AddInputVector. Either way, the drifting issue was quite bad, drifting upwards about 1/2 a unit for every 1 unit of lateral movement. I tried to remedy the issue by constraining the FloatingPawnMovement to a plane which is updated every tick (not ideal) based on the parent actor (platform/volume) UpVector. This helped tremendously, but the Pawn will still move upwards or downwards with any rotation of the parent while the Pawn is moving.

I’ve included a mock-up image of what’s happening. Top left and top right of the square sections show “Before movement” and “intended result after movement”. The bottom left shows results after moving the Pawn with only AddInputVector while parented to the platform as it spins, as you can see the pawn drifts up a large amount. Bottom right shows result using plane constraints along with parallel movement vectors which update each frame based on the Parent Actor’s current UpVector, as you can see the issue does not go away, but it is decreased.

What I think is happening, is that the information that the Pawn receives when it is looking for its Parent Actor’s UpVector each tick is outdated, resulting in the Pawn being constrained or moving along a vector which used to be parallel to the platform, but the platform has since moved, resulting in what looks like the Pawn moving into or away from the platform.

I’ve also tried using physics, but physics movement on a moving object has ended up being pretty janky each time I try to tackle this issue from that angle.

Let me know if more information is necessary, and thank you for any help or suggestions!

Instead of all that special stuff you’re doing to make the pawn attach to the platform and move with it,
have you tried using CharacterMovement or a CharacterPawn? Character pawns and their movement component have TONS of code to handle lots of common situations. I don’t know if it covers everything you need your pawn to do but it’s the only pawn class that comes with the Ue4 engine which smoothly replicates over the network (the only one that has the necessary prediction and smoothing code), and it handles a lot of subtle things you might not have thought about like stepping down small steps rather than falling onto them, but still being able to fall off larger drop-offs.

Without wiping out your current code, why not try a FirstPersonCharacter or ThirdPersonCharacter pawn template with your rotating platform and see if it behaves better with and without attaching the pawn to it?
You get lots of character movement configuration options in the details pane too, for handling things like maximum walkable slope, ground friction, acceleration and deceleration, etc. All without using simulated physics.

Having said all that, I imagine you have a good reason for using the FloatingMovement component instead.
Why is that?

Thanks for the detailed response! I’ll definitely have to take a look at the CharacterMovement and Character class again.

As you said, I do have a reason for not using it, though I’m not against the idea of using the character if I can get it to work with the idea I have in mind. There are two reasons I stopped using a Character and started using a Pawn with FloatingMovement. The first that the project I’ve been working on has Players moving on separate planes with varying directions of “gravity”. Picture two people walking on different spaceships, or on different sides of a cube with the face of each cube having gravity in the inverse direction of its surface normal. The second reason is that these planes may or may not move in some cases, and using physics-based movement tends to get janky pretty fast relative to moving objects. When I was using physics-based movement in my Pawn before I tried the plane constraint and floating pawn movement the Player would have a hard time walking around on moving surfaces such as clipping through the floor or bouncing, jittering, and sliding. Using a FloatingMovement Pawn removed all these issues, but at the cost of being very limited in other areas as you mentioned.

The Character class seems to be locked down pretty strictly in terms of how it handles all these features you’ve mentioned, such as stepping down instead of falling and walkable slope angle. It always seems to treat the -Z axis as it’s downwards vector from which it calculates everything you mentioned. For example, if the character is walking on a wall, the walkable slope doesn’t compensate for this and make slopes walkable from that wall plane.

All this in mind, I haven’t returned to the Character class to give it a shot since refining my movement functions, so I’ll go and see if any of the approaches I’ve tried since using a Pawn will work on the Character this afternoon.

Okay yeah I agree Charactermovement is not very flexible about its gravity direction and vertical axis

So I tinkered with the Character instead of using a pawn, brought over all of the functionality of the pawn I was using and made some other tweaks. As of right now, I don’t think I’ll be able to use the Character due to the issue we discussed where the Character really wants to treat -Z as down.

I did, however, come up with a solution for the FloatingPawnMovement using the Planar constraint. You can set the PlanarConstraintOrigin and have the Pawn snap to that origin. I use traces and custom volumes to set that origin for each moving platform, then when the Pawn updates, even if itis drifting, it snaps to the origin as well being constrained to the proper axis for lateral movement. I’ll be adding a more detailed explanation to mark as the answer later today.

So the solution I came up with using the FloatingPawnMovement and “Gravity” volumes was to add a second Box Collision to my GravityVolume class which only has X and Y dimensions and has a scale of 0 on the Z axis. This second box collision acts as a visual reference for a vector which represents where the floor is on the moving platform relative to the GravityVolume. Along with resetting the constraint to which the pawn movement is locked, I also set the origin of that constraint to this new floor vector component when the platform moves, which stops the pawn from drifting. To handle jumping and other non-lateral movements, I simply add an offset from that ground point. It seems a little limited, but it’s more consistent than any of the trace or physics solutions I could come up with.

In the future, I might trace from the GravityVolume down until the floor is met and generate a custom heightmap to lock the character instead of using a single flat vector. As it is right now, this solution only works on completely flat surfaces, which is okay for my project but might not be the solution others with similar issues are hoping for.

Thats good to hear. A lot of people are looking for the solution to this problem so I might point them to this thread if I see it come up again.
Now as long as you dont need smooth network replication then it sounds like youre done