Time Nick Message 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 12:38 xyz sfan5: https://github.com/sfan5/irrlicht-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 13:09 RealBadAngel celeron55, u here? 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/forum/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: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/commit/2d63973d5e4bf0371b88f625c694d1c864b2f45e#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: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 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: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 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: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 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 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 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: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 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: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 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-technic/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 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: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 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/Penlight/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 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: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] = ? 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 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: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:29 VanessaE proller: is that you on my almost-vanilla server? 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: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:22 RealBadAngel ShadowNinja, ive added try on that new parameter 21:23 RealBadAngel https://github.com/minetest/minetest/pull/1112/files#diff-34f48ad91ac6c202ac60b0348ae90e30R1944 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: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 :-) 23:30 VanessaE sapier1: *poke*