| 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 |
