In addition to the other problems that I have pointed out (i.e. where an AI can get lifted up, due to uneven walls not being properly detected when the navmesh is calculated to keep the mesh away from them), I have found some of my AIs ended up inside a void in the scene. Basically there’s a cone with a winding path around it. I had a target point near the path at the bottom. The AI had quite a long run up and a max speed of 10. On getting to the target (I probably then gave it a new target) it then started to change direction and passed through the wall of the cone. Inside the cone, A* had created another navmesh and the AI was now trying to use this one. Obviously this is not helpful.
Looking at the A* RichAI code (again), there appears to be a single short vertical ray. This will easily miss the near vertical part of a collider (i.e. the side of the cone).
There seems to be nothing to ensure that the AI is kept within the ray line length of the A* navmesh (so it is not constrained). This is causing me lots of problems with AIs ending up in silly places. Your only reply implies that I have no colliders but I do have colliders, I have added more colliders just to be certain that this is not the problem. I have spent a long time trying to show you some of the issues (see my other posts) but have had not a further response and A* is no longer feeling like it will be a solution that I can continue to trust with my project which will be a shame. I need a solution that is fast, works with any scene that my character should be able to traverse and is reliable.
Can you please let me know if there is a fix on my part here, if you will resolve to fix the problems I am encountering or, failing that, I would like a refund please?
I look forward to your prompt response, thank you.
Sorry for the late response. I have had a lot to do this last week and I haven’t had much time to respond to posts in the forum. I have answered your other posts now as well.
I can’t really picture the exact problem that you have here (a screenshot would be helpful), but I think this will also be solved by switching to a character controller.
I am confident that we can solve the problems that you are having with the RichAI script.
If we cannot, I can arrange a refund.
As I’m using a commercial scene you’d need to own that (and the other commercial assets too) for me to send you my stuff. Also the up/download would be massive (copying the files between machines is about 1.5GBytes so I assume that order of magnitude). Given the trouble it seems to have revealed, it is probably worth you acquiring just the scene asset anyway as it’s a very good test playground for RichAI. I have added 23 additional colliders to the demo scene either from when I was testing your original suggestion (that I had some missing) or because, with your navmesh generating system, I ended up with multiple navmeshes where I only want one. In case you do get the “Underworld: Cave Environment” (I’m using their “Demo1” scene to test with), I use a height of 2 and a radius of 0.6 for the navmesh. This worked with fewer additional colliders for the Unity Navmesh.
You can see the problem (with screen shot) mentioned in this forum entry, on my blog: hackslashtastic.com/?p=71
I have also tried simply adding a character controller as you mentioned in your other answers but this seems to make things much worse, (is there something else I should have done with it other than just add it using the defaults?). Also, won’t a character controller be much slower? It could still be an option (when it works) providing everything at least runs much faster than the Unity Navmesh/Agent solution which simply can’t keep up with the path requests I make.
It should be easy for you to reproduce the problems once you have the scene asset. I am essentially just using your basic RichAI setup with a very simple script to pick a random new target objects position (sat on your mesh) once the capsule is within a small range of its target. I also spawn another RichAI capsule once per second with the idea of seeing how far I can push A* RichAI etc. but, at the moment, I don’t normally get far before there are the issues I mention so I never get to see what the performance might be like for my game scenarios using RichAI.
If we can get things going with RichAI etc. then that would be great and I hope that we can do so. I have very limited time to work on my project (as I’m a full time programmer on other stuff up to 12 hours/day at the moment). Providing it looks like we’re making progress I can hang on but I am not really in a great position to spend lots of time debugging paid for things, of course. Please keep me informed of how your solutions are coming along to the problems that I have mentioned along with an anticipated fix date. This way I can look at other stuff I need to do but a fast (reliable) path finding solution is holding me up on my ideal sequence…
Do you think that you can solve these issues in the near future, (if so, any idea roughly when please)?
Thinking about what would do the trick to fix these issues, I imagine it will be straightforward for you:
To stop the problem where a RichAI item ends up in the wrong place (described at the top of this forum entry), make sure things can’t go off your navmesh in the X-Z plane. Presumably you can tell when you’re currently on the edge of it (although I suspect you may just get the nearest navmesh point (from any navmesh) and may be use that next frame). Perhaps have a flag so people can restrict an AI to the current navmesh. It would also be useful to delete un-required navmeshs, like the yellow one in the image on my blog.
To stop the problem where an AI gets lifted up / drops through stuff, make sure that the ray you use and the constraint applied is always within the max distance of your navmesh that you allow it to be when generating it. Or something along those lines.
The RichAI should already make sure that it does not leave the navmesh in XZ space.
I emailed the author of the “Underworld: Cave Environment” package and he said that he was ok with you sharing your project with me for debugging purposes.
1.5 Gb is not too big of a deal, it will take some time to upload, but I think it would be best if I could look at the project that you are using.