As I understand it the “Get Forward Velocity” node won’t work like it would for most other game modes. The actor that we’re controlling is continuously experiencing torque, where the forward vector of the mesh is always spinning. Is there a way to get the real movement direction efficiently? I would use this for a couple of things, mostly I need to do line traces in front of the ball to test for viable places to jump, I’d also like to make the camera lerp forward (my game is 2.5d) when the ball gets going faster (so the player can see more in front of the ball), basically the inverse of the “drag” found on the Spring Arm component.
My current and only theory was to get the actor’s location and store it as “previous location” and then use a trace to the “current location”, allowing me to determine the true direction of the ball’s movement. Then I would be able to add a point in front of the ball regardless of what direction its going. Does that sound reasonable? Or is there a much easier way?
The answer for anyone else looking is to get the physics linear velocity of the ball. Since we can’t get its actual facing direction or what not we must get its movement direction with the physics node. I was then able to normalize it, multiply it by a distance, add it to its own world location and use that to project a point in space at all times in front of my ball.
The mesh is always spinning, so if we got its forward facing vector we’d get 360 different angles of whatever axis its turning on. When we get physics linear velocity we actually get the direction the ball is going (ie its actual forward). Think of a tire on a car, just because we say X is its forward direction, as soon as the car starts moving it’ll be looking down, behind, up, and “forward” again constantly.
Yeah you’re right, I thought it would get the directional vector of the physics object but it totally doesn’t work like I thought it did. Though while testing this I got some pretty cool looking geometric shapes with line trace
