qsa

Got some time to comment on some of the post here I can confirm this issue. I'm not sure if its caused by GetContactPoint() or by TargetedMovementGeneratorMedium::Update line 231 - I suspect the later ... Unfortunately, I do not have the time testing it at the moment. But, I'll get to it soon enough. Fully agree on everything said here. We do need test results. Both positive and negative. Unfortunately, we cannot rely on reports from aforementioned servers which do not run our version, so trinity guys are on their own for now. - Good luck dude. Recent updates in Recast has nothing to do with the code we actually use. It is nice to stay up-to-date but currently it provides no benefits. As for implied "navigation bugs" - mind listing those here please? Can you provide some additional info? Those started after some mangos change, or mmap change, or they always were here? Not saying that mmap code is freeze-free, its just can be many factors affecting this. Things like multi-threading in particular. Changing the clime angle to 90deg is nonsense ( even with marking them). This will only cause the mmap contain all surfaces making searches even longer while not actually solving anything. Given examples (movies), show only one thing : retail ensure that if succeeded casting charge, it will get you to the destination. I can grantee, this is not done by having 2nd set of maps, but by appending destination to any generated path. This is what already happening in our code as well, from the last set of changes https://github.com/faramir118/mangos/commit/6cd0ec8f9a37604d1a74c02ba5d08cbf60adb7cc. I haven't had the time to properly test this commit, but feel free reporting the results. The only case, in which I think it can be worth having additional set of mmaps, is for different agent size. Thanks in advance, Cheers.

Sorry, can't check on zero - but it works just fine on master using the default parameters. Maybe someone with zero can extract that tile with debug info and upload or post a screen.

It should be exactly the same thing, I didn't use the "this->" thingy, since it should be implicit as in C++ standard, so I wasn't sure it will compile on *nix systems. Good old cpp and its corner cases. EDIT: pushed the change into repo.

Please try this one : diff --git a/src/game/TargetedMovementGenerator.cpp b/src/game/TargetedMovementGenerator.cpp index cd2d372..45d5048 100644 --- a/src/game/TargetedMovementGenerator.cpp +++ b/src/game/TargetedMovementGenerator.cpp @@ -81,7 +81,7 @@ void TargetedMovementGeneratorMedium<T,D>::_setTargetLocation(T &owner) bool forceDest = false; // allow pets following their master to cheat while generating paths if(owner.GetTypeId() == TYPEID_UNIT && ((Creature*)&owner)->IsPet() - && GetMovementGeneratorType() == FOLLOW_MOTION_TYPE) + && owner.hasUnitState(UNIT_STAT_FOLLOW)) forceDest = true; bool newPathCalculated = true;

I'll post it as soon as possible, currently i'm very busy at work. No rush, as long as it isn't forgotten completely Added. Personally, I find this kind of copyrighting silly, but, its a strange world we live in Tried setting InhabitType to ground and water? That's the reason. Furthermore, I removed to hack that allowed pets who "cannot swim" to enter the water in the first place. This have to be solved somewhere else in the core. Maybe some special case for pets in canSwim function, or overload in pet class. I can't recall if on retail, all pets can swim in the first place. Added faramir's old patch into repo, it should solve this issue. Not sure if we can, or should do something in this case. This sort of things can happen regardless of path generation logic used. Pretty sure that it isn't move map related. The only range limitation we currently have, is around 300yards paths at any given time - this clearly is not this issue. Added patch to allow pets follow their owners even if there's no real path. If by "smart" you mean jumping off the cliffs like on retail, than it is "smarter" now. Same as above. In general, if path cannot be found, creature will evade. Every such place should be handled separately. Just like you said, not related to movemaps. Updated the repository with mentioned above, feel free testing. Cheers.

Pretty strange dump. Some things just don't make sense, like "mapId = 3901870289" which suggest invalid source object, but the strange thing is that it still tries to build the path while it should have failed right there. Can't say much without more crash dumps. Feel free posting those if them repeat. What about system statistics w/out mmaps? Thanks in advance. From my experience, people fell underground mostly in places like arena's ramparts/pillars - LoS covers those. For general terrain (which is not covered by vmaps) the Z value is checked from maps, so this falling doesn't occur there (mostly). Sure, we can use navmesh to implement those, won't be too pretty. We'll have to teach PathInfo couple new tricks, or make different class. Which reminds me, it can be good idea to encapsulate all direct recast calls, so we wont be tied to it directly in code. The only place we use it directly, is in debug commands, if I remember right.

Can anyone can please confirm this? It isn't sound like something related to mmaps, nor I can reproduce it on local. Pet stop following when they fail generating path. This is done to avoid logical loop. Lets assume while pet was failing to move, it would try to come back to its owner, then fail again - loop with no exit point. What happens now, is that, it just stops. Player can click follow/attack again, to try once more. Same problem here, but don't know if is mmaps related ;-) Same problem, same solution - read above, this issue been addressed multiple times. Can you please provide server statistics : CPU/MEM usage w/out mmaps? What mmap revision used? Uptimes ... Things like that. Thanks in advance. Maybe is possible to implement pathfinding use in ConfuseMovementGenerator but not yet implemented. About confused/fleeing movement generators : I don't think we really need pathfinding for those. You see, on those distances, visibility implies reachability. In other words, simple LoS check will do just fine. The reason players fell down while confused, is lack of those checks. Below code (around line 47 ConfusedMovementGenerator.cpp) will do the trick. // check LOS if(!unit.IsWithinLOS(i_waypoints[idx][0], i_waypoints[idx][1], z)) { i_waypoints[idx][0] = idx > 0 ? i_waypoints[idx-1][0] : x; i_waypoints[idx][1] = idx > 0 ? i_waypoints[idx-1][1] : y; } In conclusion, I think adding pathfinding to those generators, will not solve anything better - it will only create more corner cases (taking long path to get near-by point). Nor it will simplify the code, therefore, it is not necessary. Cheers.

I advice you to try other branch. Maybe something gone missing at porting. If the issue persist, please provide additional information - location, etc. I know for a fact that flying creatures do work just fine on my test machine. I'm sure other's can confirm this. Lich king has different issue - his thrown is GO, the actual ground is far below. So it can cause issues. I advice on disabling pathfinding for him, from his script.

Depends how often you get those, I can imagine few cases when it is "expected". If it is often, this may indicate some problem. That number is GUID of creature that encountered it, so it vary from system to another.

Now i am upgrading my servers to 48 GB DDR3 ECC in order to continue tests with high populated and mtmaps enviroment realms. Stay tuned! New versions don't need that kind of memory sizes, but it surely cannot hurt. I'm looking forward for results, thanks.

It cannot hurt us. Maybe we'll get it reviwed and some ideas for improvement. But prior, I'de love to get feedback about some of our latest changes. Those thread issues in particular. Cheers.

I think http://pastie.org/1606946 is more than enough. Hrm, branch deleted. Shame, it was just the same idea I had Wonder what went wrong

This sort of thing happens when you have .mmap file for given map, but you stand where there's no tile loaded, maybe no .mmtile for that map? I think I see the problem. Extractor errors on those maps. I think there its from my cleanup back in the day Oh, well - good that this issue was found. I'll push something shortly. Thanks for reporting. You will have to extract aforementioned maps ( on any maps with .mmap files but no .mmtile files ). Cheers.

yes, but the reason there's no npc support on transports, is that server virtually oblivious to their existence. There's no system to translate map coordinates to moving transport coord set. Having it implemented shouldn't be that hard ...

Below something that's hopefully solve (atleast some, if not all) issues with offmesh connections. http://pastie.org/1590468 Please do test. About all those compile issues : sorry, but I can't see a single one, related to our code. Patches are always welcome. If you have issues on your platform compiling our CLEAN repository, please do let us know. Including platform description and solution. About my previous patch, the one with threading issues. I'm going to assume it is sparkling ... so, I'm going to commit it. Transports aren't supported at all in mmaps. At best, you can disable pathfinding to players where Player::GetTransport() != NULL Since mangos do not support NPC on transports by default, we have no way doing it either, so, with or without mmaps you wont have it working. What I'm saying here, is that disabling mmaps on transports wont solve your problem. I think its been discussed few times already.

Here we go, http://pastie.org/1576286 Test patch to solve those threading issues. Do not forget to remove that code from post #916. Thanks in advance for testing and reporting results. PS: Is it just me, or TerrainInfo never unloaded on runtime? Tiles unloaded just fine, but not the TerrainInfo itself. I haven't seen Map::~Map() called on runtime either, while I do have Instance.UnloadDelay set to just few minutes.

Movement meshes are for pretty long time now loaded/unloaded from terrain manager, just like VMAPs. They are not the issue. The issue is dtNavMeshQuery - the part that does the calculations on top of those meshes. It is not thread safe on itself. So, we have to have one of those per instance and NOT per map. We "cannot" have it per path calculation either, since it is pretty heavy on memory.

Unfortunately, this is not a memory leak, it is the actual memory usage under this model You see, what used to happen, that all creatures on same map used to share dtNavMeshQuery (the engine that does all the calculation). What happens now, is that every path calculation has its own dtNavMeshQuery. Just like we used to have while back. Well, as you guessed, it is pretty expensive, memory wise. What it made me realize, is that I was looking for the problem in wrong place. The actual issue is thread safety. As "simple" as that. Right now, we have single dtNavMeshQuery per map. So, what happens, is that two different instances from two different threads of that map use it simultaneously, that's why we get those results and consequentially, crashes. Find the problem, is about 70% of the work, now its just a matter of fixing it. I'll allocate query for every instance. Going to change our loading/unloading model a little bit, we'll have to hook somewhere in Map class Please do correct me if I'm wrong with the logic here. From what I can tell, every instance run in thread of its own right now, not every map. If, that is not the case, spare me some time digging into instance code. I merged the latest. Unfortunately, I do not have *nix system with mangos at the moment, so, someone else will have to make cmake files, or wait till I get to setting one up again, which wont be in any immediate future. (thanks in advance) Cheers people.

Different crash, but I guess they caused by similar issue. Can you please try this : http://pastie.org/1568503 - thanks in advance. PS: how often does it crash? You are half way there sometimes, when you have a pet and pet follows you to the pillar, or when pet attacks target on pillar Thanks, found a way to crash it. Now only left to find a way to solve it, or atleast understand why it does. mehh, all those new issues coming from pretty deep in recast code

Good to know someone working on that issue. In general, I don't think we should have support for dynamic objects as pre-requirement to "first stage". You have to compile recastDemo from our repository, then copy the binary to folder with SDL.dll, DroidSans.ttf - you can find those somewhere inside recastdemo folder. Then, you should extract mmaps with their debug info. You have two folders now, one named "mmaps" and another "meshes", copy them into same folder as recast binary. There's no need renaming anything. Thats about it, if the format is proper, recastDemo will have no issues opening extracted maps.

Why don't you push it. One bug less. It is their default movement. Mmaps will not work with gameobjects (forge in ironforge) - same reason why LoS don't work. We cannot implement it till LoS has it working. About that guard flying around : I guess it uses waypoints, if they are set wrongly (he have waypoint to unreachable location), you can get some strange effects. See post #891, those spacial places have to be fixed manually. Dock in bootybay, pillars in blade's edge arena, maybe some otehrs. In any case, there's a mechanics that allow solving those. I think we need to list all known issues first. Then, get it tested on major sized server for some time and get proper feedback. Only then we can start talking about moving to review. In any case, it can be nice to get some remarks about the general design from one of the devs. Make sure the maps extracted by the ported extractor are proper. Open them in our recast demo and see if you get what you expect there. Afterwards, you have to be sure you ported the core part properly. Keep in mind, that the current implementation of map loading/unloading system tied to terrain manager code, which in tern has to be backported first. Alternatively, you can use our old scheme, the one we used before terrain manager, but I think it is easier and safer to backport.

Sorry for digging this corpse, but, is it still relevant? Anyone test it?

You can either common parent class if you use inheritance, which isn't that trivial in c++. You see, since c++ isn't real level 3 OO language, it do not support things like common inheritance root. Like object in java. Actually, java used to store objects in all its datastores before it had templating. back to c++ ... The real problem with storing void*, is that you don't know what type they are. One way it is "solved" in c++, is by having wrapper class, that holds void* and "type" variable. You store wrapper classes in your collection. When you pull it from it, you check the type, and upcast accordingly. Really easy to implement, or you can just use ready one, just like darkstalker suggested.

I finally crawl from under the rock I was stuck for a while and had the time to play around with things. What came out of it, was the ability of create off mesh connection. In other words, the ability to patch mmaps generated by the extractor. Pushed in to the repo today. Why? That's the simple: we cannot cover all possible cases in generic code, therefore, we have to have mechanism to allow exceptions. How? Simply by providing input text file to the generator. You can see the example under offmesh_example.txt. Some more info can be found in readme. Basically you provide map, grid, start and finish locations and it will create link between those points. The pro's : Things like this (for those who remember) http://oi53.tinypic.com/2qipzeu.jpg are history. The con's : It have to be done manually (no shit), and it will work only on same tile (aka: you cannot link locations on different tiles - not a biggie, but still worth mentioning). The format must be exact! The "parser" is pretty weak, so if you don't follow the exact input format, it wont work. So, don't forget things like spaces, etc. In offmesh_example.txt I gave the example of booty bay dock, feel free posting here your entries! Please include screenshots if possible. It needs some testing, since I didn't had too much time testing it Cheers people. PS: been checking some posts here, I "missed": 1. faramir118: cheers for backporting. 2. about charge: I think the only thing that's missing at the moment is the delayed stun - beside that we have it working exactly as buggy as on retail (talking about charging from one side of the map to another).

This is pretty much nonsense on any modern OS (since VAXes) thanks to virtual memory. God knows what really goes on in windows universe I never saw allocator throwing anything on normal usage. But, then again, I never run anything that takes over 1Giga memory on windows either. Well sorry exchange "RAM" by "Memory", but it's not nonsense. Virtual memory doesn't help with the fact that you eventually run out of contiguous 32bit addresses to allocate a memory chunk, virtual or not. Your post made me think about it once again. Thanks. OS takes the upper quoter of our address space, which leaves us with around 3giga. Lets assume all mmaps are loaded and never unloading, so we take another 2.5giga. Add all other things that have to be loaded, maps, vmaps, add some fragmentation and we can get pretty grim picture. We can have problem with continues address space. I can't say we can solve it right now from our side. Upgrade to x64 architecture going to handle it tho. Don't know if we can significantly lower memory usage right now. Using bigger world metrics will do the trick, but it will lower the quality of our meshes. But thinking about it once more, if you do unload unused grids there's no freaking way you can fill the entire 2.5g.