Time Nick Message 00:10 est31 this is a statement by a debian packager about small point releases: https://github.com/minetest/minetest/issues/2610#issuecomment-167263938 00:11 est31 every of our releases is small point now hehe 00:12 est31 this bug would highlight a case where we could do small point releases 00:12 est31 but idk 00:12 est31 before long calinou shows up and proposes to release all two weeks 00:12 est31 bc we arent a distro 00:13 est31 then other ppl show up and want us to not do any features anymore, just bugfixes 00:13 est31 release discussions are always the same 00:14 est31 pilzadam knows it: we talk alot, and at the end everything stays the same 00:14 est31 sapier, i know find_node_near can be abused sorta yes 00:15 est31 but idk limiting it feels just wrong 00:15 est31 if people want sth fast and with a long radius they should use areastores 00:16 est31 these scale super well 00:16 est31 well, the only issue is that areastores are fully held in RAM 00:16 est31 but other than that, they scale well. 00:17 est31 (and one can write the extension to use disk storage as well) 00:17 sfan5 does that mean we'll be considering doing a release soon-ish? 00:17 sapier I didn't wanna suggest limiting it but maybe adding same check as for ABM time 00:17 sapier ppl tend to not realize HOW bad it is ... myself included 00:18 sapier I think I found a solution ... causing way more cpu load in total but reducing lag to < 123ms 00:19 sapier well solution is a lot of code but quite simple 00:20 sapier instead of checking full cube at once I split check to shell by shell base ... guess it's still gonna fail if you try to check radius 1000 ;-) but at least till 40 it's quite useable 00:20 est31 doesnt it already work shell by shell 00:22 sapier nope 00:22 sapier shell by shell in different steps 00:23 sapier current one tries to check all shells in same step 00:25 est31 what is "step" for you 00:25 sapier of course I had to implement this in lua and can't use the way more fast c++ functions any longer 00:25 sapier serverstep 00:25 est31 so why do you have to implement it in lua 00:25 est31 I dont understand 00:25 sapier the thing that causes lag 00:26 est31 is c++ less powerful 00:26 sapier in this case yes 00:26 est31 why 00:26 sapier because I'd need way more infrastructure to do this in c++ 00:27 sapier basically I'd need ot have the lua async api as well as event handling in place 00:27 est31 the async api is useless it doesnt reduce lag in any way 00:27 est31 or well 00:27 sapier if you use it correct it does 00:28 est31 it can run while c++ runs 00:28 est31 but still you need envlock 00:28 sapier async api is only part of the work to be done for it to completely work 00:28 est31 so whats running in minetest whats outside of envlock 00:29 sapier as I said async api is only part for it to gain full benefit we need partial maplocks too 00:30 est31 yeah 00:30 sapier till this is done reducing lag by spliting a part to small pieces is the only way to reduce lag 00:30 est31 minetest's infrastructure isnt right for changes like you propose 00:30 sapier and as this is extremely specific to a particular task you can only do it in lua 00:30 est31 isn't ready I mean 00:31 est31 if you added it now it would just mean additional overhead without any benefit. 00:31 est31 and the current async api isnt the way forward either 00:31 est31 it isnt true multithreading 00:32 est31 just lending out the lua global lock to some async thread 00:32 est31 or is it? 00:32 sapier I don't undestand your point the api itself is completely capable of doing multithreaded operation 00:32 sapier everything else is implementation detail 00:33 sapier imho it's better to have a clean api in place and extend it's capabilities later then having some half grown half implemented wannabe api in place 00:33 est31 is the async api even available outside of mainmenu 00:34 est31 i cant find it in lua_api.txt 00:34 sapier no it can't be used. as I said it's never been completed 00:35 sapier mainmenu was just first usage for it but I didn't continue the work ... I'd continue now but for what I remember hmmmm is already working on it so I don't wanna wast his or my time 00:36 est31 I think what hmmmm wants to get in the end regarding the async api is very fine 00:37 est31 i remember conversations with him 00:37 sapier I believe to remember this way too yet async api to gain full benefit requires splitting the envlock ... I started that work too 00:38 sapier well I added the check to find out where we need it ;-) so not very much is done by now 00:38 est31 but yeah, I guess this would be something ideal for using async operation and a split up maplock 00:38 sapier right now async api could only boost numbercrunching 00:38 est31 (this = find_nodes_near) 00:38 est31 and there isnt much numbercrunching in minetest 00:39 sapier e.g. if someone wrote a mapgen capable of doing everything in it's own data and write it to map in a later step 00:39 est31 yeah 00:39 sapier I don't see a lot of other tasks that would benefit 00:40 sapier almost everything else requires access to map 00:40 est31 but there is always overhead for copying the stuff between async threads to main thread 00:40 sapier true and that's something you can't avoid thus have to make it more performant 00:40 sapier async thereads aren't lightweight 00:40 sapier for small tasks they're useless 00:41 est31 yeah 00:41 sapier async is only worth if you have to do a couple of seconds of computing time 00:41 est31 thats why i think its bad idea to use async api for find_node_near if the radius is smaller than, say, 10 00:41 est31 and in most cases it is just 10 or so 00:41 sapier yes 00:42 sapier imho a warning similar to the abm warning telling ppl what just happened would be more then enough 00:42 est31 then they know where the lag comes from? 00:42 sapier maybe adding another parameter to it would be worth thinking about too 00:43 est31 idk, best would be pie chart or sth 00:43 sapier min radius 00:43 sapier thus you could check in steps 00:43 est31 mhhh min radius 00:43 sapier est31: there's a mod profiler in minetest you can se which mods cause lag 00:43 est31 yeah sounds simple enough and useful enough 00:44 sapier mod_profiling = true 00:44 sapier detailed_profiling = true 00:44 est31 mod profiler is cool 00:44 est31 i know 00:45 sapier mod profiler is one of the pieces I managed to get from mobf to core ;-) 00:45 est31 does that mean we'll be considering doing a release soon-ish? <---- well this apoleon wanted some point release because we fixed his bug 00:46 est31 point releases would be novel 00:46 est31 and we would need a way to distinguish them from usual releases 00:46 est31 and it would introduce problems, we'd need version branches or so 00:46 sapier I've plenty of usefull pieces there yet nothing as helpfull as mod profiler :) 00:47 est31 t4im greatly improved it 00:47 est31 idk whether its integrated into the engine already 00:47 sapier mod profiler? 00:47 est31 https://github.com/t4im/profiler 00:48 sapier nice why hasn't this been merged by now? 00:48 Fixer can i use mod profiler on RELEASE build? 00:48 est31 idk 00:49 sapier1 Fixer: profiler is lua only so you should be able to 00:50 Fixer it feels like server guys do not use it often enough, it should endorsed 00:50 sapier1 actually no 00:50 Fixer should be* 00:50 sapier1 you shouldn't run it permanent as it causes overhead 00:50 Fixer to look what things are laggy 00:50 sapier1 modders should run it 00:50 Fixer no, just for troubleshoot 00:51 sapier1 oh yes that's what it's been meant for 00:51 Fixer yeah 00:51 sapier1 vanessae and myself did find a lot of issue using it 00:51 Fixer I've advised people to try it to look what is lagging so badly, but I never seen actual results %) 00:53 est31 it cant detect engine lag 00:53 sapier1 nope but usually you do not have engine lag but mod lag 00:53 est31 if a mod spawns a million rats, the overhead might not be large 00:53 est31 in the profiler 00:53 Fixer i mean at least mod lags 00:53 est31 but the engine will have lag 00:54 sapier1 actully you'd see the spawning of a million rats in profiler 00:54 est31 yeah bad example 00:54 est31 I should go to bed 00:55 sapier1 usually you find things like the find_nodes_in issue 01:00 sapier1 but still it's modders to think about how to split what they have to do to small pieces ... at least if they do have mods that do bigger things :-) 04:04 lemon hello 19:57 sofar I'd like to merge this (later, not just yet) into minetest_game itself: 19:57 sofar https://forum.minetest.net/viewtopic.php?f=9&t=13732&p=201429#p201429 19:57 sofar would appreciate if people can comment on whether that would be something that would be mergable 19:58 sofar since implementing it as a standalone mod is very cumbersome (I'd basically have to redefine lots of /doors/ code to override the handler functions) 19:59 sofar and as a patch to minetest_game it's ... well tiny amounts of code, really 21:33 sofar how do I edit probability values for mts files? is there an editor of some sorts? 21:34 sfan5 nope 21:34 sfan5 you're gonne have to jump into a hex editpr 21:34 sofar vi -b? 21:34 sfan5 -p 21:35 sofar well that's rough 21:36 sfan5 actually no that won't work 21:36 sfan5 mts files contain compressed data 21:36 sfan5 tl;dr it's a lot of work, don't do it unless you need to 21:38 sofar well I want to add some better trees 21:38 sofar so, no choice 21:42 sofar you know 21:43 sofar sfan5: all it needs to fix that problem is to have an in-game tool that edits node metadata and adds the probability, and a modified schematic save tool to read/convert that to the mts probability format 21:44 kaadmy worldedit has schematic chances 21:47 sofar euh, it's rather ... crude 21:48 sofar no idea what number I'm putting in 21:48 kaadmy 0-255 iirc 21:48 sofar 0.1 ? 10? 1/10? 21:49 kaadmy 0-255 for chance of appearing, 255 is always, 127 is 50% 21:50 kaadmy yep, checked and it's correct(from checking the code) 21:50 kaadmy https://github.com/Uberi/Minetest-WorldEdit/blob/master/worldedit_commands/init.lua#L1130 21:52 sofar crashy, don't punch the wrong node :) 21:59 kaadmy heh 22:04 sofar well either worldedit's place doesn't use it properly, or half my probabilities are lost 22:04 sofar had a bunch of nodes with 75% not appear 22:05 sofar placed it 3x, total 12 nodes with 75% prob, not one appeared 22:05 kaadmy 75%=192? 22:05 sofar yeah 22:05 kaadmy hmm 22:06 sofar 128 and 16 work ok, afaics 22:07 sofar oh hey, WE calls minetest.place_schematic() 22:07 sofar maybe a restart is needed 22:08 * sofar not sure if he wants to fight that battle today 22:09 sofar tried making normalmaps yesterday, failed at that too