Memory manager configuration

You can choose a memory management algorithm by setting trackassembly_timermode to mode@life@clear@collect for any table sequentially divided by /. First of all the memory manager is available only in SQL mode, because in LUA mode, all the records are already in the memory and thus, there is no need to manage ( delete ) anything automatically. An example timer setting looks something like this: CQT@1800@1@1/CQT@900@1@1/CQT@600@1@1. Here mode setting is the memory management algorithm to be used ( either CQT or OBJ ) for the table. These are explained below what they do. The life in the cache for the record is how much time in seconds the data will spend sitting in the cache, until it gets deleted to save some memory ( For the example above a half an hour for PIECES, 15 minutes for ADDITIONS and 10 minutes for PHYSPROPERTIES ). The greater the number, the more persistent are the records and fewer queries will be used to retrieve the data. Setting this to 0 will turn off the memory management for the table. The clear setting if different than 0, assigns a nil to the record, marking it for deletion by Lua's garbage collector. The collect setting if different than 0 calls the garbage collector when a record is marked or equal to 0 leaves it to the game's garbage collector. It's pretty much for you to decide because every setting has its pros and cons.

1. CQT - The memory management is called every time a new piece is requested from the cache and not found. Therefore a query should be processed to retrieve it from the database, so as it does at the end it runs a for k, v pairs(Cache) cycle, inspecting which record is old enough ( not used for given amount of time ) to be deleted and marks it for deletion. * Pros: Lighter algorithm. No need for additional memory allocation for timers. Garbage collector ( collect different than 0 ) is called once to process all the obsolete records. * Cons: Uses particular points in time when a record is used/loaded and judges by these how old is it. Records do not get deleted from the cache at the exact moment when the life in the cache runs out. * Used: When there is no need of many timer objects to store in the memory OR they cannot be created due to some reasons not related to the TA tool OR the time precision does not matter when the record gets deleted OR the server will run out of memory when creating too many objects ( timers ).
2. OBJ - It attaches a timer object ( That's why the OBJ xD ) to every record created in the cache with one repetition for given amount of time ( The life ) in seconds. After the time is passed, the record is marked for deletion, and the timer is destroyed. * Pros: Obsolete ( not so frequently used ) records are deleted at the exact given time when processed. The timer is deleted with the record. It uses a running process, rather than points in time to control the memory management. * Cons: Heavier algorithm. Needs additional memory for the timers. Garbage collector ( collect different than 0 ) is called on every timer function call. * Used: When server has enough memory for the timers OR the record has to be deleted at the exact moment the life passes.