why not add mmaps system?

2 (edited by desteny 2014-08-18 16:09:02)

Hey, if you are interested in MMAPS or the new oregoncore team wants to backport something based on a older oregoncore rev, feel free to use my code.

#LINK DELETED#

its free and i shared it already on old oregoncore forum, and i saw that you guys are continuing to develop oregoncore, so i hopefully can help you a bit.

this work was done by the old oregoncore team (certain members in 2011 based on OC rev 1389) later OC revs where broken by a commit of someone else (dont even know who)

major credits are going to:
*faramir118, QSA and many more from mangos
*reno from OC Forum for starting this project and backport the major base
*midna for more backporting and major fixes for OC for AT
*desteny for more fixes, updates from TC2 and later mangos revisions

NOTE: this code was almost the same code as multiple persons where running at 2011 on public servers, including the AT (Arena Tournament) server! it includes not only mmaps but also several other fixes but NO separate branch for it.
we tried to merge it with a later OC rev 1500+ but it was not stable!

NOTE2: MMAPS are working at 98% some little ajustments could be needed

NOTE3: this is no coustom repository and contans no custom / fun stuff, (no AT or server specific stuff or fixes / changes)
all code is blizzlike and based on OC or 2011 whit all problems / bugs / missing features.

If youre intrested, good look and have fun, else ignore this

best regards
desteny

Hey! Cheers for the post desteny.

I've had some issues backporting this in the past. I got it all sorted but had a few major issues regarding NPCs and world objects such as a cart, or a tree.

Were those issues present in your version or did they stem from something else?

As for the OP, This is something we really want to do. For now it's one of the only things keeping OregonCore behind in being a popular core choice for the 2.4.3 servers.

We've already tried reno's oregon-mmaps but they were borken, but yours are not!

Well there are some glitches but nothing hard to fix:
You can see that the creature doesn't check Z distance so it thinks it arrived but it hasn't. This won't be hard to fix.
We'll try our best to bring you mmaps with the highest quality possible in a short time.

Below you can see a snapshot video from testing how they work:

[video]https://vimeo.com/101631258[/video]

"A little hard-work never killed anyone important." - Abe

hi again, sorry for the delay, was off for a week.

I've had some issues backporting this in the past. I got it all sorted but had a few major issues regarding NPCs and world objects such as a cart, or a tree.

Were those issues present in your version or did they stem from something else?

This MMAP implementation is a lot better then all others ever done for OC, it has no mayor issue for PVP usage, for PVE we had no realy usefull test server, but it should not have mayor issues (except the possibility to trap certain bosses caused unaccessible areas or big models like gruul)

for this reason there is a flag to disable pathfinding for certain npcs. (i don't know if i have done it on this repo but as short workaround i disabled pathfinding for all boss creatures)

the issue with trees or some terrain is caused by some vmaps problem (even existing on OC since lower revs without mmaps) (npc stuck behind a tree for example in terokkar on the lake near shattrath)

a other bug is that GameObjects are not involved in pathfinding, but this even not work on mangos or other cores (except TC2, as far as i know) this is cause OC don't have DynLOS (dynamic line of sight)

first step for this is backporting vmaps4 but then you must combine mmaps with dynlos to repath on a collision. (there where around some backportings on OC but i never have done some work on this job... but maybe i can find the repo)
(but its far from being complete)

i suggest to use this system without vmaps4 cause in tbc there are not much gameplay relevant GO's



@zaffy: nice, already backported and tested... good job!
there are some glitches except with the bounding radius / distance / position to the target. the z-index bug is caused on the same problem, the npc calculates the 2d distance to the target and below the wall it reach the bounding radius, but in this case there must be used the 3d distance and not to the bounding radius / contact point or target position of the movement, but to the center of the target it self!

should not be hard to fix (like you sayed)

good luck wink

Hey desteny,

Thanks for the reply. As for the vmaps, I pushed a commit recently that should solve any issues with trees etc.

We're working on updating recast currently, and hoping to go from there.

btw about the npc bugging... on retail this was solved with evade and reset system, so if the npc cannot reach you, it will wait a few seconds and then return home We're planning on doing the same.

"A little hard-work never killed anyone important." - Abe

Hi, i see you have done some great work, and you are fixing the things "the right way" like implementing npc evade like on blizz.

for this reason you maybe find usefull even to implement vmaps4 (dynLos), even if there are not much cases where GO's are used in TBC. (Most of all Doors)

feel free to take a look at this repo (https://bitbucket.org/desteny/oregoncor … ommits/all)
the credits are not going to me, i have only imported a patch from a other OC dev long time ago, but it is not tested and probably i don't know if it works or not.

but it maybe gives you a idea of how it could work.
Note: TC2 has implemented DynLos long time ago (maybe you can find missing things there, as far as i know mangos never implemented dynlos)

Hey desteny, it wasn't so hard with pre-implemented stuff... just some minor alterments and bug fixing.

DynLOS is very cool but I don't his it's something urgent, now. Will be surely implemented in future, though. I would like also to link DynLOS with Detour so we can have dynamic pathfinding too.

BTW Don't you want to start developing OC once again ?

"A little hard-work never killed anyone important." - Abe

I think we were talking about using Raycast instead, or maybe I'm getting mixed up with something ;D

DynLos is not urgent, from my point of view, for TBC cause there are not much cases where GO's realy matter.
For this reason i have not proceded to work on this, and focused on other more important problems.

the only annoying part on missing dynlos are doors and the possibility to cheat with it (not direct related to your bug with pass doors at login, or pets or npc pulls on doors (with AOE ecc.))

but for this cases i had added some workarounds to a other core long time ago... maybe you can use this as a input, but keep in mind it's not a proper solution (dynlos would be the proper solution):

1: Door logging
- i have added a flag to the player 'JustLoggedIn' or how ever, this would be set to true at the begin of the login procedure
- this flag is checked in the movementhandler (near the anticheat code, if true use the position reset like the anticheat does
- this flag would be updated to false if the player has completely loaded (don't ask where this was) + added a small delay like 100ms.

this prevents walk doors on login (more hacky way is just to add a interval in config for player to stuck (like 3-4 sec))

2: for doors i implemented a kind of dynlos at runtime, a map who will be populated if a door spawns, and switch cell state if door opens / closes / despawns

this can be integrated in the actual los check methods and with this you can fix nearly all dynlos issues without vmaps4
its not much slower but its a bit more tricky to implement.

"BTW Don't you want to start developing OC once again ?"
thanks for the invite, but ATM no, the summer is nice and i don't want to miss it wink
but maybe in later autumn, maybe, but i'm not shure.


BTW: one question, trinity has moved from ACE to BOOST and C++11, are you thinking about to make this changes as well?
cause on trininty it was a big stability plus after this changes big_smile

We talked about boost. Not C++11 yet.

I've seen another method for handling door exploits (the one where you login and move forward) but yours seems like a pretty nifty work around.

I think because we're based on Trinity 2.4.3 we should stick to our roots and follow their standard in a lot of things but in the same time keep our essence as a separate project, which is really tough to do considering we're catching up on almost 3 years of nothing done to core.

Nice work.... Movements Maps is Good i think... smile smile