qsa

During development, only MovementGenerators needed access to the path. Now things are different, with MoveSplineInit using path also and other development trying to take advantage of pathfinding (and also trying to reduce performance impact with caching or reuse of existing path).

Maybe it makes more sense now to have the path as a member of Unit, and let all of these other things access it?

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

...

Thanks for your answear.

Is this mean i cannot check if there is path juste after something like

m_creature->GetMotionMaster()->MoveChase(m_creature->getVictim());
if (!m_creature->GetMotionMaster()->IsReacheable())
{ // Do something }

Because MoveChase is threaded?

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.

Tiny observation:

I usually compile on 64bit debug mode ( VC100)

So I switched to the mmaps_rewrite branch, and get this error

LINK : fatal error LNK1181: cannot open input file '\\dep\\lib\\Win32_Debug\\Detour.lib'

With 32bit release compile was alright

https://gist.github.com/1678748

should fix this issue

Is a Map ID all that is needed or will it require exact coordinates when reporting finding an off-mesh tile?

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.

Its added, but I cant reproduce the crash so we'll have to wait and see what happens.

I'll edit this post once I know more,

Thanks once again.

Edit: Stable so far(12h uptime)

Thanks for testing.

Added the patch to repository with some related changes.

Anyone else having problems with charge/pet walking through the ropes in Blade's Edge Arena?

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.

Yes it is included, but ill do a full re-patch/compile just incase.

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 ...

Could this be caused by a similair problem?

http://pastebin.com/n2nyyW8p

t = 0x4280003a <Address 0x4280003a out of bounds>

The crash itself seems very similair. (and also seems to be caused by offmeshes)

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)

It seems to work

...

-Midna

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

Thanks for testing.

Hello, I got mmaps working on OregonCore(2.4.3) using the mmaps_rewrite repo, But I'm having problems with offmeshes, I've looked at the fixes Posted before(page 38 post #936) but they are already included.

After walking across an offmesh a few times I get this crash:

http://pastebin.com/wrPCDnrK

I managed to reproduce it on local and it seems to be fairly deep in the detour code:

...

In this code taken from DetourNavMeshQuesy.cpp 't' seems to be invalid at the time of the crash. simply returning a DT_FAILURE when this is the case will cause the pet to get stuck.

Is this something related to Oregon Core/backport?

Any suggestions are welcome.

-Midna

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.

qsa, I just want to know if the evade timeout for creatures is finished? Or any news on this point?

Have a nice day!

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.

hi,

I have a bug:

If a creature knockback you in air, the creature goes into enterevademode, because the creature can't reach you. I hope for fast help.

Same as above, missing evade timeout.

I've tested this on blizz recently and I noticed that if you attack an npc which can't reach you or has a very long and complicated path in order to reach you, then it ignores the path finding and gets to the players climbing directly the steep terrain.

The same thing happens for the pet. If follows you straight if you jump of a cliff.

The important thing however is that they always stay on the ground (no matter how is the terrain designed). They never follow or chase in the air.

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.

About discussion points I remember we talked in this thread about problems related to AI behaviour in case of non accessible enemies - so I (as I come from scripting side) will directly have as concern how these parts of interaction have been solved.

Discussion might for such a project mean that you note in a review-thread how you solved things, which problems you think, and why you have discarded which alternative solutions.

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

oh - I didn't even know you consider this patch as "finished".

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.

Also especially directed to qsa and faramir:

One big step about developing is not "only" to write code, but to discuss the code and argue about weaknesses in the code.

This is actually one of the things that slows mangos down the most: we try to discuss most serious changes, and this takes most of the time.

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.

http://pastebin.com/k5ymyHeQ

mmm, pretty hard to debug something that happens once every few months

Any updates for mangos-one? I think that now the core was updated with the lates spline system changes.

You can use mmaps_rewrite branch as-is. The mmap code from there I mean.

The movement maps feature branch of mangos-zero now contains an initial backport of movement maps and can be tested.

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.

Hello,

yesterday I got some massive falldamage ~9k after dismounting from a flying mount in "The Storm Peaks", ca. a meter above the ground. That happend a few times (noticed it after dying ), anything mmaps related? I don't run any other patches and couldn't find any other topics in Bug Reports forums section.

Revision 11786

YTDB 606

ACID 3.0.8

ScriptDev2 2271

MMAPS just missing "+ Use partial path while under effect of Confused/FleeingMovementGenerator."

Regards

Skirnir

Nothing to do with mmaps.

Hello!

I would like to make it possible to disable pathfinding for certain NPCs by using a flag in the database

and as stated before (at page 43):

We have CreatureFlagsExtra for custom flags, like CREATURE_FLAG_EXTRA_CIVILIAN, CREATURE_FLAG_EXTRA_GUARD and etc.

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.

mangos-zero has a movemaps branch which is being updated this weekend with most of the patches which we had the chance with a bigger installation of mangos-zero.

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!

Fear/Blind etc. (and charging) above tunnel often results in falling down to the tunnel.

Can't reproduce it either on clean using updated maps.

Don't have post-collision enabled?

Negativ Feedback:

Big Problem with fear: players are falling under map or go through walls (you can test it in tunnel in warsong)

Sometimes no movement if player is in fear.

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.

....

don't check on "clean core". mangos has at least 2 errors (one sience ~200 commits) with detect ground/water pozitions -> need some corrects.

What exactly are you talking about?

...

Well all thread safe parts could run separatley? I mean so all cores are use to full load?

- LilleCarl

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.

Anybody noticing creature's evading way too early? I pull some creature or mob, I go hug a wall or something or jump over some obstacle so the creature/mob cant reach me and then the mob/creature starts evading.

Now I dont know if this is intended behavior (is it?) but too me it looks like something is not right.

Dug into the pathfinding code and I found this.

In pathfinding "targetedmovementgenerator.h" there is a function called "isreachable" and it does this check.

return (i_path) ? (i_path->getPathType() & (PATHFIND_NORMAL)) : true;

shouldnt this be more elaborated with the other pathfind type like this?

return (i_path) ? (i_path->getPathType() & (PATHFIND_NORMAL|PATHFIND_INCOMPLETE)) : true;

I have tested this and the creature/mob is now following me more consistently - ie does not brake off chase so easily.

Just a thought....

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.

...

My players are reporting more falls under map that usually was. Reports about those issues coming soon but i suggest to use pathfinder on ConfusedMovementGenerator for generate random movements over valid terrain. ^^

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.

Sorry for doubleposting, but it feels better, sometimes when i run a stair (a rolled stair if you get what i mean) and the npc in this case is above me, he stops and thinks he is at my position, he is in 2d but not in 3d..... i will provide a movie laters (also there are some places he just airwalks etc (got it on movie aswell)

- LilleCarl

Shouldn't happen unless spiral levels spaced more than 5y apart.

Unless its one of the GetNearPoint()'s features.

Please provide coordinates to reproduce.

Post Collision is disabled on my realms.

Single threaded tests of mmaps on low populated realm:

...

Note: Crash between tests so is not a just mmaps.enabled = 0 and .reload config

...

Tests on multithreaded high populated realm coming soon!

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.

...

Although, I still found little bug with pathfinding: When I stand on stage and attack, of course the mob go up slope and towards me. But suddenly at about 15 yards position it turned back and moved 10 yards away from me , then towards me again. The whole action looks like unseen obstacle put on his way and he move in a circle to attack me. But the place is flat. Sometimes it moved back and back two times before access me.

...

Best regards!

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.

...

I tested a few minutes ago, this issue( GetNearPoint bug ) is still on Undergarun's server:

http://i53.tinypic.com/vcrvkk.jpg

http://i54.tinypic.com/6p6flk.jpg

http://i53.tinypic.com/fatnwo.jpg

Best regards

Tested on local in exact places you showed and it worked just fine for me.

Don't have DETECT_POS_COLLISION enabled?