variables go away

[quietlyquietly]

Don't need a whole database, just need indexed file read and write.
If you say database, then someone will want to make all variables in the database, which would make everything more complicated and all scripts run slower.
It does not matter if the indexed file read is slow, it is only done at the time the player logs onto the server. You do not have to let the player move until their data has been read.

[Bjørn]

Putting things in a database has a number of advantages, but how fine-grained this should be in terms of storing inventory or quest variables is another question. I think when you start implementing indexed file read and write you're probably better off just using SQLite, in any case.

[Hello=)]

I know few other funny - or weird "TMWA gotchas". Perhaps I should write something similar to "STM32 gotchas" for tmwa, so ppl know some odd or useful things. There're also some not really documented - but useful things as well. Internally I have some (partially incomplete) document on some extras around debug and "server operator guide".

As for RAM: all player accounts for all players are loaded on server start to RAM. This means permanent per player vars are the worst. I.e. now its about 290K records and if each of 290K players get some permanent per player var, worst case would be 290 000 * size of that. Its exagerrated since not all accounts are used - its persimistic worst case estimate, only few vars are really close like TUT_Var and so on.

In case of temp per player var it no longer exists upon player logoff so "working set" is reasonably tiny. So at worst it like what? 150 * size of that? Make it 1000 for bots influx (worst I ever seen is 650 or so). Few orders of magnitude smaller concern. So even if you do not clean few bytes on @tempvars - that will be removed on player logout

As for DBs they have their ups and downs. Their upside are advanced queries and partual load to RAM. But nothing is free lunch, in case of SQL its whole new DSL to learn, new layer of complexity on management side of things and so on. The only reason i'm not expert in more advanced server system, similar to TMWA, but more advanced, known as Herc (Hercules, https://herc.ws - there's in fact port of TMW on that engine) - is fact I'm not a DBA - but herc it needs MySQL instance. Its where dealing with TMWA been just "easiest vector" for me.

As for speed, AFAIK e.g. Herc still holds most of player related thing in "sd" in RAM despite loading player data from SQL. But it still comes with considerations like e.g. proper backups, restore, DB initialization/schema, performance, ...

On side note I managed to store plenty of serialized state as permanent global string vars (map server). Its just... serializing things is relatively easy. I permanently stored string 1 MiB in size. Deserializing ... proven to be not easy: tmwa lacks builtins to do that sanely. This also needs certain care, since its technically possible to interleave with DB structure that way - so in fact I did some "db inhection" that way (breaking part of my local mapreg.txt in process)