Ambal

Faramir118, you still have a choice where you want to hold your mmap objects: those you want to have a unique copy for each map - keep them in Map objects. If you want to share some geometry - place them in TerrainInfo.

Faramir118, to explain you how future map system will be organized in terms of sharing terrain data, lets assume we have a mapId = 12 and we create 3 instances of this map { 1, 2, 3}. Maps are stored using the new key called MapID(mapId, instanceId). To share terrain we use TerrainInfo objects each of which correspond to separate mapId. So ALL instances with mapId = 12 will share the SAME TerrainInfo object to load/unload/query geodata: {12, 1} --| {12, 2} --|-- TerrainInfo(12) <- this object stores all GridMap objects, VMaps and any other info you need for specified {mapId} {12, 3} --| So we have no duplication of geodata for any instances.

This patch is currently "under construction" - I plan to revert some changes done in Map class by returning geometry querying functions like GetHeight() to it. This will make less conflicts with other patches + will not ruin the current way how do we create and unload grids. MapInstanced class is lost forever with this patch - no workarounds for this. No placeholders for map objects which need to be shared across instances - if your code relies on such behavior then it is WRONG. Also note, there is a new class "TerrainInfo" which is created to be a shareholder for ALL types of map geometry information: maps, vmaps and *type here what do you want to share in each grid*. Update: currently I'm busy and will not submit any further changes in code until this weekend :rolleyes:

Hi, everyone Want to share piece of code which reimplements our existing Map system. It was redesigned to meet following goals: 1) Much better core scalability with mtmaps patch - from now on load balancing for instances greatly improved. 2) Reduce complexity - class MapInstanced is removed from sources, maps are sorted by key [mapid - instanceid]. 3) Reduce memory usage - this parameter should improve a bit since we do not create intermediate maps for instances. This also was a result of improved management of GridInfo objects. 4) Code refactoring - ALL geometry obtaining functions from class Map were moved to specialized TerrainInfo class. Maps have a pointer to their own TerrainInfo object and to obtain it either from Map or WorldObject you can use GetTerrain() function. Thank you for reading and testing Here is a link to my repository on github, branch "master": https://github.com/Ambal/mangos

Hi, epozdnyakoff Well, we had to thought about ORM layer loooooooong ago: we have alot of code implemented and tested + some team members go mad when you just talk about using std::auto_ptr<> to prevent memory leaks with unreleased SQL query results in NEW code :huh: Also, we cache alot of records on server startup from DB (player level stats, creature_data etc) which doesn't change and reuse them like DBC data. Also, server stability is the big issue, thats why we rely on transactions (which lag our servers to the death) and try to not keep data in memory for too long... Solid ORM layer is must-have for all serious DB-oriented applications but in MaNGOS, unfortunately, it will take ages to implement Prepared statements is much easier way to gain server speedup but thats not a panacea from questionable software design :confused:

MySQL already has commercial license, only Community Edition is free of charge. Thats why its free edition develops slowly now. So relax and have fun

Guys, the main problem is: who will maintain databases for different DB engines, provide patches etc? I see only few ppl who use PostgreSQL as DB Engine, 99% use MySQL. Don't you think that making support just because ' we want it, but we don't know if we would use it' is pointless?.. P.S. Prepared statements is a way to go for further DB performance tweaking... Thats my 2 cents

All errors aka 'Cannot open ../../dep/tbb/libtbbmalloc.so' and similar should be fixed in [8759]. Thanks to ApoC and ghostpast

Mtmaps patch w/o using thread pool -> epic fail Otherwise your server would die from thread context switches

One more thing: solution like Multi-MaNGOS is needed to deal with crash handling e.g. whole process(!) restart instead of thread restart. P.S. Btw, what about crashdump generation? Would we get them on every crash or not? Cheers.

Nice catch with void Master::_OnSignal(int Signal) hooking BUT: such way of handling crashes is very dangerous, since we don't know what caused crash and simple 'restart thread and free map resources' technique is naive... I just fear that after some crashes we'll end up with infinite thread restarts :confused:

As was said earlier in this topic: just ignore these warnings, there is nothing serious

I've restored VS2010 Beta 2 TBB compilation and usage in [8756]. Have fun if you dare

I suggest you to restore these dlls in Windows/System32 folder! We don't know the reason why they were put in there so it is better to have them rather than get malfunctioning software

It seems that you already have TBB libraries installed in your system as separate install from Intel. Thats why mangosd and realmd work w/o tbb.dll\\tbbmalloc.dll in your mangos folder. BUT: it is better to have these dlls inside your mangos folder since these are the latest versions of Intel TBB libraries!!! Check whether you have \\Program Files\\Intel\\TBB\\2.1(or 2.2)\\ directories on your PC

Want to share a small patch, which should improve stability of those crazy servers, which use mtmaps: http://filebeam.com/d1505fa74f7190eed4f5e44f3b228dcb . It makes BgQueueEvent***::Execute() methods thread-safe. Patch is for rev 8754. WARNING: this patch will not be commited to main repo!!!

Erm, I don't understand what are your trying to say :huh::confused:

Do you mean server startup takes too long now? Also, please, provide your OS info and check if you do not use DEBUG build...

What do you mean 'server reboots in 2 mins'? :confused: Your OS type, please.

Intel Threading Building Blocks memory allocator is implemented in 0.12 branch

Everybody experiencing not-found libraries by mangos executables - check this patch, suggested by ApoC: http://www.pastebin.ca/1645235

Stillhard, these are assertions, failed in function ObjectMgrr::GenerateLowGuid() - something got wrong in WorldObject::SummonVehicle(). This is not related to memory allocator itself. Possibly you have problems with Vehicles patch.

http://paste2.org/p/485485 - this crashdump you send me, NetSky, is very strange! I see that code calls for free() function in operator delete() while it should call for scalable_free() :confused: Have you recompiled your entire binaries including SD2/MaNGOSScript.dlls with TBB support?

Can you upload and PM links to GDB debugs your have to me? Or post callstacks here...

Could you provide a callstack of crashes you have and your system spec?