Minetest logo

IRC log for #minetest-dev, 2013-09-27

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

All times shown according to UTC.

Time Nick Message
00:18 werwerwer_ joined #minetest-dev
01:57 loggingbot_ joined #minetest-dev
01:57 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
02:09 IceCraft joined #minetest-dev
02:16 kahrl Awww, I give up. I can't think of a good libmtmap interface that doesn't pull in half of the minetest server and is C.
04:10 SpeedProg joined #minetest-dev
04:18 ImQ009 joined #minetest-dev
04:22 salamanderrake joined #minetest-dev
04:27 Miner_48er joined #minetest-dev
05:10 neko259 joined #minetest-dev
06:13 darkrose joined #minetest-dev
06:13 darkrose joined #minetest-dev
06:43 Calinou joined #minetest-dev
07:37 Ritchie_ joined #minetest-dev
08:19 VanessaE kahrl: what about just giving the server binary a simple command-line API?  not as good as a dedicated lib but maybe it'll be useful somewhere?
08:19 Calinou ability to type commands in server console would be cool
08:19 Calinou but I'm not sure if that's related
08:20 VanessaE not related.
08:20 VanessaE this is for backend-independent access to the map data
08:20 kahrl well one of the goals is writing minetestmapper with it
08:20 kahrl I guess it could be done that way, but it might be slow
08:20 VanessaE slower than the python one? ;)
08:21 kahrl maybe :P
08:21 VanessaE I was thinking something really simple like,  minetestserver --worldname foo/blah --fetchblock 1,2,3  --> block is fetched and dumped to stdout
08:22 VanessaE (and a --stashblock or --writeblock or however you'd name it, of course)
08:22 kahrl ah, in that case you'd even have to start a new process for every block
08:22 VanessaE yeah I know
08:22 VanessaE that's the big drawback
08:22 kahrl not to mention re-initializing minetest and reopening the database
08:23 celeron55 probably something like --fetchnodes -100,-100,-100,100,100,100
08:23 VanessaE celeron55: +1
08:23 VanessaE didn't consider the idea of a block range
08:23 celeron55 but that's not really a full solution to anything generic... except for the mapper
08:23 VanessaE right, and even there it has limited utility
08:24 VanessaE I'm just thinking of kahrl's exasperation :P
08:25 VanessaE I figure if you have to pull in "half of the server", it may be simpler to use the whole damn thing
08:27 celeron55 i don't really see why one'd need to pull in half of the server; the key would be to include actual decoding of data for only certain things and i/o the rest as binary blobs
08:30 celeron55 and make it able to generate empty versions of the blobs if needed
08:30 kahrl for example, when deserializing the bulk node data
08:31 kahrl correcting the node ids in a block is easy: just require the user to provide callback to get node ids
08:31 kahrl +a
08:32 kahrl but if the mapblock version is 22 or lower, it requires knowing individual node definitions, to handle legacy_facedir_simple and legacy_wallmounted
08:34 kahrl of course, we could say that maps from before 0.4.dev-20120122-1 that used non-minetest_game nodes with legacy_facedir_simple and legacy_wallmounted are not supported
08:34 kahrl and compile in a hardcoded list of node names
08:35 kahrl maybe provide an API to add nodes to that list
08:42 kahrl s/22 or lower/21 or lower
08:43 celeron55 doesn't sound that much of a problem
08:49 caemir joined #minetest-dev
08:52 VanessaE do older maps get migrated as the server is updated?
08:53 VanessaE (I forget now)
08:55 kahrl VanessaE: nope, blocks are migrated as they are loaded
08:55 kahrl brb
08:55 VanessaE hm.  seems to me that the code that can migrate between databases might be leveraged to handle that part too.
09:03 celeron55 if we had actually working minor versioning, that could be used so that only the current and previous minor version is loadable
09:04 celeron55 as how stuff is done now, it would be way too obscure to figure out what migration steps would be required for what map
09:06 celeron55 (unless it's all done automatically for any version, which IMO completely misses the point of being able to drop compatibility via migration support)
09:36 Krock joined #minetest-dev
09:38 Semilevel joined #minetest-dev
10:15 jojoa1997 joined #minetest-dev
10:23 jojoa1997 left #minetest-dev
10:41 Akien joined #minetest-dev
11:07 Zeitgeist_ joined #minetest-dev
11:24 PilzAdam joined #minetest-dev
11:49 proller joined #minetest-dev
11:51 caemir left #minetest-dev
12:05 smoke_fumus joined #minetest-dev
12:26 hmmmm joined #minetest-dev
14:31 NakedFury joined #minetest-dev
15:11 IceCraft joined #minetest-dev
15:46 proller joined #minetest-dev
15:51 Calinou joined #minetest-dev
17:13 rubenwardy joined #minetest-dev
17:18 neko259 joined #minetest-dev
17:23 proller joined #minetest-dev
17:59 kaeza joined #minetest-dev
18:02 Jordach joined #minetest-dev
18:16 rubenwardy left #minetest-dev
18:34 Krock joined #minetest-dev
18:35 neko259 joined #minetest-dev
19:24 jojoa1997 joined #minetest-dev
19:39 OWNSyouAll_DESKT joined #minetest-dev
19:43 OWNSyouAll_DESKT joined #minetest-dev
19:51 OWNSyouA1 joined #minetest-dev
20:07 Krock joined #minetest-dev
20:35 ImQ009 joined #minetest-dev
21:46 NakedFury joined #minetest-dev
22:39 hax404 joined #minetest-dev
22:54 Miner_48er joined #minetest-dev
22:58 NakedFury joined #minetest-dev
23:18 kaeza joined #minetest-dev
23:50 Weedy joined #minetest-dev

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