Time  Nick      Message
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.
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: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)