qsa

This error is there for a very good reason ... Just take a wild guess what it means. TIP: you have to rebuild your maps fresh.

Sure, mind me putting something "special" inside?

Another memory leak... I pushed something interesting. Killing one more piggy. Hehe, now you'll have to test all the crashes introduced with 252 switch

Merged and pushed both new Mangos and new Recast (r252). Somewhat tested, but, as always, there may be more than enough well hidden problems. Next stage is converting for full dtPolyRef-64bit support.

Some of them fixed ... you cant get it all at once Can you post your partial server log? What I'm really looking for, is errors that might have been generated by mmap code. PS: doubt 2nd crash has anything to do with mmap code.

no, not exactly. But reading your post made me understand we will not avoid widening dtPolyRef. The thing is that every polygon in same navmesh must have unique ID. Since the rough number of polygons per map do not change, it is around ~2^30. So, splitting those to different tiles wont help us. It will only solve the long poly issue. We also need pretty big salt to minimize the chance for wrongly selecting polys. EDIT: actually, we don't use the feature salt was created for at all, for our loading/unloading. Maybe we can cut it out giving us 4 more bits. We can always make dtPolyRef 64bit. I can do the nessesery changes, if you provide me with diff with all our changes from clean recast. http://code.google.com/p/recastnavigation/issues/detail?id=102 EDIT: we need to think first, if we need more than 32bits for dtPolyRef. Cutting salt to 0 or 1bit, will hopefully give some room for polygon numbers we need.

I think the real solution should be doing something like: Define : map, cell, tile, polygon. While : map - ingame map ( just like we have right now ) cell - subregion of the map ( what is called tile now ) tile - subregion of cell polygon - same as now. When gridXY is loaded, we load cell, with all its tiles. Instead of making gridXY=single tile. This will solve both overflows due too too many polygons per tile and too many tiles per region and the problem of long triangular polygons that screw some of our paths. Problems: extra overhead - since tiles have their own data, pretty much neglectable, since the real number of polygons will not change, but still ... pathfinding between neighboring cells. detour do not support this ( as far as I know). We will have to change findPath/findStraghtpath algorithms to support this. Atleast we'll have to make them return the status of last poly in path. We have to know if location is out of cell. Then we can calculate two (or more) subpuths and paste them together. This (*) is the real problem. Those are just some thoughts on the subject.

faramir118 : tell me, are you sure assigning those bits to tiles, don't hurt polygons? I'm asking, since .. well, just look at those crash dumps. pathPolys = {4213792, 4214256, 4214257, 4214227, 1967148500, 4213273, 4213280, 4212993, 4205097, 4205099, 4205095, 39, 0, 20, 4204946, 2485034720, 2, 2485033640, 1, 0, 141375826, 173306232, 4, 2485037879, 2485037879, 2941076064, 83541108, 2485033544, 83150438, 2485212808, 2485037879, 2485037879, 4, 484, 0, 83, 15601689, 2485034828, 0, 2485037879, 1, 0, 15, .... All those polygon references are overflows. It even dies at SIGFPE(arithmetic exception). Looks like something is affected, and not in a good way. Giving 12bit to the tiles making us have only 10 bits for the poly. Limiting the number of polys per time to 1024, which obviously, we have more, much more.

Can you give me .go location to test this issue? on preferably static NPC. Actually, this is something already exists, in a way. Different map's extraction processes independent one from another. keep in mind that you can explicitly input the maps Ids you want to extract. So, no actual threading is needed. What I do when extracting all maps, is usually running extractor at 3-4 copies. One for every major continent and one for the rest. You can make some really nice bash script to extract maps loading them between the instances. Something that gets the # of CPUs and then loads the extraction equally. Feel free making it. I'm sure people will appreciate it. Thats about the extractor, about the core : you cant really load the balance properly while mangos runs all maps on the same thread. When it wont, we wont have to spread anything either. PS: thank you all guys for testing and reporting. Above all, remember - this is work in progress. PSS: Wojta/KiriX do you have those crashes with newly extracted maps?

You beat me into pushing it But i think we can do with 1024 (or 2048) tiles there and save 2 more bits for polys. Since bigest maps have just under 1k tiles. I also pushed something to hopefully prevent some memory leaks. Even tho, this case, most likely was caused by this tile number limit.

m_maxTiles is loaded directly from MAP_ID.mmap files, it is put there by extractor in MapBuilder::buildNavMesh(). It limits the maximal number of tiles per map. So, if lets say, in map 530 there are 1024 tiles total, it should be 1024. You saying it is not loaded or stored/calculated properly?

no. Maybe i can test without TBB under valgrind if you teach me how to do it and this will work without additional lags at live server Well, dropping TBB under FC wont affect the performance too much. But running under valgrind MOST defiantly will But if you run something under 50 testers, it will be reasonable. I'll make a little guide here, maybe someone will find it useful. 1) install valgrind package. 2) disable TBB. You can do it by adding "#define USE_STANDARD_MALLOC" at top of src\\framework\\Policies\\MemoryManagement.cpp or just commenting the entire file. The reason for this, is that TBB takes over memory management so the valgrind's sandbox can't hook properly. EDIT: obviously you have to recompile. 3) start mangosd under valgrind. "screen -A -m -d -L -S worldserver valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes $srv_dir/bin/mangos-worldd" This assumes you are using screen utility. The output will be written into screen.X file (usually located in your home dir, or mangos dir) You can also run it directly by "valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes $srv_dir/bin/mangos-worldd > output.txt" 4) Start the server -> do staff - > shutdown properly -> see the results. The logs are more or less self explainable. You can always look for detailed explanation at google. 5) Enjoy EDIT: you can also use it as profiling tool - can be pretty nice to get those logs too. To see the frequency of path calls and their relative exec times over long time periods. "valgrind --tool=callgrind $srv_dir/bin/mangos-worldd"

We haven't made any changes that can affect memory usage between 10683 and 10690. Actually the svn is at 10677, but I don't think mangos did anything too extreme too. So if there's actual leak in our code, its much older. I tried to run our latest under profiler (purify), and there were no definite memory leaks found (or any at all related to our code). If anyone can run under valgrind with TBB disabled! (important), and actually get leak trace, I'll be able to fix it. But prior to that, I cannot even confirm its there PS: you have grid unloading disabled, right? try enabling it. Maybe your memory actually just fills up. PSS: anyone have similar issues?

You totally made it sound like something else Anyhow, those flags (UNIT_FLAG_PVP_ATTACKABLE and UNIT_FLAG_PVP) checked client side only. Server only sets them. By the looks of it, UnitFlags enum needs some updating feel free to test those flags and list the results.

Since it is not set ... A good place to start would be : http://en.wikipedia.org/wiki/Mask_%28computing%29 or http://www.gordano.com/kb.htm?q=966

You have to build and use AD extractor from our source, then extracting maps/mmaps.

Any chance you know how much memory used while it crashed? since it appears that malloc() failed to allocate additional memory. Again, it is memory allocation error. I have no idea why this can happen. Either there are memory leaks somewhere, or your system just running out of memory.

Beside "Visibility Optimizations" idea, the other things were already implemented in my first patch. He said that he implements suffix optimization in crowd tool. I'll check his way when I get back home, but it can't be too different. About "Visibility Optimizations" idea : he doesn't implement it at all. While it sounds good, the cost of checking if we can cut the corners may cost more than we are ready to pay for paths with few less corners. It is something we have to implement, then test - only then we can see the effects. But in general I don't think we should mind paths with couple extra corners. Pretty much the same. But identifying those problems ( if any ) can be tricky. Main question is : do we really have amy related problems? What I did notice while checking the svn, is that there were alot of x64 related changes. Need to check the exact nature of those changes. We may need to update ... Which brings me to next question : do we have changes made into recast package beside changes in recastDemo? I sure hope not.

While I haven't test this particular case, I'm pretty sure it will be fine. Since there's no "water only" path between the pools. So it will work just like "land only" trying to pass a river -> evading. You asking since you there's a bug somewhere, or? EDIT: actually, when I think about it little bit more, there can be some problematic corner cases. Like when both are in deep water, too far from any polygons. But i think in general it should be pretty much reasonable for now. By the way, same applies to flying creatures. There are cases when flying creatures will fly directly into the walls. You really have to work hard for this (almost impossible to make while normally playing), but its still doable. There is maximum triangle edge parameter. Wont it work playing with this value a little bit? I mean, it does make a difference while you generate those under recastDemo. There's also things like the max. number of edges per poly which can be useful. KAPATEJIb / Wojta : thank you very much guys for testing. PS: it seems that result vary a little bit from one system to another. Maybe we have x64 compatibility issue? For example I cannot confirm a fair portion of those errors on my test system 32b.

Pushed some changes. Including most basic cases for underwater movement. Should be mostly fine. Few notes: * Succubus dragging itself on the bottom of lakes is not my problem, it "can't swim" from DB (inhabit type). * While in water you can shoot creatures who cannot swim - they will evade immediately. It is not a bug. In ".go X Y Z map ori" format please movies will do just fine too. GO's are not supported, and will not be until LoS support those. Don't worry, it will be ready by year 2015.

I still think we should use agent size of about ~0.4. Its the smallest model size. So it will make wall-walking less common of standard models, while small doors still will be walkable. I mean, opening under 1y shouldn't be walkable at all. Actually, when I think about it, maybe we can solve it with single mesh. Maybe I can modify smooth path algorithm to steer around corners at given range. 1) "underwater paths" : At the moment npc are stuck to the surface. Maybe can be handled like flying case. 2) Doing some research about map generating parameters. Maybe giving different parameters for different maps. There are things like circular stairs that are generated really poorly at the moment. 3) Properly test everything.

See post #540, its same source, should be solved. It's never stuck (as long as there's no mesh problems), it comes as close as it can to the owner. When owner moves, it tries again. It has nothing to to with maximum path length, since you can generate those cases for any size. I think it works exactly as it should be, since pets cannot jump like their owners Yes, it is known issue. Currently all algorithms provided by lib we use assume uniform unit size. You input it when the maps are generated (aka : agentRadius ). Maybe we can play with this value a little bit, since right now its set to really low number, making most models "scratching" the walls as they move by. But in general, there's no simple way solving it for dynamic model size. Using something like findDistanceToWall() while calculating the path is just out of question performance wise. The only "relatively simple" solution I can imagine right now, is generating "multiple meshes" with different agent sizes, then selecting proper one dynamically. But that something for the future ... just like dynamic meshes for GO etc Tested on my laptop (win), worked just fine, I'll test it on *nix later on... Well, you could always just remove the maps you don't like from mmap folder, it works just like disabling them. Can't hurt having the option in cofig either.

Thank you very much. Really solid crash log for little sneaky crash. Not very common one, but still can happen, no wonder we didn't get it on low population. Hopefully fixed in https://github.com/faramir118/mangos/commit/fa96109a5cb8f006642e44b0c4fb767f7a087bd3 Keep those coming ... Checked map 603, and it looks really strange, good to know that faramir118 is on it Maybe extracting that specific map with different cell size can solve it, since borders tend to get screwed. So happens cells are connected just in the middle of the room. But sure, proper solution can be even better

Just noticed we have different problem implementing this one. Since paths right now calculated from WorldObject to caller, the path mask used is Object's mask. There's no way currently passing it. We can make something ugly, like passing mask into path constructor, but thats just overkill. The other "no so pretty" solution can be temporary setting Objects inhabit type to whatever we selected, so the path generated will be of the type we want. The 3rd option, is making separate class, that inherits from PathInfo, that will provide much more debug options. But again, this may be just overkill. PS: merged and pushed latest mangos.

I can add so you could pass filter mask, but it wont be too intuitive. Maybe we can do something like "ground water magma" -> "true true false" type of shift. User will input this array, or ... bitmask. Not sure which option is the best. For basic testing you can always hardcode some value there ... Sidenote : any remarks against updating to latest mangos? if not, I'll do it tomorrow. Unfortunately we rather not support anything beside provided code in the repository. There's a quote by Mark Twain to fit here perfectly ... Polite answer wont hurt you.