| Time |
Nick |
Message |
| 00:44 |
|
celeron55 joined #minetest-dev |
| 01:08 |
|
VanessaE joined #minetest-dev |
| 01:08 |
|
Taoki joined #minetest-dev |
| 01:11 |
|
VanessaE joined #minetest-dev |
| 01:12 |
|
VanessaE joined #minetest-dev |
| 01:23 |
|
VanessaE joined #minetest-dev |
| 01:32 |
|
celeron55 joined #minetest-dev |
| 02:10 |
|
celeron55 joined #minetest-dev |
| 02:52 |
|
celeron55_ joined #minetest-dev |
| 03:17 |
|
celeron55 joined #minetest-dev |
| 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 |
| 04:00 |
|
proller joined #minetest-dev |
| 05:42 |
|
BackupCoder joined #minetest-dev |
| 06:30 |
|
SpeedProg joined #minetest-dev |
| 07:56 |
|
jin_xi joined #minetest-dev |
| 09:34 |
|
ecube_ joined #minetest-dev |
| 09:37 |
|
darkrose joined #minetest-dev |
| 09:56 |
|
prestidigitator joined #minetest-dev |
| 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? |
| 10:15 |
|
darkrose joined #minetest-dev |
| 10:48 |
|
proller joined #minetest-dev |
| 10:54 |
|
darkrose joined #minetest-dev |
| 11:03 |
|
iqualfragile joined #minetest-dev |
| 11:07 |
|
darkrose joined #minetest-dev |
| 12:18 |
|
iqualfragile joined #minetest-dev |
| 13:16 |
|
hmmmm joined #minetest-dev |
| 13:23 |
|
troller joined #minetest-dev |
| 13:25 |
|
proller joined #minetest-dev |
| 13:28 |
|
nyuszika7h joined #minetest-dev |
| 13:30 |
|
nyuszika7h joined #minetest-dev |
| 13:51 |
|
darkrose joined #minetest-dev |
| 13:51 |
|
darkrose joined #minetest-dev |
| 13:51 |
|
proller joined #minetest-dev |
| 13:59 |
|
troller joined #minetest-dev |
| 14:02 |
|
proller joined #minetest-dev |
| 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 |
| 15:03 |
|
PilzAdam joined #minetest-dev |
| 15:27 |
|
Taoki joined #minetest-dev |
| 15:31 |
|
serengeor joined #minetest-dev |
| 16:21 |
|
iqualfragile joined #minetest-dev |
| 16:46 |
|
Jordach joined #minetest-dev |
| 16:46 |
|
Jordach joined #minetest-dev |
| 17:10 |
|
Calinou joined #minetest-dev |
| 17:13 |
|
dimeshake joined #minetest-dev |
| 18:01 |
|
BackupCoder joined #minetest-dev |
| 19:01 |
|
proller joined #minetest-dev |
| 19:17 |
|
mrtux joined #minetest-dev |
| 19:26 |
|
troller joined #minetest-dev |
| 19:35 |
|
PilzAdam joined #minetest-dev |
| 20:34 |
hmmmm |
proller, huh? |
| 20:34 |
hmmmm |
what's going on with json? |
| 20:39 |
|
sapier1 joined #minetest-dev |
| 20:42 |
|
serengeor joined #minetest-dev |
| 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 |
