itslewiswatson
commented
9 years ago https://github.com/nokizorque/mta-sql-caching
I created a basic system that achieves just this. I haven't tested it, nor do I know how to properly implement it with DayZ (yet to learn the resource web).
It may sound like that would be a lot of (unnecessary?) work
Considering how poor the usage of element data is (not trying to crap on hard work), I beg to differ. Element data uses a lot of bandwidth as it syncs to every client, as well as the server. It should be use sparingly. Though element data is quite easy going on CPU usage and does not have much impact on RAM. Synced tables allow you to control where they are synced, so you're able to manage bandwidth (see latent events). However, they're more tasking on the CPU and large tables tend to eat away at RAM. I would recommend moving towards more use of synced tables. I personally use them a lot and find them to be more structured and flexible than element data.
(table.insert, table.remove, possibly table.merge, ...)
I doubt you would be able to create an efficient system using those functions. A more efficient way of doing so would be using keys and values in tables.
Of course, said tables will be clientsided and for the localPlayer only, to ensure no tables are being mixed up.
That is why tables in Lua are not like Python lists, but more so like dictionaries. Each entry has a key and a value. That's why you can store the player's unique ID/account element/account name followed by a nested table of their data in one large table, and be able to access data quickly and with ease. You could also store all active player's data in one large server-sided table to minimize bandwidth usage. Though, the trade off would come with RAM usage. Especially if the server has a large concurrent player count.
I was wondering whether or not we could, somehow, use a mixture of tables and SQL instead of setElementData(). It may sound like that would be a lot of (unnecessary?) work, but since setElementData() is one of the main issues of MTA DayZ (and the strain it puts on both server and clients), it begs the question what alternatives we have.
My idea is as follows: As long as the player is online and playing, everything he does will be done via tables (table.insert, table.remove, possibly table.merge, ...). As soon as he logs out, everything in the tables will be stored in the SQL database (using either dbPoll/dbQuery/dbExec or executeSQLQuery). Once said player joins back, everything in the database will be written back to the tables. Of course, said tables will be clientsided and for the localPlayer only, to ensure no tables are being mixed up.