Update 2
Hey guys. Obviously I’ve been pretty busy and since I’d like to spend the spare time coding time I have on Behave, I have just made the Path repository publicly available with an MIT license attached.
Note that I will be monitoring and taking in pull requests as well as compiling builds for releasing into the asset store (obviously as a free package). Let’s make this project as awesome as can be
Path does not have built-in navmesh generation or navmesh pathfinding. Would support for pathfinding on a hand-made or elsewhere generated navmesh be of much interest?
My ultimate pathfinding solution would enable me to give destination move/rotation commands to AI units and have them find their own way to said destination without getting stuck, sans the limitations of raycast-based pathfinding, and with as little setup as possible
Actually no. You’ve got something to look forward to in the updated Path integration with UnitySteer I’m shipping with Ricardo sometime at the end of this week / start of next week.
Awesome! As long as there’s some decent explanation on how to set it up I’ve looked into UnitySteer before, but gave up trying to integrate it due to documentation being virtually nonexistent.
I tried importing Path (the latest 2.02f from the Asset Store) into my project (Unity 3). The import itself seems to work, but when attaching the Navigator to any GameObject (blank or existing), the GUI doesn’t show up in the inspector. There’s no error messages or anything, but the only thing that appears in the inspector is the script reference itself, plus the ‘Seeker Iteration Cap’ setting.
When I create a new project with only Path (per the tutorial video), it does show up, so I can confirm that my download isn’t corrupted or anything. Something in my project is screwing it up, but it’s hard to tell what that is when there are no error messages. Could this be the namespace issue already mentioned?
Path should not be affected by the namespace issue - it should only affect other scripts in your project. You’re sure that the log is empty and that you do not have the inspector in debug mode?
I also assume you meant the “Navigation” component and not the “Navigator”, right?
My first reaction is that we need a way of selecting and moving waypoints directly with the mouse instead of always using the pop-up menu or the > and < buttons. One possibility would be to add temporary gameobjects as children under the Navigation game object. Then you could even multi-select and move them all at once with the built-in support in the Unity editor. These temp objects would kill themselves at game startup, or just live in an inactive layer. Otherwise, I’m liking it.
Yeah, I meant Navigation. Not sure why I said Navigator. And nothing indeed showed up in the Console or even the editor log. I wasn’t even aware that the Inspector had a debug mode, but I turned it on and the same thing showed up, only with one private variable, Waypoints, greyed out, added.
I then thought that I should try moving the /Path/Editor folder to /Editor, replacing what was in /Editor (nothing). I succeeded in getting a bunch of Detonator errors, similar to what Angstrom was seeing. This gives me hope in thinking that perhaps Unity just wasn’t seeing it in the folder before. Still no progress, though. Nothing shows up when adding a Navigation component to anything.
I might just wait until you release the new one, though, if it is indeed coming soon. I plan on integrating UnitySteer, so it sounds perfect!
I just took a look at the iTweenPath editor class. He’s creating a series of PositionHandles, one for each node. This would work, but it does sort of clutter the scene with lots of handles. Still, an easy solution.
It appears that Waypoint is an actual GameObject (you can duplicate one if you have it selected and get a free floating Waypoint. It also must have the HideInHierarchy attribute). So it should be a simple matter of putting a mesh on it to make it selectable.
Waypoints are indeed components and when you create them via the inspector I set the hide flags to reduce clutter. I could make this optional if you would prefer it, but that doesn’t really seem like a good fix.
I’ll see what I can come up with. Thanks a lot for your feedback.
I’ve been decompiling your code to understand it better (sorry for that). I have a couple questions:
SeekerData computes the HScore by summing the old score with the new Connections H value. Isn’t this a bug? HScore should be an estimate of the remaining cost to the goal, not the sum of those estimates from the start position. Summing from the beginning is what you want for GScore, not HScore.
Also, the cost function for connections uses Euclidian distance squared. Summing those squared distances for G is not really comparable with the H value distance squared. I know doing the square root is expensive, but if G isn’t computed accurately then the returned Path may not be minimal.
I don’t know what algorithm you are using, so I could just be completely confused. Sorry to decompile and complain.
