qsa

I think we need to distinguish between two different things: 1) Having indication if current target is accessible from Unit class. 2) Checking reachability to any point on demand. First: can be easily done, by adding wrapper to IsReachable(), if we have target, the path calculated/updated every cycle anyway; just need to make sure we check after it is done. Second: Code other than movement do not need the actual path, all it needs is reachability indication, calculating it is much, much cheaper. We can add function just for that; but need to make sure it is really needed. @cyberium : this should also answer your question. About incremental updates, etc: already done by PathFinder

Actually it will work since MoveChase will call Mutate() on MotionMaster, which in tern will Initialize() new generator; If this generator calculates pathfinding inside Initialize; its safe to use, otherwise, you will get default value; true. Actually, when I think about it, only TargetedMovementGenerator (and all its derivatives) return the actual value. Of course you have to also add wrapper inside GetMotionMaster for IsReacheable(). Just to clear things out about threading: all pathfinding calculation reside in same thread as the map instance they run over.

https://gist.github.com/1678748 should fix this issue

Unfortunately, it is not trivial. You have to know exact map id, tile id and coordinates of start and end of connection. Just look at the example in offmesh_example.txt That particular tile have to be re-extracted afterwards. As Patman128 said, best way is to look at the mesh itself in debug tool, again, not trivial but its the best way we have.

Thanks for testing. Added the patch to repository with some related changes. You are missing offmesh connections there, search up what it is all about PS: that reminds me: none yet posted any offmesh connections. Don't be shy. Best regards.

Can you please test below code and report? diff --git a/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp b/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp index f2c07e0..6a6eb94 100644 --- a/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp +++ b/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp @@ -169,6 +169,10 @@ dtStatus dtNavMeshQuery::closestPointOnPoly(dtPolyRef ref, const float* pos, flo if (m_nav->getTileAndPolyByRef(ref, &tile, &poly) != DT_SUCCESS) return DT_FAILURE; if (!tile) return DT_FAILURE; + + if (poly->getType() == DT_POLYTYPE_OFFMESH_CONNECTION) + return DT_FAILURE; + if (closestPointOnPolyInTile(tile, poly, pos, closest) != DT_SUCCESS) return DT_FAILURE; return DT_SUCCESS; For some reason it looks like closestPointOnPoly() really don't like offmesh connection polygons, while findNearestPoly() has no problem returning those ... Just hope its really offmesh connection related ...

Looks about the same. Is it from code with latest change? PS: added something little better to address this problem to repository. (but the patch posted here should do exactly the same, just bit less efficiently)

Unfortunately it is a pretty ugly hack. I'll add better solution later on. Thanks for testing.

Not really familiar with OregonCore and from the looks of it it uses pretty outdated mmap code. Hope it isn't backporting to one or porting to different core issue. But maybe its issue is there even in new version. Can anyone confirm? Please try the below patch. Do not forget to report back if it worked or not. Otherwise, I just wasted some 20 minutes of my life. diff --git a/src/game/PathFinder.cpp b/src/game/PathFinder.cpp index df428bd..5eb8d14 100644 --- a/src/game/PathFinder.cpp +++ b/src/game/PathFinder.cpp @@ -108,6 +108,14 @@ dtPolyRef PathFinder::getPathPolyByPosition(const dtPolyRef *polyPath, uint32 po { MANGOS_ASSERT(polyPath[i] != INVALID_POLYREF); + const dtMeshTile* tile = 0; + const dtPoly* poly = 0; + if (m_navMesh->getTileAndPolyByRef(polyPath[i], &tile, &poly) != DT_SUCCESS) + continue; + + if (poly->getType() == DT_POLYTYPE_OFFMESH_CONNECTION) + continue; + float closestPoint[VERTEX_SIZE]; if (DT_SUCCESS != m_navMeshQuery->closestPointOnPoly(polyPath[i], point, closestPoint)) continue; Best regards.

I was kinda hoping someone else would pitch this part up. I tried it once and it turned to really ugly hack very quickly. Maybe someone else has better idea. Same as above, missing evade timeout. This is current for pets (on mmaps too), but I'm pretty sure not for creatures (last checking a year ago). Sometimes creatures do climb pretty steep looking clifs, but never unreachable gaps, etc.

I'm all in favor of public discussions. I think we spoke about non accessible enemies entire month. All ideas and solution + chosen solution is somewhere in this thread. We can provide links to those posts while moving to review. That's not my point. I'm saying that it is having discussions with _myself_ using the forum is not very productive. Let me rephrase it: It takes at least two people to discuss something. If none asks hard questions and highlighting point we haven't thought about, no discussion is possible. As said before : I'm willing to help with whatever necessary (under time restriction). No offense taken, hope its the same by your side, no offense meant either. PS: Everybody wants to go to heaven, but nobody wants to die. Best regards

I do not consider it finished, I consider it ready for review. I would hate all this work goes to drain, forgotten in the back pages of this forums. As far as I see it, we do not have the luxury waiting until it is perfect. I don't think there are major issues reported (at least in master). About tests/performance: most if not all done by Undergarun and detailed report is in this thread - he should be contacted on the matter. I don't think I ever refused to answer a question. All code is public. If anyone indeed is interested in inner-works I can be contacted by either forums of mail. None yet to contact or show interest. You do understand my unwillingness to beg for tests/review/input/whatever, don't you? I do apologize for not writing proper external documentation for the entire code, but it isn't part of mangos's standard either. PS: I did not start this thread, therefore it is not my call to move it to "under review" section. Best regards

I'm all in favor. Unfortunately it is not up to me. I've done my part. Now its in the hands of folks who deal with repository. Faramir118's free to move this thread to under review section. Best regards.

mmm, pretty hard to debug something that happens once every few months You can use mmaps_rewrite branch as-is. The mmap code from there I mean.

Thanks. But I still think it would be better not to use the badly outdated code, instead of backporting (even degraded) version of spline system. Nothing to do with mmaps. I would like to implement a custom flag, using "CreatureFlagsExtra" that causes the creature to ignore pathfinding, I have tried doing this myself without success - it would be great if anyone could show me! You can set UNIT_STAT_IGNORE_PATHFINDING from any script. It is unit state and not extra flag which you can set from DB for a reason.