The suggestion was originally posted on github in issue #1150 - Lag from excessive items in containers.
This is an issue with 77 comments! And tons of suggested solutions and research. The current bounty is at 55$.
My suggestion is regarding the problems when a player logs in and forces the game to load his player items (which can cause lag when exceeding > 100k items).
Ofcourse the easy solution to massive player item containers is capacity limits (Which not everyone wants, and could cause problems with etc house item depot transfers). But even with limits, this should still aleviate uneccesary stress on the CPU when dealing with "container junkies", previous house owners, big players.
Playerloading memory overhead:
Minimal - Classic way, players are loaded into memory on login, and loaded out in logout.
Minimal Optimist - Classic way, but loads player out of memory 1 hour/xx minutes after logout (immediate shutdown/closeserver/server save). Prevents relog lag spam, but may cause one freeze per big player after the timeout.
Active - Loaded into memory on login, loaded out on shutdown.
PreActive - Players who has logged in past xx days are loaded in memory on startup. Loaded out on shutdown. (SQL inserts on save/close servers)
Semi Full / Semi PreActive - find heavy players and load them all on startup
Full - All players are loaded into memory on startup, loaded out on shutdown. (SQL inserts on save/close servers)
Unload = do the insert queries & free up the objects from memory etc...
With the big overhead (active) options, it might be a good idea to also add a "unload on upper RAM size cap". So if tfs.exe exceeds XXGB memory, trigger a Lua globalevent and unload the inactive players from memory to save up RAM.
That way, you can make do with a small box, but if you got 16+GB ram, you can just go all ham on it.
High RAM capable servers arent to rare these days, if your server can easily chug up enough RAM for the
Lag from excessive items in containers [$10] · Issue #1150 · otland/forgottenserver
Sorry, the bug was caused by excessive items in the mail box ... if you can limit it would be great. The player was with some 70 thousand label in the mail box when the player entered the server wa...
github.com
This is an issue with 77 comments! And tons of suggested solutions and research. The current bounty is at 55$.
My suggestion is regarding the problems when a player logs in and forces the game to load his player items (which can cause lag when exceeding > 100k items).
Ofcourse the easy solution to massive player item containers is capacity limits (Which not everyone wants, and could cause problems with etc house item depot transfers). But even with limits, this should still aleviate uneccesary stress on the CPU when dealing with "container junkies", previous house owners, big players.
Playerloading memory overhead:
Minimal - Classic way, players are loaded into memory on login, and loaded out in logout.
Minimal Optimist - Classic way, but loads player out of memory 1 hour/xx minutes after logout (immediate shutdown/closeserver/server save). Prevents relog lag spam, but may cause one freeze per big player after the timeout.
Active - Loaded into memory on login, loaded out on shutdown.
PreActive - Players who has logged in past xx days are loaded in memory on startup. Loaded out on shutdown. (SQL inserts on save/close servers)
Semi Full / Semi PreActive - find heavy players and load them all on startup
Full - All players are loaded into memory on startup, loaded out on shutdown. (SQL inserts on save/close servers)
Unload = do the insert queries & free up the objects from memory etc...
With the big overhead (active) options, it might be a good idea to also add a "unload on upper RAM size cap". So if tfs.exe exceeds XXGB memory, trigger a Lua globalevent and unload the inactive players from memory to save up RAM.
That way, you can make do with a small box, but if you got 16+GB ram, you can just go all ham on it.
High RAM capable servers arent to rare these days, if your server can easily chug up enough RAM for the
Minimal Optimist
configuration, you may save yourself from players who otherwise might cause havoc on your server just to screw around with you.
Last edited: