Using the Character Movement component, if you actively move a character up against a moving obstacle (such as a block that shifts left and right on a spline) it will smoothly push the player out upon overlap. However, if the moving obstacle collides with the player while he isn’t applying any movement, it will jerkily teleport him out, which feels terrible and looks very unprofessional.
Is there a way to fix this? I’d like the same smoothness regardless of what movement state the player happens to be in. I thought “continuous collision detection” would, but it did not seem to. I noticed that when standing on an obstacle, the player smoothly is pushed. That’s what I’d like, just with horizontal and rotation (object spins and collides with player) interactions.
I don’t have a magic answer. But assuming I understand what you want, the inconsistency you’re seeing is kinda typical of game engines I’m afraid (its similar to when a 1000kg vehicle collides with the player and simply stops moving but the player doesn’t nudge at all… But a player landing on a vehicle after a jump causes the vehicle to move / shift in a WTF moment?!). Now, there may be a simple fix for your use case, so go through all the CMC properties first just in case I’ve forgotten any as its easy to overlook them.
But if not, then you may need to telegraph the action by attaching a collision box or doing a trace to either the player or the moving obstacle. Then apply a force or impulse to push the player the way you want. I know it seems odd that this doesn’t work right out of the box as expected, and there could be a setting in the CMC for this. But I usually had to build something manual in UDK / Unity before, to get the exact behavior I needed… BTW: Did you find a solution to getting Set-Timer to execute in the same frame?
@EntrpriseCustomr I’ll go through those options again and see if I missed anything, but I don’t think I did. A volume that moves with the object and adds a *very *small force, like 1 unit, was something I considered, but I haven’t tested it much yet.
About the timer issue, no I never found a definitive fix. But I found a “good enough” solution that works for 10 and up fps. I subtract deltatime from the overall length of the timer when setting it. This makes it nearly the same “distance” every time. Not sure how this would perform with fluctuating framerate, but for now it seems fine.
The second video only happens when you aren’t applying input to the player. Sometimes it might even launch you off the ground a little bit. I assume it only uses “sweep” function when the player is moving, and resorts to some coarse “push-out” when you’re standing still. Most likely for performance reasons?
You could play with lowering Max Depenetration Velocity on the colliders; the setting dictates the rate at which intersecting geometry is ejected and is quite high by default. Not sure whether that will help with the movement component since it lives in its own dimension between physics and reality :|. But it might be worth experimenting with since it’s just a couple of clicks:
Seems it doesn’t really work with moving objects. Here it is with a low value: GvAYCLdSs1
Higher values than default also didn’t cause any change to how it was working from the start. Ideally i’d like to be able to have “sweep” working constantly. Which is what I thought CCD did. I wonder if there is no solution in the editor, that duplicating the Character Movement component itself and changing the C++ code is possible?
I see, I’m using the character movement component for player movement, and the shifting block itself is just an actor that moves on a spline track. Currently nothing is simulating actual physics using that checkbox in the properties of objects.
But since we’re sweeping, the moving mesh will actually stop if its obstacle cannot be moved out of the way - as in: you’re still applying movement. Since sweep is exposed, perhaps you can tell the obstacle to sweep only if no Input is applied. An interface could pipe in the data into the actor.
Ain’t that the truth. That pretty much sums up game dev …
Ultimately if nothing works, you can always try ‘cheating’. Namely, leverage the animation system or use mesh substitution (assuming you can reliably capture contact between the two actors using a hit-event / trace / collision-box / overlap etc). Going back to the 1000kg example… After the hit, play an anim to sell the effect (vehicle hits character and character falls back or falls down consistently). Its worth looking at approaches taken by fighter combat systems. Or try the substitution trick, which involves simultaneously hiding the character and teleporting a mesh that matches the physics of the hitting actor.
Neither of these are great if this will be multiplayer at some point, as it will break client-side prediction and may cause other glitches too… Overall, a lot of the reasons it takes so much work to get this kind of thing working, is that a character pretends to be a physics actor, but its really closer to an inert object. Whereas basic actors with simulation-on behave more reliably like real-world objects (bouncing ball off a wall). Its this Kinematic vs Physics ‘reality mismatch’ that causes all the problems… BTW: Try and link images / videos directly into posts as you’ll get more replies (faster UX for users + less invasive trackers).
This is an interesting approach I hadn’t thought of. I’ll look into this, and similar. Maybe if I’m just going to use cubes I could also do a bounding box push-out of sorts, that snaps the capsule to the respective edges on overlap, instead of further out than it needs to be.
Thank you for the explanation/tips. I think I should be able to get something working, even if it requires me to edit the C++ code of the movement component. I’ve been needing an excuse to look into those for a while now anyways, lol. I will also keep in mind to link videos directly in the future.
Ah, figured there would be 2 methods like this. Do you know if it’s at all possible to just make a custom component that defaults to “MoveAlongWall” at all times? I might be able to optimize a bit by only turning it on while within an actor’s bounding box etc.
It currently has a limitation I’m attempting to work around, which is that even if the player is standing on top of the object, the sweep detects it and causes the player to get thrown off if it has a movement component that supports objects beneath it, like the CharacterMovementComponent. Another potential downside is that since the “set location” sweep doesn’t seem to return an array of hit actors, it might not support multiple collisions at once. A simple shape multi-trace would fix that specific issue, but then you wouldn’t be able to use complex geometry for the platforms.
If anyone has ideas on how to fix the problem of being on top of the platform, please share!