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

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/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
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/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: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/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: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-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		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/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 <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/files#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

← Previous day | Channels | #minetest-dev index | Today | Next day → | Google Search | Plaintext