[Mod] Store player-related information [db]

[addi]

Sometimes a mod have to store player relevant information during the restart of the server.
Each mod has it own ways to do it and it have much of code only for that function.

This (something like OOP) mod adds an easy way to do it.

Project Homepage: https://project.king-arthur.eu/projects/db/
Source + Download: https://bitbucket.org/adrido/db/src
API Doku: https://project.king-arthur.eu/projects/db/wiki


1. Add db to depends.txt.
2. Create a new instance of a database:

Code: Select all

local my_db = playerDB({fs={
                             form = "json",
                             place="world",
                             name="my_db",
                             },})

Get some value:

Code: Select all

local somevalue = my_db:get(player, key, default)

player can be a playername or a player object.
key is a string wich value tried to read.
default is a string, number,table wich is returned if nothing found.

Set something:

Code: Select all

my_db:get(player,key,value)

player can be a player name or a player object.
key is a string.
value can be a string, number or table.

Example: a mod that changes the skin:

Code: Select all

local skin_storage = playerDB({fs={
                             form = "json",
                             place="world",
                             name="skins",
                             },})
...
-- If a player joins the server:
local current_skin = skin_storage:get(player,"skin_id",1) --1 is the default skin
...
-- If a player sends a formspec to set the skin:
local selected = fields.skin
skin_storage:set(player,"skin_id",selected)

Depends: Minetest 0.4.3
License: WTFPL and CC 0 (at your option)

[kaeza]

Something like this would be useful in builtin.

Have you considered submitting a pull request to minetest?

[asie]

Doesn't datastorage from technic_game do something similar already?

[rubenwardy]

Two things: firstly, the indentation appears to be wrong.

Secondly, I don't see a use for this in any of my mods. Why can't I just use my own storage? It's only ten lines of code long, why would I depend on an additional mod?

[addi]

Something like this would be useful in builtin.

Have you considered submitting a pull request to minetest?

no, but if there a chance that it will be merged ill do it

Doesn't datastorage from technic_game do something similar already?

dont know, i dont find something like "datastorage" in technic_game. also its imo easier to depend on a mod than on a game

Two things: firstly, the indentation appears to be wrong.

Secondly, I don't see a use for this in any of my mods. Why can't I just use my own storage? It's only ten lines of code long, why would I depend on an additional mod?

1. its not finished jet, later it does not only store player relevant information, it can also store other informations.

2.1 you can also use your own way to store things, but its easier to use that api provided by my mod
2.2 it matters not if you call it with an player object or with an playername
2.3 im currently writing a lot of (currently not public) mods, and i found out, that i copied to all my mods the same code. and if i made a failure there i must change that overall. so i extracted it.
2.4 the sence, that a mod depends on another is just, that you do not have to use the same code in each.

[asie]

https://github.com/minetest-technic/datastorage is datastorage

if there a chance that it will be merged ill do it

There always is a chance.

[addi]

at first sight I see the technic mod one advantage:

1 you can use ipairs() and pairs()

and one disadvantage:

1 you need to create a new container for each player

with my, there are however more:

1 it can be a default set worth so it saves the following clausel:
if test_container ["var1"] == nil then
test_container ["var1"] = "something"
end
2 it can use both, the minetest and in JSON, format.
JSON format is a data exchange format that can be read by other programs.

3 it saves when something has been changed, thus nothing is lost in a server crash.


but with my mod, there is a disadvantage:

1 you can not use pairs () and iPairs ()

maybe i can try to fix it

the idea of both mods are the same, but there is also another difference:
mine is OOP and rba's is programmed conventional way.

[stu]

I really like this as I have just been reading about metatables and oop in lua in an effort to sharpen my lua skills.
This mod has helped me gel with a real example, very nicely done regardless of the little indentation inconsistency ;-)

I would use this but I think on the whole other modders are reluctant to depend on other mods, which I think is a shame.
It would be nice to see something like this added to builtin, basically a persistent data storage mods can use for data other than metadata for nodes or staticdata for entities. I would suggest a more generic name than playerDB, modDB perhaps?

[rubenwardy]

Not moddb. That's the mod store project.

[Sokomine]

I pretty often add the line

Code: Select all

-- TODO: save and restore ought to be library functions and not implemented in each individual mod!

to my mods - namely whenever I cut&paste the save/restore routine - and that expresses clearly what I think of it.

Please get this (or something like this!) into builtin. That is where it belongs. And please not only player-related information but also other world-related data.

[addi]

how about:
nodeDB optimized to save node relevant information params: (pos,key,value) [alternative for metadata,because all metadata is sent to client]
entityDB optimized to store entities information params:(dontknow,key,value) [maybe soembody wich have some experience with entities should help me]
configDB to store configurations information params:(modname,key,value)
DB to store all other information params:(key,value)

other ideas or sugestions?

i agree, that must be in builtin.

[Sokomine]

That sounds too complicated. Make it so that each mod can store a table for each world. That's the easiest way and also the most flexible one. Offer additional functions for player-specific entries.

Of course, for some situations, beeing able to access a database directly could also be extremly useful (=access to a database on SQL level). Probably something for the wishlist thread.

[spootonium]

+1.
I'd been thinking about extending [hud] into an interface that modders could implement to track and display player stats, buffs, timers and the like, but had gotten discouraged by the task of coding a universal DB back-end for it. Along comes Addi, and makes it look simple.

[SwissalpS]

+1 add to core.
Player related data should be attached/accessable to/by Player object.
But in the end I guess it's a lot more complicated.
Since some data is not only mod-dependent but also game and world dependent.
For now, I vote for this approach. OOP is certainly the future of programming.