Problems Regarding FPS attached meshes clipping and character Movement

Hello, yesterday I had this issue: Screen capture - ca9252c9edd34e04fbcf2b2ffd0b0cf5 - Gyazo

my cart is attached to the fps camera and would constantly clip through static meshes. Now I hacked it by just making the capsule component coating the cart but that doesnt seem like a statisfying fix. So I was wondering, is there a way like unity to render it on a different layer or just a way so the carts collision gets respected by character movement so it would not ignore other collision on the same bp ? I have seen solutions like moving "weapons up"using a overlap event or shader tricks but if I want to also have a 3rd person view, those solutions are out of the question.

So lets say i have a shopper or even a character that has a huge cross attached to his back. How could the game respect his huge cross static mesh on his back when he for instance wants to go through doorways? It would just clip I assume. I cant think of an good solution to this and would love some help regarding this.

suppose I want to be able to crash my cart into the other character capsule or cart mesh and deal damage, the cart capsule has collision to block all in the bps, yet when i playtest it, I will constantly clip through his cart.

noone? would really appreciate some help

You have to use overlap events to disable capsule movement, or IK to deflect.

e.g. add a collision sphere to the front of the cart. On begin overlap (event) -> disable “forward” movement on character -> determine if overlapped actor/object can be damaged -> apply damage/state change.

The character class capsule component is the “ONLY” collision in the class that will actually stop movement (block). Thus the need to use overlap events.

thank you, any idea how i could stop movements in blueprints dynamically? so if i hit a wall while moving left, block movement only in that direction and front only block front movement etc.

Thank you!

Add a box collision (thin) on the left and right of the cart. Add a another in front of the cart.
Create “On Begin Overlap” and “On End Overlap” events for each of these new collisions. Set up there collision settings as needed.
Create Boolean vars for Move Left disabled, Move Right disabled, Move Forward disabled. Default (0).

Foreach of the On Begin Overlap you need to set its movement direction boolean to true (1).

e.g. moving forward -> on begin overlap (front collision box) -> set “move forward disabled (true)”. etc etc.

Foreach of the On End Overlap you need to set its movement direction boolean to false (0).

For the move input action (forward/backward) and the left/right, turn etc you need to set up branch conditionals.

(forward input) -> scale float > 0 > 0 = forward, < 0 = backward]
For forward inputs (scale = 1) branch check if “move forward disabled” is true. If false, then pipe to movement input and pass the scale val.

This should get you started. All you have to do is toggle those booleans true/false and use them on input actions. pretty straight forward.

If you need a visual aid (bp pic) let me know and I’ll try and squeeze a few minutes to punch it out.

hey, so I am quite a noob in bps so a visual picture would be greatly appreciated. Thank you btw, if this works it makes my day. Have been stuck for a while.


any idea how this is done? I wouldnt mind if it wasnt too dynamic but this looks good as well. Same logic as you suggested?

I’ll put something together in the coming day or by Saturday.

The video uses the same principle but combines it with Inverse Kinematics.

awesome looking forward to it. Is it possible you go over his approach as well, only if its not too much work. Thank you again, feel relieved, havent found anything satisfying for days.


  1. Create a Box Collision and place it in front of your cart. Try and keep it thin if possible.

  1. Configure it’s Collision.

  1. Create “On Component Begin Overlap” and “On Component End Overlap” events for the collision … (click the + button).

  1. Create the needed Boolean variables to drive the logic. For your usage (Forward, Left, Right). Default them to FALSE.

  1. Set up the overlap events.

  1. Set up the movement input logic flow.

If you don’t need the “Backward” functionality simply remove the lower branch node and pipe it’s feeding node to the reroute.

Right and Left will be the same set up. Collision -> overlap events -> logic flow.

  1. World actor collisions …

Any actor that you want your box collisions to interact with must have their collisions setting “generate overlap events” ticked (true). Otherwise the begin/end overlaps will not execute.
Ultimately I’d recommend creating a new Object Channel or Preset (Project Settings -> Engine -> Collision) and use this for your box collisions settings. This will make it easier to tailor interactions between your box collisions and world actors.

Also I need to note that movement velocity does have an impact on the timing of the overlap event setting the boolean vars. At high velocities the box collision will penetrate further into the opposing actor. Tickrate also impacts this.

You can counter this a bit by moving the collisions outward/inward a bit based on the characters velocity.

e.g. say your moving forward … once forward velocity exceeds n, move the forward collision forward by 5cm or so. When it drops back down move it back.

This will be trial and error and take some time to get the distance offsets correct.

oh no, seems like all the image files are broken?

yes, I was immediately thinking about the same approach. I have also heard attaching a spring arm to the fps arms and mesh, though havent played with spring arms.

Hello Rev0verDrive,

I played around with the spring arm and managed to do this: Screen capture - e41c8135de8b12bda6f154655724e1b8 - Gyazo

Now, I think this is a good start, but how could I make it similar to the video where it softly transitions and based on an angle? Sorry I am new.

here is the bp and set up

I still think especially if you want 3rd person and due to the nature of the object, a full restriction of movement would be better. If you could try to get your pics back up that would be awesome.

Thank you so far.

Bump the wall, pause and eject … look at what the spring arm does.

Fixed the images.

EDIT: Screen capture - 89abb876c8ef2f9b18b0b86aa104d09e - Gyazo

hey also back, this time i used a timeline and it sort of made things better. However I do have the issue that the cart can get pulled back too early when the trigger overlaps, so its not like a distance based thing. I tried updating it by subtracting 2 vectors but I couldnt figure out how to use event tick in all of that.

Thank you for updating the images, i will look at your solution now.

BTW: do you know what is causing this: Screen capture - f8132a0ca3edae24009a5c61023e4c00 - Gyazo

My physics objects are just so bouncy and feel like nothing weight wise, even when increasing mass scale or kg. All it does makes the cart slower / laggy, the bounciness is persistent. Ontop of that when I pull back my cart (when close to a wall), the objects all clip through: Screen capture - f8132a0ca3edae24009a5c61023e4c00 - Gyazo

heres my custom collision mesh: Screenshot - 9402a06e989211de2be134b1a414b700 - Gyazo

Physical materials …

Specifically Restitution (bounciness).

For the cart impacts you need to calculate a deflection angle using impact normal. Adjust the amount of deflection force based on impact velocity. This will give you the appropriate physics response to the collision.

Use the physical materials to handle the bounciness of the objects inside the cart.

thanks, tried applying a physics material with appropiate values, didnt really help unfortunately.