Thanks a lot for explanation. I will investigate on Recast.
So it can generate nav mesh out of level mesh created by a 3D editor, nice.
So R&D can be used completely decoupled from JME ?
You mean use it with Java JNI over c++ ?
I also found this port of R&D for java. I may take a loot at it.
You can even make Agents walk iirc, but I don’t know if you are able to export nav mesh like that. I actually used this back then to figure out some optimal parameters and such.
(Source: Recast Navigation: Recast Navigation)
Nope, Raw means some C++ project maybe actually because a JNI Wrapper in the first place is some work to do. If you first evaluate R&D a bit beforehand, it might be easier to port.
Also note that there already is GitHub - QuietOne/jNavigation: Navigation for jMonkey Engine. which also is a partial port (unfortunately without some decent Makefiles (Continous Integration) and a bit older, but it seems to be designed for JME).
And there is also: GitHub - ppiastucki/recast4j: Java Port of Recast & Detour navigation mesh toolset, which is a full recast port for java. Not saying it is better than a JNI wrapper (both comes with their advantages and disadvantages), but another alternative.
With a bit of delay, here is the change made in the code
It was Ali_RS who found the problem. I just modified the two lines of code.
In library jme3-artificial-intelligence, file NavMeshPathfinder.java
On line 117:
currentCell = navMesh.findClosestCell(currentPos3d); // modified newPos2d
On line 125:
goalCell = navMesh.findClosestCell(goalPos3d); // modified goalPos2d
With this small modification, the path search works correctly with two paths that overlap.
Good day to all
Also we fixed it on latest release of jme3-artificial-intelligence on Darkchaos github repo.
Super, I had also created a clone project with the changes,
Another small question, would it not be more interesting to ask that the changes be made in the original draft?
Have a good day
Yes. Let’s see what @Darkchaos thinks about it?
They could be made but
a) it might not be merged considering the current activity level
b) We’re currently not able to push out netbeans plugins using the update central either
c) I’ve modified the Plugins so you can more easily build them using gradle and without the need for a full sdk compilation
which is d) For some Plugins, you still need the SDK which in it’s current state makes it unbuildable by travis since we’re running out of disk quota even when just building the sdk itself, I would need to investigate that a bit.
e) I could just rush and set everything up under bintray but I am not sure about their conditions and don’t want to get sued or whatnot
In General this whole SDK Updates thing is down for a long time now, I might think about a solution and hope to set everything up sooner or later.
So what I wanted to say: Currently the only way to install the plugin is using my repo anyway. And the other thing, well, I’ll find something.