Time  Nick            Message
03:57 hmmmm           pfffffoooo
03:57 VanessaE        p'tooie
03:57 hmmmm           it was unnecessary to loop through each light bank when calculating the lighting in the mapgen
03:58 hmmmm           i wonder what the total amount of wasted CPU time that adds up to, for all the minetest players, plus all their frustration in waiting for a chunk to be generated
03:59 hmmmm           vanessa, nevermind about the 10x speedup.  i am able to do more like 40x
04:00 hmmmm           the lighting calculation is really neat, elegant code (algorithmically speaking), but it just doesn't scale
04:00 VanessaE        sweet
10:01 prestidigitator Hello.  Is there anyone here who might be able to help answer a pretty specific question about a base terrain mapgen function?
14:10 proller         celeron55, hmmmm maybe make set-getNoiseParams in new mapgen settings in json ?
14:12 proller         0, 1, (250, 250, 250), 9130, 3, 0.50, 1   -> ("p1"=>0, "p2"=>1, "vec" => [250, 250, 250], "p3"=>9130, .... but with good names and skipping default values
20:34 hmmmm           proller, huh?
20:34 hmmmm           what's going on with json?
20:42 VanessaE        oh G*d please don't overcomplicate MT config files with json crap
20:43 sapier1         I've just completed initial implementation of a pathfinding algorithm within core, it's still work in process but I'd apreciate if someone would test this: https://github.com/sapier/minetest/tree/pathfinding
20:43 sapier1         -process + progress
20:45 sapier          btw is there any reason why minetest is compiled -O1 even in debug mode?
20:46 troller         hmmmm, noise params strings like "mgindev_np_terrain_base",   "-4, 20, (250.0, 250, 250), 82341, 5, 0.6, 1"
20:46 troller         make it key-value
20:49 celeron55       sapier: to make it perform reasonably
20:50 celeron55       developers (at least me) always run a debug build even while player, and it being slow isn't fun
20:50 celeron55       s/player/playing/
20:51 sapier          yes but -O1 isn't quite comfortable if you really do gdb debugging
20:51 celeron55       it generally is just fine
20:53 sapier          you wouldn't say that if you'd been searching for an index bug for hours because your indices where optimized out ;-)
20:54 sapier          and yes after finding it it was quite easy ... but it didn't really show up next to index related things but about 6 stack levels below ;-)
20:55 celeron55       index bugs are pretty much the only thing -O1 makes more difficult, and you can just set -O0 in the file temporarily then
20:56 sapier          yes but you need to know or at least already guess it's a index bug too do that ;-)
20:57 celeron55       i suggest just not making index bugs 8)
20:57 sapier          lol for that reason you could enable -O3 optimization and not make any bugs at all ;-P
21:01 sapier          Hope no one takes the -O3 suggestion for real ;-)
21:03 VanessaE        fwiw, I just built the client with -O3 (not debug) and it seems to work.
21:03 sapier          -O3 does work most of time quite good but it doesn't always improove performance
21:04 VanessaE        I figured it was worth a look is all.
21:04 sapier          and for rare occassions when code isn't very well it shows up bugs not being recognized before
21:05 sapier          another topic, are there any comments (except "I generally don't want security") about the new implementation:  https://github.com/minetest/minetest/pull/495
22:13 hmmmm           troller, i don't see a reason why we should change how structures are parsed, why doesn't what we have work well enough?
22:44 sapier          seems the stl changes messed  up mod name sorting algorithm
22:47 sapier          whoever did this should double check all iterator changes they aren't valid anymore as soon as list is modified!
22:47 sapier          at least not within stl
22:54 sapier          ok I've checked again it's iterators may not be valid ... this explains why it doesn't fail everytime
23:00 sapier          ok forget about above comments the iterator has nothing to do with the bug
23:19 sapier          seems I'm not the only one not checking things very well on checking ... scriptapi 909 this has to be "mods_sorted.end()" it can't ever terminate if you check a iterator of mods_sorted against the end of mods_unsorted ;-)
23:24 hmmmm           well so much for push n' pray
23:24 hmmmm           the praying evidently didn't help
23:27 sapier          just pull my fix ;-)
23:27 hmmmm           where is the commit for it
23:28 sapier          I've already got bug reports against mobf that my development version would stop minetest from starting :-) so those ppl didn't realize it's a core problem :-) https://github.com/minetest/minetest/pull/547
23:29 sapier          maybe the algorithm terminates in very special memory constelations :)
23:29 hmmmm           alright i guess i'll do some merging
23:30 hmmmm           this and the clouds thing
23:30 sapier          btw I've just recognized mintest is crashing on "exit to os" instead of shutting down ;-)
23:31 hmmmm           wouldn't surprise me
23:31 hmmmm           not a very critical bug though
23:31 sapier          http://pastebin.com/TAdAW0Je
23:31 sapier          no not critical seems to be some race condition in on_generate code
23:33 hmmmm           well what was the script error?
23:33 hmmmm           shouldn't it have printed something out?
23:33 sapier          what():  LuaError: error: attempt to index a number value
23:33 hmmmm           attempt to index a number value... wtf
23:34 hmmmm           so i am guessing it's like this
23:34 sapier          as you said not critical
23:34 hmmmm           serverthread, which created the lua objects, was terminated first, which causes those things to be deleted, so when the emergethread is running lua things, it crashes
23:35 sapier          imho problems like that could be handled best if scriptapi was unlinked from server and environment
23:35 hmmmm           i think it's my fault, i honestly forget in which order the threads were stopped before the new emerge code
23:36 sapier          so scriptapi module knows about current condition of lua stack and could simply skip any scriptapi* call if there isn't avalid stack
23:36 sapier          multithreading would be improoved to if scriptapi could act like a "gatekeeper" to lua stack
23:37 sapier          there's no need server or environment to know anything about scriptapi's internal datastructures ... e.g. lua could be vb, python or whatever
23:50 hmmmm           way more complicated than just fixing the race condition
23:50 hmmmm           woo way to go shadowninja, the current clouds code doesn't even compile, he's missing a semicolon
23:51 hmmmm           i need to review this code hardcore before committing it.
23:52 sapier          did anyone review the stl changes for other bugs? don't get me wrong I absolutly positive stl should be used instead of irrlicht.
23:53 hmmmm           no, there are way too many modifications, just hoping that other things don't pop up
23:54 sapier          I hope they do pop up soon as it gets more and more complicated to track things down the more additional commits are in between
23:55 sapier          changes that big rarely are without mistakes