Minetest logo

IRC log for #minetest-dev, 2014-01-25

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:19 e1z0 joined #minetest-dev
00:25 e1z0 joined #minetest-dev
00:31 rsiska joined #minetest-dev
00:35 RealBadAngel guys, what about #1112 ? can we have this merged? i keep asking because soon i will have to rebase against my own patches
00:35 ShadowBot https://github.com/minetest/minetest/issues/1112 -- New HUD element - waypoint. by RealBadAngel
00:37 RealBadAngel also i want this code merged: #1117
00:38 ShadowBot https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel
00:38 sapier ShadowNinja Scriptapi is your area #1112 I'm positive about it but I will not decide against your opinion
00:38 ShadowBot sapier: Error: ProcessTimeoutError: Process #738 (for String.re) aborted due to timeout.
00:39 sapier hmm not sure whos realm this is
00:39 RealBadAngel this is how 1117 works: http://i.imgur.com/unPPQGy.png
00:40 RealBadAngel at the image you can see 2 different sized textures
00:40 RealBadAngel those are default ones: http://i.imgur.com/oWx4jth.jpg
00:41 RealBadAngel it works with any textures, but best effects are for either low resolution textures, or cartoonish ones like sphax's for example
00:41 sapier hmm isn't this a little bit too heavy at screen norders?
00:41 sapier borders
00:41 RealBadAngel its configureable
00:42 RealBadAngel by default i made the effect a little bit lighter
00:42 RealBadAngel personally i like it stronger
00:42 sapier yes but we should decide uppon default effect
00:43 RealBadAngel to decide enough folks have to be able to play with it
00:43 sapier I like it but imho in your last image its too much, and I can't imagine how it's gonna look like in default
00:43 RealBadAngel in the first place
00:44 RealBadAngel i cannot keep such changes on my hdd hidden for ages
00:45 sapier of course but I guess it's quite a quick thing to add a similar screenshot with default settings isn't it?
00:45 RealBadAngel since i started to work (and finished it) minecraft has done the same and released it
00:45 sapier you don't have to persuade me I like it
00:45 sapier just not that heavy ;-)
00:45 RealBadAngel so try the pull
00:46 RealBadAngel and tell me what do you think
00:46 RealBadAngel screenshots are static in the first place
00:46 RealBadAngel and shadows are not
00:46 VanessaE sapier: *hand wave*  "these are the shaders you're looking for"
00:46 sapier not tonight, I'd have to stash all my current changes and or rebuild from scratch
00:46 VanessaE sapier: or pull to a work dir. :P
00:47 RealBadAngel it works out of the box, even with test game
00:47 RealBadAngel i mean minimal
00:48 sapier while you're discussing you could already have done that screenshot ;-)
00:49 sapier but I can't merge it either, graphics isn't my realm
00:50 sapier -either + anyway
00:52 RealBadAngel sphax texture pack: http://i.imgur.com/2BB0px7.png    + the effect: http://i.imgur.com/JpTkG0T.png
00:52 sapier that's cool
00:55 RealBadAngel same for default: http://i.imgur.com/bN0laP5.png vs http://i.imgur.com/HoXY5Gl.png
00:56 sapier imho a little bit to heavy at the edge ... but that's a matter of personal taste
00:57 RealBadAngel and HDX 256x: http://i.imgur.com/h0Jtim2.jpg vs http://i.imgur.com/2r7kuBf.jpg
00:58 sapier ok that's ugly
00:58 RealBadAngel that what you could too heavy at the edge are dynamic shadows
00:58 RealBadAngel and depends on the point of view
00:58 RealBadAngel and is dynamic
00:58 sapier I could live with it I'm just telling my opinion ... it's better then before
00:59 RealBadAngel yeah, as i already said, effect is not for photorealistic texture packs
00:59 sapier have a look ain wiki and see who's responsible for graphics I support merging it
00:59 RealBadAngel it is using sobel operator to generate normals, so it makes strong outlines to the sampled areas
01:13 RealBadAngel and another pretty nice screenshot from VanessaE's server: http://i.imgur.com/E7eGGGd.png
01:18 EvergreenTree joined #minetest-dev
01:18 EvergreenTree joined #minetest-dev
01:40 zat joined #minetest-dev
02:14 xrogaan left #minetest-dev
04:10 Miner_48er joined #minetest-dev
05:04 AllegedlyDead joined #minetest-dev
07:16 Miner_48er joined #minetest-dev
07:16 Miner_48er joined #minetest-dev
07:41 Taoki[mobile] joined #minetest-dev
08:05 ImQ009 joined #minetest-dev
08:13 werwerwer joined #minetest-dev
08:47 darkrose joined #minetest-dev
09:27 Calinou joined #minetest-dev
09:54 Gethiox joined #minetest-dev
11:02 PilzAdam joined #minetest-dev
11:31 Jordach joined #minetest-dev
12:22 werwerwer_ joined #minetest-dev
12:30 rsiska joined #minetest-dev
12:38 rsiska joined #minetest-dev
12:38 xyz sfan5: https://github.com/sfan5/irrli​cht-android/commits/ogl-es-svn
12:39 sfan5 good, so we merge that to master when needed?
12:40 xyz well, that was my idea
12:40 xyz I guess you'll have to redo master though?
12:40 sfan5 that' ok
12:40 sfan5 s/that's ok/
12:41 sfan5 I'll do that in a minute
12:45 nore joined #minetest-dev
12:53 Weedy_lappy joined #minetest-dev
12:53 Weedy_lappy joined #minetest-dev
12:53 Weedy_lappy joined #minetest-dev
13:02 e1z0 joined #minetest-dev
13:06 RealBadAngel joined #minetest-dev
13:09 RealBadAngel celeron55, u here?
13:19 EvergreenTree joined #minetest-dev
13:19 EvergreenTree joined #minetest-dev
13:30 sfan5 xyz: I'm finished with redoing master
13:31 xyz it's good, I guess
13:31 xyz although I'd prefer you to use my patches of course
13:31 sfan5 I didn't say that I won't use them
13:31 xyz http://irrlicht.sourceforge.net/fo​rum/viewtopic.php?f=7&t=49410
13:32 xyz but you did implement your prevx/prevy stuff
13:33 sfan5 yeah, I can remove that because it does not work as intended
13:33 e1z0 joined #minetest-dev
13:34 xyz because you got confused, your previous x/y are based on pointer index but those should actually take pointer id into account
13:34 xyz also there's a similar bug in my code
13:35 sfan5 does that explain why touching does nothing?
13:35 xyz your code?
13:35 sfan5 yes
13:36 xyz it depends on what you defined as "nothing"
13:36 sfan5 well the coordinated go through, but I can't use the main menu
13:36 sfan5 coordinates*
13:37 xyz here's another patch which also includes more stuff https://github.com/xyzz/freeminer/blob​/android/build/android/irrlicht.patch
13:37 xyz you can't use main menu probably because you don't emulate mouse
13:37 xyz you should either modify the code to properly send EET_MOUSE_INPUT_EVENT events
13:37 sfan5 I do: https://github.com/sfan5/irrlicht-android/co​mmit/2d63973d5e4bf0371b88f625c694d1c864b2f45​e#diff-1a6779bf06c62dde43aaa25bc9f8c505R299
13:37 xyz or modify irrlicht to make gui work with multi touch events
13:37 xyz yet it still doesn't work?
13:37 sfan5 no
13:39 xyz you only send EMIE_MOUSE_MOVED event
13:39 xyz how do you expect it to work?
13:40 sfan5 oh
13:40 sfan5 I looked at the code of CIrrDeviceSDL.cpp and probably didn't see the irr::EMIE_LMOUSE_PRESSED_DOWN part
14:14 RealBadAngel i have done a mod to store on disk any data for players in a single file
14:14 RealBadAngel https://github.com/minetest-technic/datastorage
14:14 RealBadAngel what do you think about adding such thing to builtin?
14:16 ImQ009_ joined #minetest-dev
14:21 xyz what about reliability? why's that tied to players' data?
14:22 RealBadAngel its meant for mods to store per player data
14:23 RealBadAngel there are many mods that create separate files on the servers
14:23 RealBadAngel this way theres single file per player
14:23 RealBadAngel and memory used is freed on player leave
14:26 RealBadAngel also managing the data is extremaly easy, just two functions for mods to use
14:26 RealBadAngel https://github.com/minetest-technic​/datastorage/blob/master/README.md
14:27 grrk-bzzt joined #minetest-dev
14:27 xyz so basically that's just a kv storage where you construct the key by taking modname and playername
14:28 xyz well that's fine but I think what we really need is a reliable persistent kv storage accessible from lua
14:29 RealBadAngel ive made one super-reliable based on inventories
14:29 RealBadAngel but the data stays loaded in memory all the time
14:30 xyz we could store the data in a map and add methods to our database_* classes
14:30 xyz I don't see any problem with that
14:30 RealBadAngel http://pastebin.com/xFEQnW9W
14:31 RealBadAngel this one uses items meta to store any data
14:31 RealBadAngel xyz, database would be the best solution imho
14:32 xyz yup
14:32 RealBadAngel atm there are more than 10 mods that create tons of files on servers to store their data...
14:33 RealBadAngel im about to add such functionality to 3rd of my mods
14:33 RealBadAngel so i decided some universal storage is needed
14:33 xyz well that shows that some part of lua api is badly designed
14:40 RealBadAngel either in lua or database, we need such thingy badly
14:49 NakedFury joined #minetest-dev
14:59 xyz yea, I agree
15:00 sfan5 how about lua <-> sqlite3 binding?
15:01 xyz I think just having kv storage is enough
15:02 sfan5 lets use redis /s
15:02 xyz redis is way more than kv storage
15:02 xyz so we can start with api which allows us to store/retrieve data (string) from this storage
15:03 sfan5 hm
15:03 xyz and then write a function to serialize/deserialize lua tables
15:03 xyz using marshal, for example
15:05 sfan5 file format proposal: MTKVS\x00\x01\x00\x05abcde\x00\x07foobar1 || Magic, File format version, repeat( key length, key, value length, value)
15:06 xyz why are you reinventing stuff?
15:06 sfan5 because why not?
15:07 xyz that's a very bad argument for reinventing the wheel
15:07 sfan5 well.. what should we use instead?
15:07 xyz we already have database backends
15:07 sfan5 well then we use sqlite3  for key-value stuff
15:07 xyz no, we use whatever backend the map uses
15:08 xyz and just add methods to those classes derived from Database
15:10 VanessaE how about use neither of those
15:10 VanessaE how about use something that is human readable/writable.
15:10 sfan5 why?
15:11 VanessaE because half of the data that'll be stored in this per-player database that RBA has in mind will probably need to be stuff a server admin may need to edit.
15:11 VanessaE and it's a hell of a lot easier to sed -i than to try to figure out some obscure sqlite command.
15:11 hmmmm joined #minetest-dev
15:11 xyz why are you so sure about that?
15:11 sfan5 >obscure sqlite command
15:11 sfan5 SQL isn't that hard
15:11 xyz it's just some internal data mod decided to store
15:11 VanessaE if is if you've never used it.
15:12 sfan5 anyway, mods should provide commands to edit data the server admin may want to edit
15:12 VanessaE sfan5: good luck with that!
15:13 xyz VanessaE: can you answer me?
15:13 VanessaE xyz: why am I so sure about what?  that it's easier, or that it's necessary?
15:13 zat joined #minetest-dev
15:14 xyz that "a server admin may need to edit"
15:14 xyz if it's the case then the mod is supposed to provide interface
15:14 VanessaE because I've already had to do it once.
15:14 xyz with what?
15:14 VanessaE with the areas mod.
15:15 VanessaE I had to skim through the database at least once, removing a player's ownership and transfer it to someone else, of all of his areas.
15:15 VanessaE there's no hook for that in the mod, but sed made it a one-command change.
15:15 Gethiox2 joined #minetest-dev
15:15 xyz well then that's a mod's problem
15:15 xyz you could as well have written your own lua script to do that
15:15 VanessaE look, you're trying to kill a fly with a sledgehammer
15:15 xyz how?
15:16 VanessaE you don't need a database to store 10K of player-specific data (or however much it might be)
15:16 xyz we already have the database!
15:16 VanessaE a database file, you twit
15:16 VanessaE don't twist my words.
15:16 xyz what do you mean?
15:16 VanessaE I know we already have the database *program&
15:16 VanessaE **
15:17 Yepoleb joined #minetest-dev
15:17 VanessaE there's no reason to pipe this shit through sqlite or any other database program, turning it into human-unreadable/human-nonwritable gibberish if a plaintext file is good enough for the job.
15:17 xyz no, we already have the database, it's called map.sqlite or map.db or something
15:17 xyz it's not good enough
15:17 VanessaE why isn't it?
15:18 xyz in the end you'll just reinvent the wheel
15:18 xyz say, there's 100k keys and values
15:18 xyz and you want to store this how exactly?
15:18 VanessaE so wait, you want to store per-player data IN the map file!?
15:18 xyz I'm not talking about per-player
15:18 xyz can you read?
15:18 xyz I'm talking about generic kv interface
15:18 VanessaE *facepalm*
15:18 xyz what?
15:18 VanessaE RBA's whole reason for bringing this up was for per-player data.
15:19 xyz yes
15:19 xyz and my point was that we need a generic interface and then we implement per-player data using it
15:19 VanessaE then why are you transforming the argument into kv data embedded into the map?
15:19 VanessaE that's a stupid place to put it
15:19 xyz because that's the generic interface I'm suggesting
15:19 xyz why's that a stupid place?
15:19 VanessaE because what if you need to reset the map one day?
15:19 VanessaE so all your players' data gets deleted with it?
15:19 xyz well you just delete it
15:20 xyz wait and what do you want?
15:20 xyz you want to delete just the map but leave areas, inventories and similar stuff?
15:20 VanessaE "I'll give you a hint - not that."
15:20 xyz that's very helpful
15:21 VanessaE if you're gonna store it in a database, which is already a stupid idea to begin with, it should not be in the map file.  it should be in a separate file.  player_data.sqlite, call it whatever you want
15:21 VanessaE fuck, we already have players/foo
15:21 VanessaE why not store the data in those files?
15:23 xyz why get so upset?
15:23 VanessaE because it pisses me off to see people re-inventing the wheel and coming up with ever more imaginative ways to overcomplicate things.
15:23 VanessaE the files are ALREADY THERE
15:23 xyz that's exactly what you're doing
15:23 xyz (as I see it)
15:23 VanessaE JUST FUCKING USE THEM.
15:23 xyz eh
15:23 VanessaE that's why I get so mad.
15:23 xyz well stay mad
15:24 VanessaE (and I don't mean the map file, because it may not even BE there.....leveldb, some other random backend someday)
15:24 sfan5 you mean we should place stuff in players/foobar ?
15:24 sfan5 what if one wants to save binary data?
15:24 VanessaE sfan5: then MIME encode it or something
15:25 VanessaE or whatever the method du jour is.
15:25 sfan5 that is heavily inefficent
15:25 VanessaE however, I don't think the intent of this was ever to store binary data
15:26 VanessaE but my point is, if you have players/foo and you need to attach player-specific data to him, why not just store it in foo's player file?  (assuming it were text)
15:27 VanessaE the file is there, it's human readable, the engine already loads it anyway, it already knows how to parse it, etc etc
15:28 RealBadAngel but the database solution could be indeed better than a single file
15:28 RealBadAngel it can store any data, binary blobs, player models, tables or whatever
15:29 RealBadAngel and will be far more reliable than new file each time new player joins
15:29 RealBadAngel see, there will be just one file for all of them
15:30 VanessaE well if you HAVE to go with a database, it still must not be part of the map file.  that's one point I would absolutely block this on, had I a vote on this matter.
15:30 RealBadAngel imho it could be separate database file
15:31 RealBadAngel this way transferring all the players data to a new world will be just copyin over that file
15:31 xyz yeah like areas
15:31 xyz to the new world
15:31 xyz yay!
15:32 VanessaE when I created my new server the other day, I imported all of the players' accounts from the other servers, joined with a simple cat command, then loaded it into the new server with /auth_reload
15:32 VanessaE I couldn't have done that nearly as easily with a database.
15:32 sapier joined #minetest-dev
15:32 xyz great!
15:33 xyz I mean
15:33 xyz can we agree that there are things that you want to import and things that you don't?
15:33 xyz all of the players' accounts == auth.txt
15:34 VanessaE == five auth.txt's
15:34 xyz things that are stored in the "players" directory are tied to map
15:35 xyz so I can't imagine any situation in which you'd remove the map but not "players" directory
15:35 xyz unless you're doing some crazy shit
15:36 Evolykane joined #minetest-dev
15:37 RealBadAngel some crazy admin's shit
15:37 RealBadAngel theyre used to do such shit often ;)
15:38 RealBadAngel regular mod or a user wont be able to do that
15:38 VanessaE well I did say auth.txt, not players' files.
15:38 VanessaE inthis case.
15:38 VanessaE but auth.txt is just as player-specific as a player's inventory, I'd think.
15:38 xyz no
15:38 xyz it's not world-specific
15:38 xyz see the difference?
15:39 VanessaE when did we go from player-specific to world-specific?
15:39 xyz when you restart the world you want players' inventories gone
15:39 xyz inventories are player-specific
15:39 VanessaE says who?
15:39 xyz you don't?
15:39 VanessaE YOU might want to delete player inventories.  what if I don't?
15:39 xyz then it's kinda some "crazy shit" I was talking about
15:40 VanessaE or maybe I want to clear inventories only, without resetting the map?
15:40 VanessaE how am I supposed to do that if you tie the two together?
15:41 xyz why do you want this?
15:41 VanessaE I havemy reasons.
15:42 xyz why aren't you saying stuff like "or maybe I want to run sed on map.sqlite to replace default:dirt_with_grass with default:dirt it doesn't allow me to and breaks my map, please do something to store map in human-friendly format"
15:42 xyz great
15:42 VanessaE just as you have your reasons for wanting to wipe it all out at once.
15:42 xyz you're being very descriptive
15:42 VanessaE maybe I have some asshole player, or several, who got something into their inventory illegitimatley?
15:42 xyz and giving very heavy reasons for what you say
15:42 xyz so I'll definitely have to consider those points you make
15:42 VanessaE or if an admin drops something by accident and another user picks it up and should not have it?  how do I get rid o fit then?
15:43 VanessaE such as a maptools admin pick
15:43 VanessaE I had to edit that out of a player's file the other dat
15:43 VanessaE day*
15:43 Exio4 that should be done in-game
15:43 VanessaE Exio4: there is no facility in-game for editing another player's inventory.
15:43 Exio4 also, cleaning invs but not world, or viceversa are not that crazy things
15:45 RealBadAngel back to the point. problem was to store MODS data per player or whatever the key is. It means we need the db to store a table with given key. thats all
15:45 VanessaE as an active admin, I need to be able to make changes to players' inventories, positions in the world, or other things, whether they are online or not, or backup and/or restore their inventories from backups if something weird happens.
15:46 RealBadAngel whatever mods decide to write there its on their own
15:46 RealBadAngel and whatever admin decide to do with the file is up to admin
15:47 RealBadAngel so imho whole arguing is pointless rather
15:49 ShadowNinja RealBadAngel: Your mod has issues with players named "load_data" and the like...
15:49 RealBadAngel yes i know
15:49 RealBadAngel adding ! to keys would prevent that
15:50 RealBadAngel like "!registered_players" "!player_name"
15:50 ShadowNinja Storing players/ in a SQLite DB might be good, it would fix the Windows check-every-file-to-find-a-players-playerfile hack.
15:50 ShadowNinja RealBadAngel: You should store that is a seperate table.
15:51 ShadowNinja Mods WILL use it without prepending a '!', and making them do that is hacky.
15:51 sapier imho mod data should never be stored withing generic map data. If we want mods to use sqlite files someone could try to find a old pull request of mine. I suggested this about 1-2 years ago
15:51 sapier it's been a proof of concept by that time only
15:51 ShadowNinja While I find SQL fairly easy, LevelDB is much harder to edit...
15:52 RealBadAngel separate db file for mods is the best solution imho
15:52 sapier I fully agree with rba. And separate files can be stored either in world folder e.g. for waypoint or other map related data ... or in mod folder for generic data
15:52 RealBadAngel ShadowNinja, yes, it shall be separate table
15:52 ShadowNinja Yes, access to mod sqlite DBs would be good, as long as mods didn't use it for storing tiny ammounts of data.
15:53 xyz why sqlite?
15:53 Calinou joined #minetest-dev
15:53 RealBadAngel tiny or not. this is meant to store ANY data
15:53 xyz how do you plan to use sql then?
15:53 ShadowNinja xyz: Because it's simple, fast, and bound to a single file.
15:53 sapier I don't care if sqlite or something else.
15:53 xyz ShadowNinja: I'd prefer leveldb
15:54 sapier as long as it's not json ... it'd be crap to use a text format to store data ... if a text format use lua's native format
15:54 sapier either binary (sqlite,leveldb,...) or lua native
15:55 xyz that depends on how you plan to use it
15:55 xyz if just as kv store then there's no reason for sqlite
15:56 sapier yes, as you can already use lua native, I guess the only additional feature worth implementing would be a fast binary db
15:57 xyz woth implementing?
15:58 sapier what would be benefit of adding a slower second text format?
15:58 sapier or a third ... fourth ... xxxth
15:59 xyz I'm not sure what you want to "implement"
15:59 xyz what's "fast binary db"?
16:00 sapier actually in best case we would only have to decide to include a lua lib to acces sqlite db files from lua
16:00 sapier or leveldb files ... or any other binary db file
16:00 e1z0 joined #minetest-dev
16:02 xyz and what the api would look like?
16:03 sapier what ever that lua library would provide as api ... btw who did request that feature?
16:05 xyz that'd be really stupid
16:06 xyz what if server has no leveldb support?
16:06 xyz what if server has no sqlite support?
16:06 xyz the second situation can't happen though
16:06 sapier you can't fix that issue
16:06 xyz no you can
16:07 sapier how do you think you can fix it?
16:07 xyz first you should determine what users need
16:07 ShadowNinja if minetest.features.leveldb then...
16:07 xyz then you provide a generic api
16:07 xyz the first step is not done yet
16:08 sapier a generic api to access a database? of course you can ... imho it's like using a harvester to cut your bonsai
16:08 xyz why do you think we'll need " a lua lib to acces sqlite db files from lua"
16:08 xyz i don't think modders will need anything more than key-value storage, like i've been trying to tell you all for an hour or so
16:08 sapier I don't think we need any of this
16:10 xyz any of what?
16:10 sapier any additional way to store data for mods. I haven't read a usecase yet that can't be done with current api
16:10 sapier do you know any?
16:11 bas080 joined #minetest-dev
16:11 xyz with current api it gets extremely messy since every mod creates its own files wherever it wants to
16:11 sapier and how do you suggest to fix it?
16:11 RealBadAngel api should be dead simple
16:11 xyz then it has to maintain those files (open, close, read, write)
16:11 xyz sapier: read my message please
16:11 RealBadAngel get_container ( key)
16:11 sapier wich one?
16:11 RealBadAngel and thats all
16:12 xyz sapier: alright, I'll repeat once again
16:12 xyz sapier: I propose to add API methods to utilize key-value storage
16:13 xyz get string for key, set string for key
16:13 xyz then add Lua methods to, for example, get table for key, set table for key
16:13 xyz which will be smarter and will be able to use additional data, i.e. mod name, when dealing with keys
16:14 sapier we already have that api
16:14 xyz what is it?
16:14 sapier it's called "settings"
16:14 xyz it's boring
16:14 xyz I guess you're trolling
16:14 RealBadAngel lol
16:14 sapier it's exactly what you suggested
16:14 xyz or wait
16:14 sapier key --> value
16:15 xyz do you genuinely fail to understand that settings are not per-world?
16:15 sapier the only thing to change is add additional settings elements not beeing saved in minetest.conf
16:15 xyz or that storing binary data is not the best idea?
16:15 xyz or that those things aren't even settings?
16:15 sapier I already had a pull request "per world settings"
16:15 xyz okay
16:15 xyz let's say we now have a lot of mods
16:16 RealBadAngel lemme be clear, i as a modder need a table in which i can store ANY data, everything that can be put into lua table
16:16 xyz and there's a mod which creates 10 keys per player
16:16 sapier actually it did just use settings code to open a different file as settings source
16:16 xyz so in the end there could easily be 100k keys
16:16 RealBadAngel a jpg for example, a model, dumped computer memory
16:16 RealBadAngel whatever i can imagine
16:16 xyz you really want to store this in a settings text file?
16:16 RealBadAngel so storing that in text file is bad idea
16:17 sapier rba that's a basic problem a generic db will never be as fast for simple task as a specific implementation
16:17 RealBadAngel i cannot see there a problem
16:17 sapier xyz you wanted key value and don't want to use a db
16:17 RealBadAngel it doesnt need to be lighting fast
16:18 RealBadAngel mods dont save their data all the time
16:18 RealBadAngel its meant to be a storage
16:18 sapier It's crap to have hundreds of mb overhead for a feature used to store 2 propertis in about 99% of all cases rba
16:18 sapier imha of a mod has that specific requirements to it's data storage it should take care about it's storage itself
16:18 xyz sapier: I've never said I don't want to use a db
16:19 RealBadAngel why hundreds of mb??
16:19 xyz lrn2read
16:19 RealBadAngel im talkin about a generic method to storage anything
16:19 sapier true you said you don't want to look it like a db
16:19 xyz and I've never said that
16:19 RealBadAngel not anything specific
16:19 xyz stop telling me I did
16:20 sapier generic interface using key value isn't what I call a db interface
16:20 xyz I said that there's no reason to expose underlying database interface to Lua
16:20 xyz alright
16:20 xyz then think about it this way
16:20 nore btw, about meta_set_nodedef: http://nore.mesecons.net/screenshot_3392059102.png
16:20 xyz I don't want a db, I want a key-value interface
16:20 xyz the key-value interface can be provided by a DB
16:20 RealBadAngel yes
16:20 sapier true but could be provided by settings too
16:20 RealBadAngel and that is what modders need
16:21 RealBadAngel sapier, no
16:21 xyz nore: what's this supposed to show?
16:21 RealBadAngel key can be modname
16:21 sapier so what do we encourage this iface to be used for gb's of data or for some small settings?
16:21 RealBadAngel so 1 key could mean all the mods data
16:21 RealBadAngel not a single value
16:21 nore xyz, the tree in front is half-size... done with micro-nodes with meta_set_nodedef
16:22 xyz nore: well this could be done without it and will be more efficient too ;P
16:22 sapier rba I used settings to store all mods data for quite some time this is possible
16:22 sapier key value doesn't necessaryly mean "value" to be a basic datatype
16:23 nore no, because with that, you can make micro-nodes using ANY material... and put several micro-nodes of the same material in the same node
16:23 nore s/same/different
16:23 RealBadAngel sapier, take a look at this: https://github.com/minetest-techni​c/datastorage/blob/master/init.lua
16:23 RealBadAngel this is funcionality im talkin about
16:23 xyz RealBadAngel: I'm afraid we won't find support here
16:24 sapier ok it's same I use in mobf for about a year now
16:24 RealBadAngel xyz, just code that
16:24 sapier and I already found usecases where a single file doesn't fit mobfs requirements
16:25 xyz RealBadAngel: maybe I will, too busy with other stuff now
16:26 RealBadAngel by now, coding data storage solutions for each and every mod out there is just insane
16:26 xyz but then what's the point if minetest will never merge that?
16:27 RealBadAngel if anybody out there will say we dont need such solution will simply mean hes nuts
16:27 sapier Rba while I'd like to have a single interface to I don't think this interface can ever fit all mods requirements
16:29 sapier I once wanted to add per world settings, but I realized they're not that usefull
16:29 RealBadAngel then if you write some crazy mod that need some crazy solution only for its own usage, code it
16:29 RealBadAngel but we need a generic one
16:29 sapier imnho the usecase you suggest "lots of data" is the crazy one
16:30 RealBadAngel not "lots of data"
16:30 RealBadAngel i said "any data"
16:30 RealBadAngel that is what generic means
16:30 sapier and what data do you think you can't store e.g. in settings?
16:30 RealBadAngel jpg?
16:31 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies​/minetest/screenshots/screenshot_3392990975.png
16:31 sapier you can't have a jpg in lua anyway
16:31 VanessaE nore: ^^^^^^
16:31 RealBadAngel a picture i mean
16:31 VanessaE "mini grain elevator"
16:31 sapier same
16:31 sapier lua only has text numbers and tables
16:31 VanessaE stands ~4m tall
16:31 RealBadAngel in which we can store anything
16:32 VanessaE nore: ^^^^^ the screenshot you asked me to make.
16:32 sapier ok so if you have your jpg/image as "text" you can store it to settings
16:32 RealBadAngel yup, and still we end with many files
16:32 sapier sorry if I'm not understanding what you want to tell me
16:32 RealBadAngel instead of one db file
16:33 xyz why would you store this in settings?
16:33 sapier because we already have that interface ;-)
16:33 xyz it's extremely inefficient
16:33 sapier it's a text file containing keys and values
16:33 xyz which is extremely inefficient
16:33 RealBadAngel because it will be damn funny to see and trying to edit such file with a few images stored in it ;)
16:34 RealBadAngel propably thats a reason hehe
16:34 sapier depends on your usecase if you want to store just a few paramteress it's quite efficient
16:34 xyz yuuup
16:34 xyz just like loading player files in O(n²) is quite efficient
16:34 xyz well who'd have thought we'll ever have 30k files
16:34 sapier I don't know any format to store a couple of images in here and edit with text editor
16:35 xyz let's just load all them in memory
16:35 xyz in a list
16:35 xyz now let's say there's a mod which adds 1 key for a player
16:35 sapier so what's your suggestion xyz?
16:35 xyz but 1 mod is unfun, let's have 10 mods
16:35 xyz you'll have 300k keys in a single text file
16:36 xyz sapier: well i could repeat it once again just for you
16:36 xyz sapier: it's to use db to store kv data
16:36 RealBadAngel sapier, single file solution is better because you will read the data when you need them
16:36 RealBadAngel also freeing up memory will be as easy as assign nil to table pointer
16:37 RealBadAngel so no need to preload anythin into memory
16:37 sapier I don't have a problem with this but you have to implement quite a lot of administration features
16:37 xyz what?
16:37 RealBadAngel what for?
16:38 sapier e.g. list mods having data in that file
16:38 sapier delete data for a single mod
16:38 RealBadAngel what for?
16:38 sapier backup data per mod
16:38 xyz but you can't know it
16:38 xyz backup?
16:38 xyz well, now you're just saying some random shit
16:38 xyz map doesn't provide those interfaces and no one complains
16:38 RealBadAngel theyre not needed at all
16:38 sapier I can delete/backup/ls any file stored in world folder ... in current stage OS provides those features
16:39 Zeitgeist_ joined #minetest-dev
16:39 sapier if you put all to a single file you need to do this manually
16:39 RealBadAngel so you can backup one db file too, right?
16:39 RealBadAngel have you ever saw windows registry?
16:39 sapier maybe I don't want to backup the full file? or I removed a mod and want to delete it's data now? or I didn't remove the mod but want to remove it's data
16:40 xyz well
16:40 RealBadAngel its quite similar to that idea
16:40 xyz that's got pretty boring
16:40 sapier e.g. because the mods data got corupted by a bug
16:40 RealBadAngel any program can use the registry
16:40 xyz anyway, if I ever implement it 1) you know where to find it and 2) I'll maybe probably send you a patch
16:40 RealBadAngel read "mod"
16:40 sapier yes and everyone thinks windows registry is crazy shit ;-)
16:41 RealBadAngel text based settings file for that is even more crazy :P
16:41 sapier and no RBA if you say mod == programm we need uninstallers for mods ;-P
16:41 Zeitgeist_ joined #minetest-dev
16:41 Zeitgeist_ joined #minetest-dev
16:42 sapier true rba we'd need to implement this too for a single file ... but it'd be possible to remove a key from a text file by text editor
16:42 sapier I'd not wanna do this
16:42 RealBadAngel youre trying to find a problems in extremaly simple task
16:42 RealBadAngel storing a table
16:42 sapier you'r suggesting solutions for non existing problems  ;-)
16:43 RealBadAngel this is existing problem
16:43 sapier I don't see a problem in each mod having it's own data file
16:43 RealBadAngel i do have already a few of my own mods that have to store data
16:43 RealBadAngel and its extremaly uncomfortable to implement storing them
16:44 sapier me to and I usually just copy those 50 lines of code
16:44 sapier or include the file containing that code
16:44 RealBadAngel not to mention creating tons of files server side
16:45 sapier It's quite simple if your suggestion isn't as good as solving the task in a way modders will be thankfull to use it, nothing will change
16:45 RealBadAngel what could be simplier than calling a function and get pointer to a table?
16:46 sapier that's what I already have so it's not better
16:46 RealBadAngel xyz was right, youre just trolling
16:46 sapier no I'm not, I just don't see the benefit.
16:47 sapier not for the things I need to store
16:47 sapier there may be obvious benefits for other usecases
16:47 xyz "i don't need it so there's no benefit"
16:47 xyz i don't need it so nobody needs it
16:48 sapier you haven't proposed any REAL usecase I can understand to
16:48 sapier o
16:48 RealBadAngel i do need it
16:48 RealBadAngel for all of my mods
16:48 sapier "storing images" ... I guess reading a image to lua will be way more complicated then storing it
16:48 RealBadAngel that was just an example
16:49 RealBadAngel real usecases are usually not so heavy
16:49 sapier what do you need? sore some key value things
16:49 sapier or more?
16:49 RealBadAngel cant you read?
16:49 RealBadAngel i need to store a lua table with given key
16:49 RealBadAngel nothing less, nothin more
16:50 RealBadAngel i cant say that any simplier
16:50 sapier setting.set(key,minetest.serialize(value))
16:51 RealBadAngel forget it
16:51 RealBadAngel its unusable
16:51 sapier value = minetest.deserialize(setting.get(key) or "{}")
16:51 sapier why?
16:51 sapier sorry I really want to understand it
16:51 hmmmm he wants to store binary data
16:51 RealBadAngel because settings file is not meant for such usage
16:51 sapier ok for binary data this is not usefull
16:52 sapier no problem to admit this
16:52 sapier but do you really save binary data in any of your mods RBA?
16:52 RealBadAngel technic computer could do that
16:52 RealBadAngel store its memory
16:53 sapier memory is binary data?
16:53 RealBadAngel what would you expect?
16:53 sapier in a lua mod? text
16:53 RealBadAngel computer can also have a screen...
16:54 sapier ok other mods having binary data?
16:54 sapier xyz? do you have any mod ?
16:54 xyz what?
16:54 hmmmm but I have to agree
16:54 hmmmm the utility in this is quite limited
16:55 hmmmm it'd be best to have a simple, mutual agreement between modmakers on how to share data blobs instead of building something into minetest
16:55 hmmmm the key-value store could be like
16:55 hmmmm the file is the key
16:55 hmmmm filename rather
16:55 hmmmm the value is the contents of the file
16:56 hmmmm your filesystem is the database
16:56 sapier this might fail if someone has thousands of mods saving data... true ... but is this a realistic scenario?
16:56 RealBadAngel but this way on the server side we do have way too much files
16:57 RealBadAngel instead of one db file
16:57 sapier what is "too much"?
16:57 sapier as far as I know any current filesystem can handle some very very large number of files
16:57 RealBadAngel and when i need for example check any teleported i have to reload each and every file
16:58 RealBadAngel instead of just asking db
16:58 sapier it's not as for player files where we really have thousands of files
16:58 sapier so db has to do same
16:58 kahrl sapier: "too much" = running out of inodes
16:58 RealBadAngel well, if "1 file per player" my lua solution already does that
16:58 kahrl this happened quite regularly before the map format was switched to sqlite
16:59 sapier kahrl this depends on what you did specify on formating the disk ;-)
16:59 sapier RealBadAngel I usually keep those data in memory and only save back to file on modification
17:00 sapier of course this will fail if you have a lot of data ... but what's wrong with e.g. keeping 20 mb of data in memory per mod?
17:00 sapier if you don't need it os will swap it anyway
17:00 RealBadAngel yes, but imagine that: some1 has built a teleporter, hes not online
17:00 RealBadAngel you have to browse through all the aviable ones
17:01 RealBadAngel so you have to reload all of them, so it means reload all the players files
17:01 sapier ok what you're adressing now is not data storage issue but data access issue
17:01 RealBadAngel its bound together
17:01 sapier why is mod data bound to player?
17:02 RealBadAngel and im describing now real mod behaviour
17:02 RealBadAngel stargates
17:03 sapier rba no db in world can stop you from misorganizing your data
17:04 sapier if you use player as key and save position somewhere in lower levels you can't expect to have fast per position access
17:04 sapier a db can only handle this if you add additional per pos indices
17:04 sapier indexes
17:04 RealBadAngel no, it can easily handle that if mod was the key
17:04 RealBadAngel not player name
17:04 sapier And I don't know if any filedb like sqlite supports this does anyone know?
17:05 RealBadAngel so, as you can see per_player file fails in this very case
17:05 sapier Hmmmm just suggested to save data per mod in files named MOD
17:05 RealBadAngel and per any key solution still works
17:06 sapier nooone suggested to save data per player?
17:06 sapier at least didn't I realize that suggestion
17:06 RealBadAngel im talkin all the time "PER KEY"
17:06 RealBadAngel whatever mod decides key is
17:07 RealBadAngel modname, player name or some random shit
17:07 RealBadAngel generic solution to store any data
17:08 sapier ok maybe I understand now you want a double key db <KEY><MOD>
17:08 sapier right?
17:10 hmmmm what i figured would be decent is something like filename is the top-level key which is per mod
17:10 hmmmm then each lower-level subkey is represented within the file
17:11 hmmmm for example technic.images.imgwhatever = "binarydatahere" would be like technic.bin, and inside of technic.bin you have a really really simple VFS where one section would be images and then then a specific image would be someimghere
17:11 hmmmm err imgwhatever
17:11 hmmmm lots of games have virtual filesystems by the way, don't act like it adds too much complexity to consider
17:12 hmmmm in fact I think that's how the windows registry works
17:15 sapier we have a lot of simple solutions, but imho we should add one really solving the issue in a generic way and not only solving a single issue
17:17 sapier and even RealBadAngel always uses the term "generic solution to store any data" the way I understood his suggestion it seems to be very specific to me
17:17 hmmmm i think what he wants is to make a set of database access api and an abstraction layer on top of them
17:18 sapier maybe we should divide api from implementation. xyz suggested simple key/value, I guess for what rba wants this isn't enough
17:19 sapier if I understood correct you need at least key,mod,value
17:19 hmmmm well the mod is part of the key
17:20 hmmmm i would suggest that the api just has a sql query interface, but we use databases that are non-sql so we have to do the abstraction in the core
17:20 hmmmm ugh
17:20 sapier ok that's obviously an option too but I guess it's not what is suggested is it RBA?
17:22 ShadowNinja PenLight has a CSV-like text database format with SQL-like queries...
17:22 RealBadAngel if we have a key access it means we have it all
17:22 hmmmm oh by the way, when I say 'we' i mean the person implementing this which is clearly not me
17:22 RealBadAngel inside one key, in a table, theres another key...
17:22 ShadowNinja https://github.com/stevedonovan/Pe​nlight/blob/master/lua/pl/data.lua
17:22 sapier sounds like a full blown db interface RBA?
17:22 RealBadAngel so clearly a filesystem like and subdirectiories
17:23 sapier not a simple abstraction like xyz suggested
17:23 RealBadAngel using any "key" means its simple
17:24 RealBadAngel so per player, per mod, or whatever uses are possible
17:24 harrison i searched the whole keyboard but i can't find the "any" key!
17:24 sapier no it doesn't. If I understand correct result of get(key) could be either a lua datatyp or something you can do result.get(anotherkey)
17:24 sfan5 16:05:01 <sfan5>file format proposal: MTKVS\x00\x01\x00\x05abcde\x00\x07foobar1 || Magic, File format version, repeat( key length, key, value length, value)
17:24 sfan5 what about that? ^
17:25 RealBadAngel result shall always be a pointer to a table
17:25 hmmmm deleting keys
17:25 sapier table as in lua table?
17:25 RealBadAngel which can contain anythin
17:25 RealBadAngel yes
17:25 hmmmm you should not make up your own file format for this
17:25 grrk-bzzt joined #minetest-dev
17:26 sapier but if result is a table you'll have all the issues you have with files again, as you need to store whole table on modification
17:27 RealBadAngel store on leave, shutdown or forced save
17:27 RealBadAngel wheres the issue again?
17:27 sapier sounds exactly like your file access code?
17:27 RealBadAngel because that is exactly needed?
17:28 sapier but if the data is stored on leave you'll have the teleporter issue again?
17:28 RealBadAngel no because i can call for the specific pointer at any time
17:29 sapier wait what's "pointer" we had keys and tables by now
17:29 RealBadAngel load the data, assign nil to the pointer to delete it when no longer needed
17:29 RealBadAngel because theyre pointers in fact
17:29 sapier so what is a pointer supposed to be?
17:30 xyz still arguing?
17:30 sapier no I just trying to understand
17:30 xyz just make a key-value api, fetch value for key, store value for key, delete key
17:30 xyz both key and value are strings
17:30 sapier and aren't enough for what rba wants
17:30 xyz (like leveldb does it)
17:30 RealBadAngel why not?
17:30 xyz strings are always enough since you can serialize/deserialize stuff
17:30 RealBadAngel i can serialize to string anytghing
17:30 xyz for that I suggest to use marshal
17:31 sapier what's a pointer?
17:31 sapier you said you need them but I don't know what you mean with a pointer
17:32 RealBadAngel you you have table [modname][playername] you can call for it to get table [modname] and its content
17:32 sapier ok
17:32 RealBadAngel or [modname][playername} to get just one player data
17:32 RealBadAngel for example
17:32 sapier ok still with you
17:32 RealBadAngel and you use it then in a way table[value] = "foo"
17:33 RealBadAngel whenever table points to
17:33 sapier like table[value] = <playerdata> ?
17:35 RealBadAngel for example
17:35 sapier ok so you want to store teleporter data from a player to another table to make it available after player left?
17:36 RealBadAngel that could be example use of it
17:37 RealBadAngel such solution is flexible
17:37 sapier ok so far so good. now let's say player didn't join since server startup
17:37 RealBadAngel if the data is created and stored it can be accessed
17:37 Miner_48er joined #minetest-dev
17:37 RealBadAngel no matter how many shutdowns there were
17:38 sapier that's not possible in lua
17:38 RealBadAngel of course it is
17:38 RealBadAngel this is how my code works
17:38 sapier the only way to make this work is load everything to memory at startup
17:38 sapier and keep it there
17:39 RealBadAngel once a player were on the server mod creates a key for that player
17:39 sapier and that key is loaded at each startup or on player login only?
17:39 RealBadAngel http://pastebin.com/ebVbFr02
17:40 sapier ok so on player login only
17:40 RealBadAngel on demand or player join
17:40 RealBadAngel i can still get the data if i need to
17:40 sapier by loading the player data
17:41 RealBadAngel i will have just to browse registered players table
17:41 sapier yes exactly you have to load the full player data in order to access something within
17:42 sapier full player data != all player data
17:42 RealBadAngel in this very implementation, yes
17:43 sapier the best aproximation I know to access arbitrary data directly without having to load other data is a hashtable
17:43 sapier but you'd have to store basic values behind the hashtable keys to have direct access to all data
17:45 RealBadAngel but in this very case storing gates per player is not the best solution
17:45 sapier it's not a flaw in your implementation RealBadAngel if I understand correctly what you want this is just not possible in general.
17:46 RealBadAngel key shall be a gate, not the owner
17:46 RealBadAngel and then everything is ok
17:46 sapier yes for this special case data format is buggy
17:47 RealBadAngel owner shall be a value, together with position
17:48 RealBadAngel so, we are still back that proper usage of keys can be a solution
17:48 RealBadAngel ANY keys, not forced modname or playername
17:49 sapier imho we have multiple options lua only like your code. core assisted e.g. world specific settings. core assisted db file access, and the full blown option add real database support to lua api (we have another multiple options to do this)
17:50 sapier all have pro's and cons dependent on what you want to use it for
17:50 sapier maybe a single solution isn't enough for everything
17:53 sapier I don't like usage of ANY key because you can't remove data on per mod base in this case
17:56 sapier maybe there's a way to "hide" the mod key within api
18:08 RealBadAngel removing the data is an optional case
18:10 RealBadAngel and in fact it is nothing different to issue when you have removed the mod and then have unknown nodes
18:11 RealBadAngel following your way unistalling the mod shall efect in removing the nodes it placed in the world too
18:15 RealBadAngel or provide a txt file for each mod with key names that mod will use
18:15 RealBadAngel then simple cleaning script
18:16 RealBadAngel so admin will be able to clean the registry when needed
18:20 salamanderrake joined #minetest-dev
18:41 hmmmm minetest is the best OS
18:42 xyz just lacks decent voxel-based game
18:48 hmmmm yup
18:48 harrison needs moar raytracing
18:48 hmmmm you have fun with that okay?
18:48 harrison and a dedicated cryptocurrency
18:48 harrison oh, fun, i kinda remember that
18:48 hmmmm buttcoin integration would be neat
18:49 harrison it was before 1995 i think
18:49 xyz nah dogecoin's the big thing now
18:51 hmmmm dogecoin to the moon
19:05 zat joined #minetest-dev
19:29 VanessaE proller: is that you on my almost-vanilla server?
19:37 Calinou joined #minetest-dev
19:45 zat joined #minetest-dev
19:49 bas080 joined #minetest-dev
20:14 zat joined #minetest-dev
20:46 RealBadAngel so, what about #1112 and #1117 ?
20:46 ShadowBot https://github.com/minetest/minetest/issues/1112 -- New HUD element - waypoint. by RealBadAngel
20:46 ShadowBot https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel
20:47 sapier1 joined #minetest-dev
20:49 ShadowNinja RealBadAngel: You're sure that new clients will be able to connect to old servers?  It looks like you need a try block around the readV3F1000.
20:50 RealBadAngel im sure
20:50 ShadowNinja You've tested it?
20:50 RealBadAngel yes, i played with such client on VanessaE server
20:51 ShadowNinja And she didn't add your patch?
20:51 RealBadAngel no
20:52 RealBadAngel so its inactive simply i think
20:52 RealBadAngel client doesnt send anything back to server
20:53 RealBadAngel but i can add there try just to be sure
20:53 VanessaE my servers are unpatched/vanilla minetest engine (and a few commits behind, by now I'm sure)
20:55 RealBadAngel ah i see now. it will work until old server is not using any HUD mods
20:55 RealBadAngel if it does then that "try" is needed
20:55 RealBadAngel i will add it right now
21:03 EvergreenTree joined #minetest-dev
21:03 EvergreenTree joined #minetest-dev
21:22 RealBadAngel ShadowNinja, ive added try on that new parameter
21:23 RealBadAngel https://github.com/minetest/minetest/pull/1112/f​iles#diff-34f48ad91ac6c202ac60b0348ae90e30R1944
21:48 ImQ009 joined #minetest-dev
21:50 AllegedlyDead joined #minetest-dev
21:54 ShadowNinja There are two more section positions to be filled, release and community.  hmmmm has handled releases for a while, so maybe he should do that.  What do you think about community?  That person whould probably the primary manager/owner of the G+/FB/etc page and the like.
21:57 * VanessaE backs away, slowly...
22:01 ImQ009_ joined #minetest-dev
22:20 Sokomine you're trying to find someone here who'll be willing to maintain a g+/fb site? i'm afraid that might turn out to be a difficult search
22:20 RealBadAngel call it a quest. a very tough one ;)
22:21 Sokomine might be very hard indeed :-)
22:51 rsiska joined #minetest-dev
23:27 iqualfragile joined #minetest-dev
23:30 VanessaE sapier1: *poke*

| Channels | #minetest-dev index | Today | | Google Search | Plaintext