Jump to content

MMaps Redux


Guest auntieMangos

Recommended Posts

the debug .obj generated with generator looks weird to me (loaded into recastdemo)

http://img405.imageshack.us/img405/3962/screenshot14l.png

maybe someone can check it too? maybe its just me, or there is problem with .obj generation or even vmap usage

./MoveMapGen --tile 35,46 --debugOutput true 0 

edit: seems to be just my source for recastdemo. shame on me for getting it from github and not googlecode

Link to comment
Share on other sites

  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

map#.obj = unmodified RecastDemo

#.obj = modified RecastDemo

I modified RecastDemo to use it with our project, so that I could load the navmesh produced by the generator, as well as the raw debug output.

This version loads the intermediate data debug files and the #.obj file produced by the generator, and it has some functionality that allows you to display 1 tile at a time.

It only builds on Windows (only other build I saw was Mac Xcode).

The unmodified version only uses the map#.obj file produced by the generator. You won't get to see the generator-built navmesh.

The generated obj file for this version had an off-by-one error in the triangle indices. It should be fixed now.

edit: Oops, didn't see your edit. My change works fine in the binary on github.

Link to comment
Share on other sites

Very often crash at last version of mmaps =(

Call stack:
Address   Frame     Function      SourceFile
007A042A  00000000  PathInfo::findSmoothPath+9A
004806EA  00000000  MaNGOS::WorldObjectWorker<MaNGOS::NearUsedPosDo>::Visit+A
4589FFFE  00000000

This is not valid stack call.

Any chance you know how this can be reproduced?

Thanks in advance.

PS: anyone having any other related crashes? ( with *nix dumps preferably )

Link to comment
Share on other sites

map#.obj = unmodified RecastDemo

#.obj = modified RecastDemo

I modified RecastDemo to use it with our project, so that I could load the navmesh produced by the generator, as well as the raw debug output.

This version loads the intermediate data debug files and the #.obj file produced by the generator, and it has some functionality that allows you to display 1 tile at a time.

It only builds on Windows (only other build I saw was Mac Xcode).

The unmodified version only uses the map#.obj file produced by the generator. You won't get to see the generator-built navmesh.

The generated obj file for this version had an off-by-one error in the triangle indices. It should be fixed now.

edit: Oops, didn't see your edit. My change works fine in the binary on github.

i added cmakefiles to build it on linux and it works fine ( i think ):

if i put it into directory of MoveMapGen and generate with debugOutput i can launch it select debug as Sample and <mapid>.obj as input mesh. Problem is it seems to load every tile in map, wich reduces usage possibilites (i.e: my pc can't handle it :D). you said there is way to only display one tile at a time? i couldnt find anything relating to that in debug.cpp code, or did i just miss it?

For debugging purposes optimal would probably be the display of the current tile and if wanted the 4 adjacend tiles, no?

Link to comment
Share on other sites

One more crash:

Registers:
EAX:0000003C
EBX:00000000
ECX:0ABA513C
EDX:0ABA5124
ESI:00F30716
EDI:0ABA513C
CS:EIP:001B:00409E2B
SS:ESP:0023:0ABA50C0  EBP:00000014
DS:0023  ES:0023  FS:003B  GS:0000
Flags:00010216

Call stack:
Address   Frame     Function      SourceFile
00409E2B  00000000  dtDistancePtPolyEdgesSqr+4B
004047E2  00000000  dtNavMeshQuery::closestPointOnPolyBoundary+152
007A03E6  00000000  PathInfo::findSmoothPath+56
458B20EC  00000000  

=(

Very often crash at last version of mmaps =(

Call stack:
Address   Frame     Function      SourceFile
007A042A  00000000  PathInfo::findSmoothPath+9A
004806EA  00000000  MaNGOS::WorldObjectWorker<MaNGOS::NearUsedPosDo>::Visit+A
4589FFFE  00000000

hint: dont compile in Release

Why? Debug can resolve this crash? =)

Link to comment
Share on other sites

One more crash:

....

Why? Debug can resolve this crash? =)

This stack looks more logical, but, without line numbers and locals there's not much I can do.

Either that, or way to reproduce.

I don't see how it can crash, but sure, there always can be really strange corner cases.

So, ye, in a way, debug can solve the crash. Just as others already mentioned.

If anyone have *nix core dumps, don't be shy and post them here. If it is as common as KiriX say it is, you shouldn't have problem getting those.

Take care.

Link to comment
Share on other sites

http://github.com/insider42/mangos/commit/e9ef7e36ae5929b3eb1f327673646f9302ff9fd0

also encounted a problem when i have DoStartMovement(pWho, 20.0f); or something like that in script - ofc mob will stay at 20 yards from you and use ranged spells, but it will EVADE after few secs because of evade code from mmap mod.

How can i fix this problem? Maybe there is some other way to prevent npc from trying to do melee for scripts? Or how i can check if mob is ranged before evade it (add some checks for mmap evade code)? Or how i can force boss to ignore mmaps if there is no path to his target (how it work at first versions of mmaps), for example add this check for instance npc's?

Link to comment
Share on other sites

http://github.com/insider42/mangos/commit/e9ef7e36ae5929b3eb1f327673646f9302ff9fd0

also encounted a problem when i have DoStartMovement(pWho, 20.0f); or something like that in script - ofc mob will stay at 20 yards from you and use ranged spells, but it will EVADE after few secs because of evade code from mmap mod.

How can i fix this problem? Maybe there is some other way to prevent npc from trying to do melee for scripts? Or how i can check if mob is ranged before evade it (add some checks for mmap evade code)?

About that patch: we are not yet on mangos version that require this change. It will be included when we update.

About DoStartMovement : is is unforeseen side effect (when offset is used) from old evade code.

I am currently working on implementing better way.

This issue should be solved there.

I'll post it for testing, as soon as I have time for some basic checks.

Thanks.

PS: do you have issues with stability?

Link to comment
Share on other sites

Below attached test patch.

Implements evading and aggro changes on targets that become unreachable.

Pretty much everything we spoke about.

It uses the lazy logic. Which makes it simple yet effective.

The only thing missing (as far as I know) from all the things we spoke about, is evading timer. Right now its 0 delay. But since it is used only in very specific place, this feature can wait for later.

Feel free to test and report issues.

Patched over (c8a25250df7752) :: http://pastie.org/1248321

Ideas, remarks, criticism is always welcome.

Take care.

PS: Can anyone check that I remove the target from aggro list properly? lines 140 and 200 in diff . Thanks in advance.

Link to comment
Share on other sites

you said there is way to only display one tile at a time? i couldnt find anything relating to that in debug.cpp code, or did i just miss it?

For debugging purposes optimal would probably be the display of the current tile and if wanted the 4 adjacend tiles, no?

Hrm, looks like the part that hides the mesh went missing. I will add it back in.

Right now I just have a slider at the bottom of the debug pane (bottom right of window, scroll down). It lets you change which tile's debug data is rendered.

PS: I don't like this 'procedural UI drawing' RecastDemo uses :(

Link to comment
Share on other sites

Reluctance for Minions or Pets to follow the owner.:/

I thought you might be interested in this issue that occurs with the current 'mmap_rewrite' code.

Test: I created two identical server builds, on with the mmap_rewrite code and one without.

With mmap_rewrite code

Minions in particular will not automatically follow the owner. Selecting the 'follow' button does prompt the minion/pet to catch up with the owner, but then remain at that point until you press 'follow' again.

Without mmap_rewrite code

Minion/pets automatically follow owner unless commanded to 'stay'.

I have not found what is causing this, but suspect that something is interrupting 'MoveFollow'.

Hope this helps a little.

Link to comment
Share on other sites

Reluctance for Minions or Pets to follow the owner.:/

I thought you might be interested in this issue that occurs with the current 'mmap_rewrite' code.

Test: I created two identical server builds, on with the mmap_rewrite code and one without.

With mmap_rewrite code

Minions in particular will not automatically follow the owner. Selecting the 'follow' button does prompt the minion/pet to catch up with the owner, but then remain at that point until you press 'follow' again.

Without mmap_rewrite code

Minion/pets automatically follow owner unless commanded to 'stay'.

I have not found what is causing this, but suspect that something is interrupting 'MoveFollow'.

Hope this helps a little.

Thanks for testing.

This issue should be fixed in my latest test patch. Feel free retesting and report.

faramir118: Are you sure http://github.com/faramir118/mangos/commit/27980025db926e26fedf758cf1d4479f321a3386 is necessary?

those modes are far more useful than the debug. Simply since you can "play" in real time with parameters and see the effects.

Link to comment
Share on other sites

qsa:

I like the changes in your most recent diff. :)

For pets, we will need to handle nopath in PetAI::UpdateAI (or PetAI::_needToStop).

If pet can't reach the target, PetAI::_stopAttack

If pet can't reach the owner, what is the expected behavior? Relocate to owner?

Right now, pets will try to come as close as they can to target/owner.

I think its more than reasonable. So, no changes in pet code needed.

Don't really remember how it is dealt with on retail, but its either that, or just taking no action at all.

Personally, I like the first option. It doesn't cost us nothing.

I'll give people time test it bit more, and push it.

Link to comment
Share on other sites

I play a hunter on offy as my main.

When the pet cannot come back to the hunter, it stays at near possible place. Then if the Hunter go away or the place is to far from the hunter, it despawns.

If the pet cannot go to the target, it resets his command and go back to the hunter.

Pet never relocate, but can climb a very high angle if needed to join the hunter, lot more than a player can do.

Link to comment
Share on other sites

Reluctance for Minions or Pets to follow the owner.:/

I thought you might be interested in this issue that occurs with the current 'mmap_rewrite' code.

Test: I created two identical server builds, on with the mmap_rewrite code and one without.

With mmap_rewrite code

Minions in particular will not automatically follow the owner. Selecting the 'follow' button does prompt the minion/pet to catch up with the owner, but then remain at that point until you press 'follow' again.

Without mmap_rewrite code

Minion/pets automatically follow owner unless commanded to 'stay'.

I have not found what is causing this, but suspect that something is interrupting 'MoveFollow'.

Hope this helps a little.

Thanks for testing.

This issue should be fixed in my latest test patch. Feel free retesting and report.

faramir118: Are you sure http://github.com/faramir118/mangos/commit/27980025db926e26fedf758cf1d4479f321a3386 is necessary?

those modes are far more useful than the debug. Simply since you can "play" in real time with parameters and see the effects.

Hi,

I've tested the mmap_rewrite with your latest patch and the minion still does not follow it's owner. I have a warlock with a succubus minion and it does not follow, but lags behind until beyond LOS, then it despawns. I have played a warlock with minion on a Blizzard server and I do not remember it behaving this way.

I have monitored program flow through PetAI::UpdateAI and 'MoveFollow' is called once as expected

            if (!m_creature->hasUnitState(UNIT_STAT_FOLLOW) )
{
     m_creature->GetMotionMaster()->MoveFollow(owner,PET_FOLLOW_DIST,PET_FOLLOW_ANGLE);
}

but something is then preventing the pet/minion from reaching the target/owner.

Cheers

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use