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!
The problem is that the character is not calculating collision unless it’s moving,
this is a temporary solution u can use I will edit it once I find a better one.(put this in the tick function of your character )
I’m fascinated by your solution…with a jpg/png showing 4 simple nodes you have just about solved a problem I’ve had for months. Thread here.
So let me sum this up… for awhile now I and a few others here have noticed a problem when it comes to the player being “pushed” by a wall or something. Unless the push occurs in the Z (up and down) the player is jerked and not pushed smoothly, for a video demonstration look in the thread I linked. This was ultimately proven to me to be the SHAPE of the capsule component and the way UE does collision.
I imagined there was a simple solution and perhaps you have almost found it. I notice your solution ignores the Z (since pushing in the Z doesnt seem to matter.)
In the first sentence, notice how I said “about solved” the issue…unfortunately I have found a small problem, that perhaps you or someone else can figure out.
I will make a quick video and show you what the problem is.
In this video…when the game starts you will see 3 moving platforms each moving basically the same speed. Mover 01 in the X moving toward the camera, Mover 2 in the Z going from down to up, and Mover 03 going from left to right.
The movers are simply actor BP’s with a cube sized / scaled appropriately to represent a wall. Then dragged into the world. Simple logic to move them.
HERE is the problem! I see smooth pushing from the left to right wall, (and surely the vertical platform) BUT, the wall coming from the background toward the camera there is a strange “torqued” sliding going on. I hope you can figure out what is causing that. Because your solution here is one of the simplest I have seen and look forward to using it!