MMaps Redux

[Neo2003]

- does the mob not react at all?

I can answer this one. The creature takes damage from the first shot(s), then become immune and you have a yellow text "Immune" and it is back full life.

[Toinan67]

Tests results!

Environnement : I made the tests with a character lvl 84, in outland (vs lvl 70 mobs), and in deepholm (a new cataclysm zone, vs lvl 82-83 mobs).

It may be unclearly presented...but it's what happen on retail

The tests begin when you're out of combat, noone attacking, you're not attacking anyone.

So here are the results :

- If you attack a mob while you're reachable :

- if you stay where you are : normal behavior, he just chases you till he dies, you die, or you flee

- if you become unreachable :

- if there is another target (for me, it was my magma totem) :

- he attacks the other target. When this target dies, if there is another reachable target, he attacks it. Otherwise, evade immediatly

- if there is no other target :

- evade immediatly (not even 1 second of waiting)

- If you attack a mob while you're unreachable :

- he doesn't move from where he stands at the moment, he just faces us

- he attacks with ranged attacks/spells if he can, otherwise it does nothing.

- if he does not attack you with ranged attack/spell, he evades after precisly 26 seconds (don't ask me why).

It was the same 26 seconds for lvl 70, 71, 82 or 83 mob.

- if you become reachable before 26 seconds, he starts chasing you, and attacking you.

- he seems to be in a "nearly evading" state, because :

- as long as you're unreachable, you can't reach him either ("miss" all the time), unless he attacks you with ranged attacks/spells.

In that case, you cannot reach him all the time, but just when he casts his attack/spell (this part was a bit unclear for me...)

- he is constanly regenerating full life/mana (every 2 or 3 sec.).

- it seems like retail has some troubles too : I attacked a mob while I was unreachable several times.

Then, when I tried to attack him being reachable, he wasn't able to chase me anymore, he was rooted.

I hope you will find some useful informations here, please tell me if you want more precise testing.

[faramir118]

I think the part we really disagree on is the intent of pathfinding. Is it a tool to only build a point path, or should it be used for other things?

The statement "breaks modular coding way by mixing pathfinding into AI" is contradictory to me. Pathfinding is AI.

Behavioral corner cases are easy to handle, or even avoid, when you can see the big picture. Reachability tests during target selection accomplish this nicely.

IMHO the debate about lazy vs eager path generation, performance vs robustness, etc is just a side effect.

On a side note, I want say thanks. It's really refreshing to work with people who care enough and are able to form logical arguments for and against different aspects of a design.

[qsa]

...

- If you attack a mob while you're unreachable :

- he doesn't move from where he stands at the moment, he just faces us

- he attacks with ranged attacks/spells if he can, otherwise it does nothing.

- if he does not attack you with ranged attack/spell, he evades after precisly 26 seconds (don't ask me why).

It was the same 26 seconds for lvl 70, 71, 82 or 83 mob.

- if you become reachable before 26 seconds, he starts chasing you, and attacking you.

- he seems to be in a "nearly evading" state, because :

- as long as you're unreachable, you can't reach him either ("miss" all the time), unless he attacks you with ranged attacks/spells.

In that case, you cannot reach him all the time, but just when he casts his attack/spell (this part was a bit unclear for me...)

- he is constanly regenerating full life/mana (every 2 or 3 sec.).

- it seems like retail has some troubles too : I attacked a mob while I was unreachable several times.

Then, when I tried to attack him being reachable, he wasn't able to chase me anymore, he was rooted.

...

Thanks for testing.

This is not exactly how I remembered it, but close enough.

Are you sure that if you are unreachable target will not even try to come closer?

Overall this seems not very natural behavior to me. Don't really sure why. But its clear that "they" deal with "no full path"="something wrong" -> just error out ( evade ).

Can you please also test the scenario when you have 2 targets. Main target becomes unreachable, while the other still is. NPC will switch to 2nd target, but what happens with threat? something visible?

Thanks in advance.

Should we follow this type of behavior at all? I mean, do we really need to copy their bugs?

We can either try to mimic retail behavior using the fastest/most accurate solution, OR we can try to make something more reasonable.

But that's totally different question.

I think the part we really disagree on is the intent of pathfinding. Is it a tool to only build a point path, or should it be used for other things?

I think we disagree on the "how", not the purpose of pathfinding.

We can always make different class with only purpose will be checking reachablity. We sure can save some CPU cycles there, since we wont have to generate anything but poly paths + couple simple checks.

Then we can use this class for checking targets in SelectHostileTarget.

This is perfect solution. We'd know if we can reach target even before selecting it.

Unfortunately, this is where we really disagree. Perfect solution do not exist in our imperfect world.

Those checks are not free. If they were, we'd just use them.

Here is where the problems start. Making it happen.

If we just check all those targets and then generate path for chosen one we are wasting alot of resources.

If we try to somehow use the data we generated there to build the path, we are mixing AI with Movement.

Sure, you say : "lets make it so efficent, so it wont metter how many paths we generate, how many checks we run".

The best you can do here is cut the overhead as close as you can to A* cost, its our lower bound.

It is far, far from "free" or low.

Best regards

[Toinan67]

(i don't want to interfere in the debate, just sending tests results)

Are you sure that if you are unreachable target will not even try to come closer?

Yes, I am 100% sure.

If you become unreachable, it will evade instantly. If you were already unreachable, it will wait 26 seconds to see if you become reachable again. Then, it will evade.

I noticed something new, though. If you move just a little bit after attacking it, going left and right on 1 meter, it will evade much more faster (something like 3-4 seconds after you started).

Overall this seems not very natural behavior to me

I find it quite natural, if you start a fight with someone, they force you to _fight_ and become reachable, by constantly regenerating the victim's life, and making your attacks miss all the time. If you attack a mob, they want you to be able to be killed by this mob. Quite normal ^^

About threat, the threat doesn't change during those 26 seconds. It doesn't reset, goes down, anything. It stays at its value.

For multiple targets....actually I have no idea how to become unreachable after attacking the target. Searching for spots....

For the previous tests I just used my flying mount to run next to the mob and then go up.

I need a place where I can damage the mob, and then jump on something where it can't reach me. Ideas? ^^

(if faramir could show me where is the spot he was talking about in maghteridon's lair, for example)

Edit: well I managed to do it with my totems.

Apparently (according to omen), if the main target becomes unreachable, it is simply deleted from the threat list.

I aggro a mob, put it next to my magma totem, stay here for a few seconds. Then, I go up : I am instantly out of combat, out of the threat list, and the mob attacks my totem.

If I go reachable again, while the mob is attacking the totem, I don't get my threat back, I'm just a "new" target.

[Schmoozerd]

possible test scenario:

use a small river, pet on one side attacking a non-swimming mob, you do dmg from the other side

tests:

both start on mobs side, you cross to other side

pet start on mob side, you not

some wild crossing from you

[faramir118]

Would like to see some tests where player is not flying. That is probably handled with aura and height checks.

I might see if I can borrow an account from a friend, or maybe just reactivate mine for a bit...

if targets are removed from the threat list, we will have to do so in ThreatContainer::selectNextVictim(). Path check (lazy or eager) will have to be independent of any other checks.

[qsa]

Made few more changes.

* Everything from my previous patch ( post #445)

* Ability to specify which type of point path to generate. Either smooth or straight.

* Implement pathfinding in charge effects using straight path.

- Added Unit::MonsterMoveByPath() to simplify this case and allow usage in similar.

* added the ability to specify path type in ".debug mmap path" command. ".debug mmap path true" for straight path, smooth is default (or false).

patched over (213e909001b7) :: http://pastie.org/1232897

Take care.

[faramir118]

qsa, do you have a github account? I can add you as a commiter, so this doesn't take so long.

[KAPATEJIb]

* Implement pathfinding in charge effects using straight path.

works really good if objects that exist on caster's way _can_ break LOS.

But there is a problem when you stay under mountain and try to charge - because there is no path for this place caster will use (as i think) standard MonsterMove and fall through textures ofcouse (because of some falls by z coord every step when moving, yes you can increase "z" parameter when calling MonsterMoveByPath but this will cause a thing like jumps after charge into the air on this "increase value" if caster's and target's z is equal or target is below caster for z coord)

now is the time to show you some examples (offy vs mangos + mmaps patch + last changes by qsa), forget what i shows you before if caster on the high mountain (it was just my opinion "how it should work"), yesterday one man was checked this feature at offy and here the new pictures

http://filebeam.com/d0eeea60ba099beea16e5530c9b85e6f.jpg

I have an idea for take some code from patch that i found on this forum (author darkstalker) that prevent casting through mountains (causes them to break LOS), ofcourse it prevents wrong behavior when we trying charge through mountain without path to your target, but it will prevent other spells to lost LOS in same case too (that is wrong, because it's an offy feature).

I think we can add this code http://paste2.org/p/1046384 (who is the original author - see above) to force mountains to break LOS, but we should check if there is a path for this place at first, then break LOS if no path.

So i need to know how to check if path exist from caster's position to target position, can you help me with that? Something like (it just a sketch)

if (!path(caster,targetx,target,y,targetz)) // we have a path?
   return SPELL_FAILED_LINE_OF_SIGHT;
else
   {
       ...    // code from patch that i posted above
       return SPELL_FAILED_LINE_OF_SIGHT;   // result
   }

[qsa]

qsa, do you have a github account? I can add you as a commiter, so this doesn't take so long.

I rather not, but if you really don't have time dealing with this, I'll add it. My nick there is sixsixnine .

works really good if objects that exist on caster's way _can_ break LOS.

But there is a problem when you stay under mountain and try to charge - because there is no path for this place caster will use (as i think) standard MonsterMove and fall through textures ofcouse (because of some falls by z coord every step when moving, yes you can increase "z" parameter when calling MonsterMoveByPath but this will cause a thing like jumps after charge into the air on this "increase value" if caster's and target's z is equal or target is below caster for z coord)

Firstly, thanks for testing.

About the issue you describe:

The real problem there is the value returned from GetContactPoint(). Target falls under map since point returned there ( in some cases ) below the actual terrain. This is due to VMAPs.

The way point path is generated for charge effects, is that it will always reach the final point given..

I do know this issue exists, but it is not directly related to mmap. Therefore, I think, all those changes and problems should be solved regardless of pathfinding usage.

For example, the last case scenario (and first) you gave has absolutely nothing to do with mmaps at all. It should be handled in LOS checks. But as we all know, at the moment terrain in not considered as obstacle in LOS calculation.

Just to sum it all up : someone should make independent patch solving those issues. I rather not do it as part of mmaps. Simply since it is not directly related and we don't want to make this project even bigger than it currently is.

Best regards.

[KAPATEJIb]

another "funny" bug: http://filekeeper.org/download/insider/different/loool_video.zip

[qsa]

another "funny" bug: http://filekeeper.org/download/insider/different/loool_video.zip

heh, thanks for showing.

Ye, I aware of this kind of bugs, but unfortunately there isn't much I can do there right now.

The problem is with the mesh itself. I bet that step right there is blocking the path, so all that longer path is found instead.

You can check it by generating debug info while generating mmaps, then opening it with recastDemo and actually seeing all the walkable polygons.

The reason we cannot eliminate those things all together, is the same reason we still have sometimes bugs with vmaps ( LoS checks). There are just too many cases. We can't make it manually either All we can do is try to minimize those.

Maybe faramir118 or Gotisch can take a look at those. Since I haven't really spent time on the generator yet, thus don't fully understand it (yet).

In general this charge shouldn't be casted at all due to LoS fail. But, as I said in last post : LoS+terrain = bugs (at the moment atleast ).

I did my tests in BE arena, and it worked there pretty fine.

Take care.

[Gotisch]

you should be able to to generate the mesh with different arguments.

I'm not sure how new generator is set up, but it may be possible to generate mesh with different parameters per grid (?).

So the only problem would be to find a correct setting configuration that works well per grid, ie. that isnt to strict so that stairs cause problems but that isnt to lax either, so that mobs walk "over" fences.

If you can only choose one set of parameters for all the navmesh would make things a bit more limited, but in the end its all about the settings. I'll try take a look at generator at weekend.

[faramir118]

I'll work on pushing your changes today.

I'll also make you a contributor - just try to break commits into smaller pieces so it's easier to understand what changes do.

it may be possible to generate mesh with different parameters per grid (?).

...

I'll try take a look at generator at weekend.

You'll have to add parameters. I'd make the custom recast parameters optional for the --tile option

You'll probably hate the parameter parsing code - it's a hack

[qsa]

I'll work on pushing your changes today.

I'll also make you a contributor...

It's like 5min of "work" splitting them and pushing (unless you do it manually, which I hope for you sake, you don't).

If you going to add me, I can push my changes on my own.

[faramir118]

It's just easier for me to commit pieces as I review them, but in this case there are too many inter-dependent changes in the same diff.

You can push to my repo, please go ahead and add your changes.

[Patman128]

I noticed you added pathfinding to charge effects. When these fail, will the charge fail or will it do a shortcut? On retail servers, if you can't get a path to the target, you'll just get an error "No path to target found" or something similar.

[Gotisch]

I'll work on pushing your changes today.

I'll also make you a contributor - just try to break commits into smaller pieces so it's easier to understand what changes do.

it may be possible to generate mesh with different parameters per grid (?).

...

I'll try take a look at generator at weekend.

You'll have to add parameters. I'd make the custom recast parameters optional for the --tile option

You'll probably hate the parameter parsing code - it's a hack

From a first look it shouldn't be to hard to add, the hacky code, i at least find nice to read. Relevant config settings are done in MapBuilder::buildMoveMapTile() from what i can see.

The settings are:

float cellSize = .5f;       // larger number => less voxels => faster build time
                                   // too large, and tight spaces won't be pathable.
float agentHeight = 1.5f;
float agentRadius = .1f;
float agentMaxClimb = 1.65f;

or are there any more somewhere else?

It should be no problem to add them as parameters (--cellSize, --agentHeight, --agentRadius, --agentMaxClimb). That way generators can play around with them.

From what i understood from code, tiles with different settings will work together.

Anyway, these are just guessed settings, no? or taken from recast demo.

Maybe there is a good set of settings that works well for all tiles.

If not, one solution is to have different settings for special tiles, no?

[edit: my english is getting really way to bad]

[faramir118]

There is also cell height (config.ch - MapBuilder.cpp:750), which can have an impact on obstacle detection.

The only one I tested extensively was cellSize. If you make it any larger, there will definitely be areas on several maps where doorways are impassable.

Mikko made a post a long time ago about the settings and what values to try first.

[qsa]

I noticed you added pathfinding to charge effects. When these fail, will the charge fail or will it do a shortcut? On retail servers, if you can't get a path to the target, you'll just get an error "No path to target found" or something similar.

It will "always" get you to destination (unless there's problem with mesh).

I never seen "path error" on retail, maybe its since LoS checks cover almost all such cases.

But from what I remember, you can charge across small gaps.

If we going to have the option to specify parameters for each and every specific map, maybe we can make bash script with all those "best" parameters for every map.

Some community input can be nice here. which values work the best for you for every map, etc.

PS: I pushed my recent changes into the repo.

[faramir118]

Should probably check the length of the charge's path, and return an error if it's too long. That would at least prevent the scenario in the video.

[blueboy]

Hi,

First of all great work with 'mmaps redux'.

A minor issue that I am getting when I compile the code from http://github.com/faramir118/mangos/tree/mmaps_rewrite/contrib/mmap

I'm getting this warning when I compile the current code with gcc on *nix

  CXX    debugcmds.o
../../../src/game/debugcmds.cpp: In member function ˜bool ChatHandler::HandleDebugMoveMapCommand(char*):
../../../src/game/debugcmds.cpp:379:88: warning: taking address of temporary

I have found a solution to this and here is the patch

diff --git a/src/game/debugcmds.cpp b/src/game/debugcmds.cpp
index ee01e20..b3b2d3c 100644
--- a/src/game/debugcmds.cpp
+++ b/src/game/debugcmds.cpp
@@ -369,6 +369,7 @@ bool ChatHandler::HandleDebugMoveMapCommand(char* args)
        player->GetPosition(x, y, z);
        float location[VERTEX_SIZE] = {y, z, x};
        float extents[VERTEX_SIZE] = {2.f,4.f,2.f};
+        dtQueryFilter filter = dtQueryFilter();

        int32 tilex = int32((y - min[0]) / 533.33333);
        int32 tiley = int32((x - min[2]) / 533.33333);
@@ -376,7 +377,7 @@ bool ChatHandler::HandleDebugMoveMapCommand(char* args)
        PSendSysMessage("Calc   [%02i,%02i]", tilex, tiley);

        // navmesh poly -> navmesh tile location
-        dtPolyRef polyRef = query->findNearestPoly(location, extents, &(dtQueryFilter()), NULL);
+        dtPolyRef polyRef = query->findNearestPoly(location, extents, &filter, NULL);

        if(polyRef == INVALID_POLYREF)
            PSendSysMessage("Dt     [??,??] (invalid poly, probably no tile loaded)");

Hope this helps

[qsa]

Should probably check the length of the charge's path, and return an error if it's too long. That would at least prevent the scenario in the video.

Its not real solution. Tho we can add it as temp hack. Not sure if we should deal with this at all.

But in general, it can be good idea to have the ability to limit the point path length dynamically.

...

A minor issue that I am getting when I compile the code from http://github.com/faramir118/mangos/tree/mmaps_rewrite/contrib/mmap

I'm getting this warning when I compile the current code with gcc on *nix

...

Hope this helps

Thanks for noticing this typo. I pushed the change into repo.

We welcome every little bit of help.

[faramir118]

Doing some cleanup on the generator. None of the changes add functionality yet (not until vmap liquids)