Why does clicking outside of NavMesh bounds in a click-to-move project make the player pawn attempt to move towards world origin?
I've created a maze using the top down template as the basis. I'm having problems getting player pawn movement to work correctly when clicking outside of the NavMesh bounds.
What works well The pawn moves towards the hit location when I click within the NavMesh.
What doesn't work: When I click outside of the NavMesh, the player pawn attempts to move towards the world origin (0,0,0).
What should happen: The pawn should not move towards the world origin. What I want is for the pawn to move as close as possible to the mouse hit location while staying inside of the NavMesh bounds.
My first idea was to make a large plane mesh, create a new trace channel, and force all of the Get Hit Result By Cursor Under Channel nodes to use this new mesh and trace channel for pawn movement. To ensure that the pawn stayed within the bounds of the maze corridors, I wrapped all of my maze meshes with 1 meter tall collision meshes.
This solution solves the original problem of getting (0,0,0) when clicking outside of the NavMesh. However, this solution breaks when I start adding ramps that go below the Z-value of this large 2d plane mesh (see screenshot for examples of these ramps).
Now you might say that I should just lower the Z-value of the large 2d plane. This solves the issue of the ignored ramps, but it introduces a new issue. Since the camera is set at an angle, clicking outside of the maze meshes now sends the player pawn in a slightly different direction than the mouse hit, due to the Z-value difference between the newly-lowered 2d plane and the corridor pieces. This is incredibly disorienting for the player.
I'm not sure what the solution would involve.
Any help appreciated.
So, i had similar problems, since i am doing a Click&Move Game, and whenever i clicked outside of the navmesh, nothing happened. Though i wanted in that case, that the player just moves in the direction of the click. I solved this by doing some of the navigation queries "manually", here is a solution if you already used c++ in your game:
First, instead of getting the HitResultUnderMouse you could create a virtual plane on every click, so you can project the coordinates always at the same height as the player is. Evengard did the Maths for it already, so it should be quite easy to incorporate into your code (https://answers.unrealengine.com/questions/20858/set-collision-settings-for-brushes.html) :)
Afterwards we need to do something to the PlayerController. First, in the .h of your playercontroller, add 2 components:
Then we need to initialize them on instantiation of the controller, so in your constructor-method you need to call them.
Ok, so far so good. Now comes the fun part. I've bound the following method for LeftMouseClick:
(GetMouseClickCoords is my method where i pasted the code from Evengard) What are we doing in this method now: First we try to find a path to the destination location through the navmesh (FindPathToLocation). If we couldnt find a path, or the path is not valid for whatever reason, we try to find a "path" without the navmesh, which means, the player just moves in the direction of the click. Then we request the actual move.
Hope this was understandable and helps any others in the future :)
answered Jun 01 '14 at 12:11 PM
Idk how I got here (must have clicked related questions or somthing) but this seemed like a interesting problem that I could input some ideas.
I was thinking you could make a brush below everything that isn't visible(Doesn't need navmesh) that will catch any clicks and if the getmouseworld node's z equals that brushes z value then it will get the current z value of the actor and use it with the xy from the getmouseworld to create a vector to pass to the simple move to node.
I dont know if the simple move to node would translate that to moving to the edge but you could create a bool variable in the regular move to location and set use pathfinding to false if the z value was from the brush below. You could then add some brushes for the pawn to collide with at the edges.
I'm not sure how it could work when looking through the camera at an angle though so you may have to change it around possibly but it could work.
answered May 05 '14 at 09:30 PM
You could try adding branches checking by the bool return values from the function. These modules encapsulates the method LineTraceSingle( ) that just returns true if hits something.
This could solve the problem or at least minimize the "undesired" behaviour.
I guess the pro way to do this should be create a Blueprint function that breaks the HitResult and gets the PhisicalMaterial you hit, comparing it to some Material that you should just apply on the "walkable" surfaces, if they're equal returns true to you use on a branch like shown on my suggestion.
I apologize by lack the skills to make a Blueprint graph from the function you really need. :(
answered May 06 '14 at 07:52 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here