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.

I'm glad to see mmaps-zero has its hew champion in a shiny armour to carry on the torch. I'm not quiet sure how up-to-date zero and one branches are. The core code there is from dark ages before spline integration. I think (laziness speaking) that it would be easier to start porting from master, simply since it is much better tested and up-to-date. Regardless, Good luck!

Can't reproduce it either on clean using updated maps. Don't have post-collision enabled?

Are you sure you have mmaps extracted fro BG maps? Tested in WSG tunnels - works like a charm - with small modification tho, on git now. What exactly are you talking about?

Sure they can, but their results are interdependent. You cannot eat your breakfast before you woke up (as silly example). There's order in which (some) calculation has to be made. Besides, as I said above, for full cpu load, even instance based granularity will do.

Mmap code run in the contexts of its map. While doing path calculation asynchronously may seem like a good idea at first glance, when you think about it, the result is actually blocking under current model. If we could separate "tasks" in same update cycle of every given creature/event/whatever, that would be different story. Ask to calculate path, do something else, get the result, send update ... When you think about it, even this model is useless. If you have low population server, cpu performance is never a problem. On densely populated server, even properly splitting by higher granularity like tiles/maps will utilize all cores on full load. I'm not even started to talk about the sync overhead. Bottom line, I think making threading model for mmaps is useless. It is thread safe (under current granularity). True multithreading for mangos is different story, but that's not directly related to this topic.

Evade timeout for creatures is not yet implemented. At the moment creature will evade as soon as there's no full path to its target, instead of evading after timeout (while not taking damage meanwhile). You can check where isReachable() used in code, it'll give you good point to start with. You're 'solution' will just allow players to kill from ranged distance any creature by moving a little bit in unreachable place - creature will always generate partial path (aka : PATHFIND_INCOMPLETE). Best regards.

Thanks for the results. Looks solid to me. No memory consumption increase (all mmaps are already loaded anyway), around ~13% CPU spread among cores. Lovely. About falling under maps: possible when movement generator is broken before finalization. Actually, there's pretty simple solution that will give same results as old generators: using vmap heights for points + adding some error margin. Have to test it, to see if that isn't too expensive. EDIT:Tried to use VMAP heights instead of MMAP's and it was total disaster, turns out they are even less accurate Using ConfusedMovementGenerator instead of RandomMovementGenerator? Why? Random cannot ever be applied to players, therefore is is much cheaper. Other than that, they about the same. EDIT: Added something to repo, should help quiet a bit.

Shouldn't happen unless spiral levels spaced more than 5y apart. Unless its one of the GetNearPoint()'s features. Please provide coordinates to reproduce.

Looks great, Thanks you. We can conclude that it is stable and "costs" less than 10% CPU and about 3giga memory with no unloads. I think that its totally reasonable. Looking forward for multithreaded results. Should scale really well. Thanks you for those reports. I'll check it this weekend. I don't sure if its case of problematic geometry or side-effect of using weighted A*. This kind of behavior is common? Thank you guys.

Tested on local in exact places you showed and it worked just fine for me. Don't have DETECT_POS_COLLISION enabled?