Feedback: Mover 2.0 and Character Movement Component plea

Capsu1
Tue, 15 Apr 2025 14:13:20 +0000
Feedback & Requests

Hey all,

It’s been quite a while since I logged in here to post something (hope you all are doing well!), but seeing as how Mover 2.0 is actively in development (and the Character Movement Component could potentially see reworks while methods for implementing character movement in unreal are being evaluated) I figured now would be a good time to post some feedback about 2 specific problems that have plagued the CMC since I started using this engine years ago. I hope these will be addressed, or implemented into Mover 2.0 from the jump.

The first issue has been somewhat of a popular one, with users such as @usa423 and @Shrredder working hard to come up with clever hacky solutions to help others making threads about it, or running across my own thread from 2020 (5 years ago!) Nobody seems to have found a solid answer outside of “roll your own.” And while that might be valid advice for a serious developer, i’d argue in return that if you’re going to provide a starting point the vast majority of users will be using, it should at least handle these basic issues!

The problem: the CMC does not seem to accurately update collisions unless the player is either moving or airborne in some way

You can test this yourself quite easily. Make a third person template, drop in a box and slap a blueprint that moves on it. While actively moving, the player will be smoothly pushed by the box. However, if you come to a stop and let the box push you, you will be jerked out or completely ignored, depending on where the box collides with your capsule and the speed the box is moving at.

To make matters worse, while standing still, the upper hemisphere of the capsule is ignored entirely, with only the “cylinder” portion registering, and this cylinder portion defaults to some sort of coarse depenetration method. The upper hemisphere is a challenge for moving platforms even while the player is moving: position your box to pass roughly halfway inside the top hemisphere of your capsule and it will pass right on through

Why this sucks: Moving platforms/objects are very common in games, so this should at the very least be controllable via a toggle option, or continuous accurate collision should be the default on the player character, which is the most important actor in a game. The CMC can already handle smooth collisions with moving objects (barring the hemisphere detection problem) so there is no good reason it shouldn’t do the same while the player is static. There are countless threads about this specific issue stretching back years, even as early as the 2010s.

The second problem: Deflection velocity imparted upon colliding with geometry is not controllable

I think many of us have been here: you’re running around your world, maybe trying to fine tune your 3D platformer movement, or cruising through your blockout in an FPS, when you go to make a jump only to scrape the side of a wall and get unceremoniously flung way off course. Worse; you might barely touch the bottom edge of your capsule on the tip of a ledge and get bounced right away like a ping pong ball instead of landing on it. This quirk can provide hilarious results if you’re falling from high speeds only to land on an unwalkable slope. You’ll rocket really far across your level, to the point where it almost feels like a bug.

The deflection velocity particularly hates the Jump Max Hold Time variable. If you hold a jump underneath a sloped surface, you’ll go for a ride:

Why this sucks: it makes platforming feel unreliable and frustrating. In certain cases (such as the Jump Max Hold Time and fast fall into unwalkable slope) it can be game breaking and look terrible. Ideally, we would be able to control the amount of velocity imparted by a collision. Note that I do not mean overriding the SlideAlongSurface behavior, only the deflection velocity added after a slide!
A multiplier from 0 to 1 in settings would be perfect. If set to 0, the player should smoothly slide along or around surfaces as normal, and not have their movement path adjusted outside of what’s necessary to “clear” the collision (NO imparted deflection velocity). Here’s a thread about this one that is trying to fix the issue on the Z axis, and it illustrates the desired behavior at Multiplier = 0 nicely. A helpful forum member seemed to narrow it down to some C++ code, and while they helped somewhat, it still wasn’t a perfect solution in the end.

Well, that was a lot of text outta me. I hope this thread finds the right developers and they notice how prevalent the complaints are. Fixing these issues would go a long way towards making it easier for the less code-inclined of us to get the feel of your average polished game. At least these 2 specifically feel as if they never should have launched to begin with, as games on the PSX and N64 didn’t have them in a lot of cases. There is always some need to fight the engine if you want to make something outside the box, but I don’t think you should need to fight it too much for such simple problems.
All the work the Mover guys have done makes me hopeful, because they seem to get a lot of the common complaints people raise on tired old CMC.

I’m sure there are other things people would like fixed that have haunted more seasoned indie devs than myself. Wouldn’t be surprised if I missed something due to not running into them with the types of games I make. If you’d like, feel free to turn this thread into a sort of “stock movement wishlist.”

Cheers!

4 posts - 3 participants