Time  Nick        Message
00:03 est31       #3230
00:03 ShadowBot   https://github.com/minetest/minetest/issues/3230 -- Better gettext support for protocol version mismatch messages by est31
00:33 paramat     papyrus/biome tweak merging soon game#696
00:33 ShadowBot   https://github.com/minetest/minetest_game/issues/696 -- Papyrus: Grow on dirt and grass only, remove from desert ocean by paramat
00:45 paramat     now merging game 695 and 696
00:50 paramat     complete
01:02 paramat     now merging #3223
01:02 ShadowBot   https://github.com/minetest/minetest/issues/3223 -- Mgv5: getGroundLevelAtPoint searches a larger range by paramat
01:06 paramat     complete
02:16 paramat     http://i.imgur.com/yX6BaLQ.png hybrid dungeon
02:18 VanessaE    looks like a geometry argument is mandatory now:
02:18 VanessaE    GD Warning: product of memory allocation multiplication would exceed INT_MAX, failing operation gracefully
02:18 VanessaE    bash: line 1: 25953 Segmentation fault      ./minetestmapper --drawscale --drawalpha -i $worldpath"/"$worldname"/" -o $imagepath"/"$worldname".png"
02:19 VanessaE    (without a geometry arg to limit the size, I guess it does the whole world now, and throws that ^^^ error)
02:24 VanessaE    (also, I'm pretty sure a segfault is rather opposite of "graceful" :P )
02:33 kahrl       rather graceful if you ask me. I mean, it doesn't rewrite random mapblocks in the database and corrupt them
02:34 VanessaE    maybe. heh
02:34 VanessaE    still pretty sure a crash is unwanted ;)
02:36 kahrl       probably just a missing return value check somewhere
02:38 VanessaE    a feature that I think would be useful is if the mapper tool could slice the output image into several smaller pieces
02:38 VanessaE    (say max 4096x4096 or so)
02:39 kahrl       https://github.com/minetest/minetestmapper/blob/master/TileGenerator.cpp#L349
02:39 kahrl       this is where a NULL check is missing, I think
03:14 VanessaE    est31:  leaftest needs a tweak -- geometry arg for minetestmapper takes X:Y+W+H but you have X,Y+W+H (comma instead of colon).
07:33 hmmmm       wow, caverealms is a pretty cool mod
07:34 hmmmm       i haven't been able to reproduce that crash yet, however
07:41 hmmmm       unfortunately the slowness of block loading among other things breaks player immersion and ruins something that otherwise would be very neat
07:42 nrzkt       you are right
07:43 nrzkt       this is a pain to wait for map loading many times... :(
07:43 hmmmm       specifically with map generating mods
07:43 hmmmm       i have an idea though it's a lot of effort
07:44 nrzkt       why not having a lock per mapblock ? EmergeThread commit directly to map with a lock on the mapblock memory area itself instead of the whole map
07:44 hmmmm       there are a lot of mapblocks dude
07:44 nrzkt       yes, but an intelligent locking system, allocate locks at mapblock first creation
07:44 hmmmm       if the platform in question does not implement pthread_mutex_* as a futex then that would wreak havoc on the OS
07:45 nrzkt       futex ?
07:45 hmmmm       user-mode mutex
07:45 nrzkt       i see :)
07:46 hmmmm       freebsd and linux do this with pthread_mutex_ functions, and Windows does if you use "critical sections"
07:46 hmmmm       in other words, on windows, CreateMutex() et al.  are NOT user mode mutexes
07:46 hmmmm       you need to be careful there
07:46 hmmmm       in any case, an idea I would be more open to is maybe a "locking region" or some shit
07:47 hmmmm       which might be defined as a 4x4x4 cluster of mapblocks...?
07:47 hmmmm       shrug
07:47 hmmmm       even if you do this, there's still an enormous amount of work
07:48 nrzkt       8x8x8 ? :)
07:48 hmmmm       small steps first
07:48 hmmmm       break up envlock into maplock, playerlock, objectlock, etc.
07:49 hmmmm       then when we get that working really well, then we'll look into breaking up maplock
07:52 nrzkt       i do it in a separate branch
07:52 nrzkt       i have map_lock and SAO_lock
07:52 nrzkt       i did*
08:00 nrzkt       technically this separation is not a problem
08:19 Megaf       Hi all, little help please, So, I updated my server today and now this happens
08:19 Megaf       https://paste.debian.net/plain/314451
08:20 Megaf       I'm afraid it had overwriten my world =/
08:22 Megaf       Ok, it might not be a minetest fault
08:26 Megaf       ok, nevermind, I think is not minetest fault this time, game on
08:31 nrzkt       it's you
08:32 nrzkt       +x missing
08:32 Megaf       Thanks
17:05 est31       I dont like locks as they might allow for deadlock
17:05 est31       e.g. what if you have a mod that has a mob that modifies the map
17:06 est31       e.g. on its on_step, it automatically farms
17:06 est31       so you aquire the map lock while holding the object lock
17:06 est31       now what if sth else has the map lock and wants to spawn an object?
17:07 est31       e.g. you place a windmill block, and it has a rotating part
17:07 est31       which is an object
17:07 est31       --> deadlock
17:07 est31       better is an event system, asynchronous
17:08 est31       we could introduce the rule that you can't aquire more than one lock
17:08 est31       then the modders would have to use event util functions we provide for them to avoid that situation
17:09 est31       This would be a hybrid approach
17:10 hmmmm       lol
17:12 hmmmm       that's pretty silly.  this is a non-problem.  a deadlock is a bug you encounter from using locks in the wrong manner.
17:12 nrzkt2      agree with hmmmm
17:15 hmmmm       although I agree it's going to be tough to interface this properly with mods
17:15 hmmmm       modders are generally incompetent and they don't actually understand what it is they're coding
17:15 hmmmm       you get a handful who actually know what's going on and they write their own mods, and then everybody else copies and pastes from the working mods
17:16 hmmmm       but they introduce subtle differences and bugs that didn't exist in the original version
17:16 est31       I dont want to get deadlocks regardless of what modders code
17:16 hmmmm       I'm floating around the idea of letting mods control envlock in a limited manner
17:16 est31       part of the "manner in which we use locks" isnt influenced by us
17:17 hmmmm       maybe mods will only have access to envlock
17:17 hmmmm       and then when envlock gets split up, envlock will become multiple locks underneath but still appear as one single lock to the mod interface
17:17 hmmmm       this helps keep things simple
17:18 est31       ermmm
17:18 est31       so what does splitting up envlock use then?
17:18 hmmmm       there's a lot more engine code than there is mod code
17:18 est31       i mean you cant run a mobs mod parrallel to a mod that affects nodes only then
17:19 est31       well, okay, that would be a good first step
17:20 est31       engine side only split up
17:22 est31       hmmmm, is it a bad goal to not allow modders to introduce deadlocks? you agree to it?
17:22 est31       and nrzkt2
17:23 hmmmm       I agree that it needs to be made safe
17:23 hmmmm       that's the number one reason why nothing has been done with regards to locks
17:24 est31       argh #3231
17:24 ShadowBot   https://github.com/minetest/minetest/issues/3231 -- Server Error: A fatal error occurred: Invalid position (expected table got nil).
17:24 hmmmm       i've been persuaded by VanessaE to give modders a chance however
17:24 hmmmm       maybe they will be able to 'rise to the challenge' of synchronization
17:25 est31       yet another somebody who has encountered a crash, and submits it without any info
17:25 hmmmm       I mean it may have took a while but it seems they're able to use LuaVoxelManip without problems now
17:26 est31       still bad it does no range checking
17:27 est31       easily exploitable
17:27 est31       hrmm, perhaps I try precisely that later on...
20:27 eugd        i'm going to ask it again; mapblock->octree?
20:27 Krock       PLease code it for us.
20:27 eugd        ha, ok
20:28 eugd        just trying to brainstorm stuff
20:28 eugd        as far as i can reckon it wouldn't suffer transversal problem
20:32 eugd        is everyone in agreement with paramat regarding #3199>
20:32 ShadowBot   https://github.com/minetest/minetest/issues/3199 -- split map_generation_limit into x/y/z components by EUGD
20:32 eugd        just change the name?
21:51 paramat     sfan5 ShadowNinja any comments to add on https://github.com/minetest/minetest_game/issues/480#issuecomment-145301062 ?
21:56 paramat     hmmmm sometime can you add comments to #3199? my opinion is here https://github.com/minetest/minetest/pull/3199#issuecomment-144213976
21:56 ShadowBot   https://github.com/minetest/minetest/issues/3199 -- split map_generation_limit into x/y/z components by EUGD
21:59 paramat     btw AFAICR caverealms is slow due to placing lots of schematics (each with a separate lighting update)
22:09 hmmmm       you mean it doesn't register the schematics to be placed on map generation?
22:10 paramat     it might use 'place schematic' ... i might have misremembered
22:10 hmmmm       what the hell... why
22:11 paramat     the biome api can't place schematic decorations in some situations
22:11 paramat     so i see modders using 'place schematic' during lua mapgen
22:11 paramat     we need a way to blit a schematic into the lvm
22:12 hmmmm       well why don't they say something about it instead of using an extremely inefficient function as a workaround
22:12 est31       eugd, I like ShadowNinja's idea as well
22:12 eugd        i'm looking at the code now
22:12 paramat     i should check caverealms code ..
22:13 eugd        but i still really don't like it, for the reasons i said in the comment page
22:13 est31       what was it again
22:13 ShadowNinja Hmmm?
22:13 est31       https://github.com/minetest/minetest/pull/3199#issuecomment-143392234
22:14 paramat     eugd it's okay if you don't want to make the PR, someone else can
22:14 eugd        can actually do it in one, i think
22:14 ShadowNinja Ah, thanks.
22:14 eugd        no i'm working on it now, i just increasingly dislike it overall
22:14 eugd        really should be part of map structure
22:15 eugd        piling hacks on top of hacks
22:15 kahrl       I agree that it should be map metadata
22:16 paramat     hmmmmm i was wrong about caverealms, no heavy use of schems
22:16 ShadowNinja kahrl: Good point, you'll have issues with multiple worlds other wise.
22:17 est31       yea kahrl is right
22:18 paramat     oh per world ..
22:18 est31       better having it be map metadata
22:18 est31       but that has nothing to do with having it as setting
22:24 paramat     agreed, if we have map gen limit at all it should be per-world
22:25 est31       well we do need one
22:25 est31       as our addresses are limited :)
23:43 eugd        this settings code is, bad.
23:43 eugd        like half of it is unused
23:43 eugd        i'm trying to sus out the 'standard' for doing this but there isn't really one
23:56 est31       okay, what about not doing it?
23:56 est31       and waiting until it becomes a param for the map?