MMaps Redux

[qsa]

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.

[breakwater]

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.

And i hope that the merge with mangosmaster is "IN_PROGRESS"

[desteny]

there is no more mmap branch in the mangos-one/server repo, and the old one was not 100% updated right?

[desteny]

could someone tell me whats the status of the mangos-one mmap integration?

i noticed that the spline integration is finished (i don't know if it is 100% finished) but there is nothing about mmaps (https://github.com/mangos-one/server)

the mmap feature branch is not there any more since the repo was migrated tho the new one.

but the old mmap branch was not realy up to date.

Sorry for asking again, but is someone working on it, or not?

if not maybe i will start backporting the mmaps from master, the only thing i want to avoid is to make senseless work

[Edit] the actual branch is this one right? (https://github.com/faramir118/mangos/commits/mmaps_rewrite)

the branch for mangos_one is not up to date (https://github.com/faramir118/mangos/commits/mmaps_one) better to use the mmap_rewrite branch as base, right?

[cyberium]

After 1,5 year of devellopement we can espect the dev are littlebit tired about this.

I personaly didn't get any issue (but on very little server used occasionaly).

Why this not applied to master?

Erf i am completly off topic... Sorry

[Unkle Nuke]

For those of you waiting on a full backport of mmaps to MaNGOS-One, please be patient.

mmaps-redux is a HUGE code base and it takes a lot of work just developing it for MaNGOS master. When you figure in the One and Zero projects, that workload is tripled. Don't forget, there's still the usual dev work, also the bug-fixing and backporting of other large patches like cyberium's AuctionHouse Bot, as well as a lot of new features for spells, database handling, and gameobjects support.

The Core Team wants to bring you a working mmaps backport that is as bug-free and fully working as they can make it. There's a lot of changes that must be made to accommodate the differences between the three major client versions. Progress is being made, but sometimes it isn't visible to us mere mortals because the work-in-progress code is sitting on a developer's hard drive, until it's ready to be committed to one of the repositories.

You have just a small handful of core devs, who are working on three separate code repositories, in whatever spare time they may have while still juggling all the responsibilities and demands of real life. Let's cheer them on, but also be understanding.

[qsa]

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.

[Schmoozerd]

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

A thing I missed about AHbot: Do you have serious and clear enough documentation? (both user side as code side)

Other then that, I think we need someone to explain what this code actually does, where remaining problems lie, etc. In short: communication.

I won't be around this weekend, and also don't have much time currently available, but I know that I won't look into such a complicated and big patch without being sure that there is somebody who explains it to me (as I am usally slow and stupid I would need assistance)

Also ofc some more communication with Silverice is required, because he has always good ideas for changes related to movement handling in his mind, and maybe we would be better advised to schedule such projects.

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.

[cyberium]

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.

You are right

That's UnderReview section is for.

But do we need another 1,5 year?

Cheers

ps: with all my respect for all that work

[Schmoozerd]

You shouldn't measure time in quantity but by quality.

I guess for a project like mmaps we would require

* 1-2 serious feedback tests on performance

* Some discussion points about parts where it is not clear how they behave.

If this would be done within a week, then the time for review is likely 2 weeks, if this feedback wouldn't be given within 2 years, then you cannot expect review to be faster

[cyberium]

You are still right (as always )

But don't forget, iam sure this patch is heavly used on some big server from longtime now, i hope at least some of admin of them will help us with some feedback like Undergarun was providing us.

Again sorry for this off topic. It's only to make some avancement.

[Xfurry]

I think there is already some feedback about the patch here on this topic. Check the replies from Undergarun and other users who already tested this.

[qsa]

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

[Schmoozerd]

I think I might have been misleading.

I really did not want to complain about anything you two guys did here (as it is a great job in any way).

I just wanted to note a few things that I might miss - before looking into the code.

I know mangos has been sloppy on documentating, but the more that is documentated the better.

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.

Really no complaining intended - I just try to tell what I think might make getting into this code easier (for a newb like me)

Btw - even if you did not start this project/ thread, as you are very familar you

_can_ post it in the review section when you think.

But well by now at least I know that this is topic is hot, and likely I will try to get into it when I have time.

(without this one post I wouldn't have known this)

Edit: Some example of a thread I really like, because it really contains discussion: In my opinion such threads are the most important of all, because they make it possible to understand what other people are thinking.

http://www.scriptdev2.com/showthread.php?t=3930

(though a very simple problem - syntax)

[qsa]

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

[aming51]

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.

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

Have a nice day!

[Xfurry]

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.

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.

[qsa]

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.

[Midna]

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:

const unsigned char* t = &tile->detailTris[(pd->triBase+j)*4];

const float* v[3];

for (int k = 0; k < 3; ++k)

{

if (t[k] < poly->vertCount)

v[k] = &tile->verts[poly->verts[t[k]]*3];

else

v[k] = &tile->detailVerts[(pd->vertBase+(t[k]-poly->vertCount))*3];

}

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

[qsa]

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.

[Midna]

It seems to work

I really appreciate the work you put into this and thanks alot for the help.

-Midna

[desteny]

Thanks for the fast reply,

only for information, this backport for oregoncore is based on two different repos, the first one is the this one https://github.com/faramir118/mangos/commits/mmaps_rewrite (the complete dep/recastnavigation, and map / vmap / mmap generator are complete the same) (small modifications based for 2.4.3) the pathfinder, and movemaps are also from this repo, but without spline (code doublechecked with the code used on mangos zero (https://github.com/mangos-zero/server/tree/feature/movemaps))

only the movement generators are based on a TC2 mmap backport, because there are to much differences between trinity and mangos.

only one question, what is the most complete repo for the mmap rewrite?

i was thinking it is this from faramir118?

We have realy the intention to test and report problems here, and it makes no sense to make testing on a outdated code base

thanks in advice

[faramir118]

In my repository, mmaps_rewrite is the newest version. The backport branches are outdated quite a bit (relative to mmaps_rewrite AND to their respective mangos versions)

mangos one is in a good position for a complete backport of mmaps - the spline movement has been backported, which was the major roadblock before

mangos zero still doesn't have the spline movement backport, so it can't be a complete backport. However, TheLuda was working on the feature/movemaps branch but he seems very busy lately.

[qsa]

It seems to work

...

-Midna

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

Thanks for testing.

[Midna]

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.

Its also caused by offmeshes as the XYZ provided in the crashdump is near the rope in Blades Edge Arena.