Download

Question about collision response

I am using a modified version of the flying pawn BP. So I have limited the movement to a set speed and only horizontal (no up or down, roll or pitch). I need to be able to limit the area of travel with blocking volumes. As it is right now when I collide with a blocking volume the camera goes into a stomach turning spin. Any ideas on how I can cause the flying pawn to just stop in place? So that as you are moving around when you encounter a blocking volume you just stop. I have tried altering the deflect when colliding section to no avail. Any help would be appreciated. Thanks.

TheJamsh offers a very simple 6DOF template.
That might be better geared to what you’re after.
(Basically it uses a simple pawn with no Physics).

franktech, Thanks for the response. Do you happen to have a link to the exact template you are referring to? I have looked at a few (including this one A new, community-hosted Unreal Engine Wiki - Announcements and Releases - Unreal Engine Forums) and they do not seem to address the issue I am having. Or maybe it is my lack of understanding. :slight_smile:

@charlie.brown

The project & explanation is here. You can just disconnect Roll + Pitch…

franktech, I have trimmed my blueprint down to the bare minimum.

This is the response when I collide with the blocking volume.

My desire is to have the camera do nothing but stop when colliding with a blocking volume. Any advice is greatly appreciated.

@charlie.brown

Is there any rogue Event-Hit / On-Component-Hit code somewhere, that you’ve forgotten about, like in this example?
Do you need Physics, is it Active / On? Ensure Simulate-Physics is UnTicked on all Components in LHS pane of BP.

Simulate physics has been unchecked for some time now. I can find no On-component-hit code. And I do not have the nodes that RoccoFX used in his system, though my base is they Flying pawn. The image of my blueprints attached earlier is all that remains.

@charlie.brown

If you had Physics on, I was about to say you could up Angular damping anyway.
If none of the components has Physics, the only other thing I can think it might be:
Check Camera-Spring-Arm settings aren’t loose, sending the camera into a spin.

Show a screenshot of your BP Components, esp. Camera / Spring-Arm settings…

It almost looks ‘too ordered’ to be Physics, more like a Gamepad-Controller-Glitch?
Maybe now, go back and check each setting against an original unaltered Template…
Short of that someone else will have to help… I can’t think what else it could be here…

I just cannot figure it out. Here is the screen grab you requested. I appreciate your taking the time to try and help me, one of the things that makes this community so great.

@charlie.brown

Not seeing anything in the code / camera that would explain this, sorry dude.
Maybe, if I had a stripped-down / zipped-up Project, I ‘might’ spot something.
But honestly I’m not confident right now the camera and inputs both look fine.

There’s no other code??? Only ‘Move-Right’ Input makes Rotational changes.
But it won’t happen, unless the Input that its tied to has a non-Zero Axis input.

Plus, you’d see probs before hitting the ‘Blocking Volume’ if that was the case.
Must be something else in the ‘Flying Pawn BP’ that’s not being accounted for…

I really have searched everywhere. I have the pawn movement limited to the four compass points, so no extra code. No altitude variation, no bank or roll. WSAD moves on the points, mouse is the “head”. I could probably do with just the W key and mouse. Thanks so much for your efforts.

@charlie.brown

Did you ever test-drive TheJamsh’s Axis-Rotation template above?
It basically does exactly what you want, using Wall Meshes instead…
In your shoes, I’d definitely integrate that project into your own work…

Otherwise, all I can say is… UE4 is frequently humbling. Errors staring you in the face completely missed, until you step through the code slowly, node-by-node debugging each section manually. Overall, when the obvious isn’t obvious, start shutting down every circuit, until you find out what you couldn’t predict before was causing the problem all along… I would disconnect every node, and just leave the TICK forward movement part active. Then see if you get the same outcome, when the Pawn hits the Blocking Volume (making sure the volume itself has no Event Hit / Overlap code etc)…