faramir118

SpeedZ has to be vertical velocity - you can use arbitrarily large numbers, like 1000f, and the mob flies upwards very quickly.

I ignored that they are linked separately... oops. Since ACE uses unmodified new, qsa is correct - it probably isn't tbb. I reverted the change, since we need more information about this leak. Personally, I'm unable to replicate it.

From what I've looked at... For g3dlite, only G3D::Array, G3D::Table, and G3D::Data classes use a non-standard memory manager, but I don't think we use those in mangos. Similarly, ACE seems to do all of its allocations with ACE_New_Allocator::malloc (by default), which uses operator new, which is defined in MemoryManager.cpp to use scalable_malloc Obviously, I can't be 100% sure. But since you asked, and I did all this digging, I found out we should just make our dtCustomAlloc use operator new.

gcc: autoconf adds a compiler flag when you use --with-std-malloc yes vc: You need the define on both the framework project and game project If you put the define in the src, it needs to be something that is included by MemoryManagement.cpp, MoveMap.h, and World.cpp (so that you don't get linking errors, or have detour using scalable_malloc and mangos using malloc). I defer to the devs on this one...

Hopefully fixed in 26c0b1795 BUT: I'm unsure of how to handle case where USE_STANDARD_MALLOC is defined (mainly because I'm not sure where USE_STANDARD_MALLOC is expected to be defined - compiler setting for project/library, header, ?) Would this work? #ifndef USE_STANDARD_MALLOC ///- Initialize detour memory management dtAllocSetCustom(dtCustomAlloc, dtCustomFree); #endif

Not all groups of monsters are linked on retail, only some of them. In some cases, if your group dies before you kill all linked enemies, the ones you did kill will respawn.

Updated to [10727], some compatibility changes applied in 7b836bc57

As long as we have proper destructors, we can print out all remaining non-freed pointers, and where they were allocated from, right before mangos exits (during normal shutdown).

Can't we use a technique like the one I deleted here? It would take some code refactoring... replacing calls to dtAlloc and dtFree, but it shouldn't impact performance like Valgrind does.

proposed changes to mmtile format: https://gist.github.com/674959 Changes: writing multiple dtTiles to one file, and associate them with one mangos map tile. mmap generator version stored in file more complicated loading/unloading and tracking of loaded tiles Needs some revision, and will probably benefit from a standalone class to simplify reading and book-keeping tasks.

That's what I understood from reading the patch It semantically enforces what vmaps already do by loading data only for the base map (instanceId 0). Now, hypothetically say that there is a mmap which has some dynamic state - a door which blocks a path when closed. The state of the door on map{12, 1} should be independent of the state of the door on map{12, 2}. Where does the mmap data belong? Not in TerrainInfo, because that would force all instances to share state.

Make sure the method above that is closed with }

The ends of some lines got cut off - fix the ones that end in $ You'll have to look at the sources.

My point is dynamic terrain, and where that information could be stored. The [Not Yet Implemented] features like collision and LoS for doors, ice blocks, platforms that fall, etc should all be handled per instanceId. Should that be stored in the Map class? edit: I don't mean to hijack the thread with implementation details of other features. I just wondered if these things are related, or could be made easier by this change.

If GO spawns are added to vmap, they should be spawned per instance, not per map. Not a problem now, but maybe in the future. There are conflicts, but it wouldn't be to hard to merge them.

http://getmangos.eu/wiki/Main_Page Look in the External Links section PS: If you are too lazy to look for these things yourself, just give up now.

Whatever the case with salt, we could cheat and just never unload tiles until the map dtor is called :rolleyes: https://github.com/faramir118/recastnavigation There are two branches master is a clone of SVN mangos is the version we are on, with our changes (missing some things, like makefiles) I had planned to do a complete merge to the newest version. A simple fastforward will break a lot generator and mangos code - better to do small merges and update our code as we go. Or you can merge just r235, r240, and r242 to start. These will not fix it completely though - for example, 1) dtNavMesh::init still assumes 32bit and 2) we are advised to use a 64bit hash I know http://groups.google.com/group/recastnavigation/browse_thread/thread/c52d951a4a00f90a Mikko's suggestion, monotone regions, aren't possible with our huge tiles. But since we're going to use smaller tiles soon anyway...

Are you saying that each mangos tile should be a separate navmesh? That is a very large hurdle... I vote no! (navmesh-per-tile is how the project started out, so returning to that would be going backwards ) Fortunately, we can increase the number of tiles without making things more difficult for ourselves. We just have to make sure dtPolyRef can address all possible polygons. e33d285 solved this problem for now. With more tiles, we may need dtPolyRef to be a wider type - more recent versions of recastnavigation make this change easier. What I was thinking about... mangos (and wow in general): map -> 1..64x64 tiles -> 8x8 cells detour: navmesh -> 1..64x64 mmtile -> 8x8 dtTile (-> 1..1024 polygon) Our mmtile would become a logical grouping of 8x8 dtTiles. This means a theoretical maximum of 262144 dtTiles, which would require 18 bits. After giving 4 bits to salt, that leaves 10 bits for polygons. It should work without widening dtPolyRef, but the only way to know for certain is to make the changes and see if any dtTile's polycount is over 1024. (again, these numbers aren't fixed - they depend on the actual number of tiles in the map) Of course, we can choose any arbitrary number of dtTiles per mangos tile. The system is rather flexible. It might even work around some outstanding bugs, like the spiral stairways.

Do you have a crash dump, or at least the location of your player? What commit version are you running?

Also pushed some code cleanup, and changes to the mmap GM commands. Read commit notes for details.

Finally found a spot with an overflowed polygon id: .go -10982.000000 -1965.010010 39.733799 0 2.290960 Doesn't crash, just overflows and travels to the wrong polygon. Tested by summoning a vanity pet. I fixed it, going to push changes. You will need to re-run generator to fix the bits (with this patch again.)

We need minimum 10 bits for tile, but in theory need 12 We need at least 14 for the polys, maybe more. Of the tiles I currently have built, the largest poly count is over 10000 (5325235.mmtile) Salt is 10 bits (checked in dtNavMesh::init, implicitly set in MapBuilder::buildNavMesh, line 635). 10 + 14 + 10 > 32 We need to reduce the size of salt. Short term fix. Then we can work on updating to a more recent version of recast, so we can take advantage of the wider-typed dtPolyRef. edit: this math isn't 100% sound, since 532 only has a few tiles and thus only needs 4 bits for tile id. but we still have cases where large maps, like 0 or 1, have poly counts over 4096 on single tiles.

@ KAPATEJIb Can you apply this patch, so that we can see why it's not loading those files?

realmd and mangosd both have startup errors because of libeay32.dll using the binary from http://gnuwin32.sourceforge.net/packages/openssl.htm fixed it.

smooth path sometimes breaks: picture straight path doesn't have this problem. some creatures (succubus pets south of booty bay) travel slower and slower as they advance along the path. Almost like they try to recalculate path, but it gets added onto the end of the previous path.