Time  Nick        Message
00:43 hmmmm       absolutely, you'll get better quality feedback that way
00:43 hmmmm       just make sure it's clearly marked as WIP and you're looking to get feedback from people
04:01 lhofhansl   Comments on #4959?
04:01 ShadowBot   https://github.com/minetest/minetest/issues/4959 -- Fix retrieving blocks in 3rd front camera view. by lhofhansl
12:13 nrzkt       mergin #4971 in some minutes
12:13 ShadowBot   https://github.com/minetest/minetest/issues/4971 -- Update Gettext version in Buildbot by sfan5
12:17 nrzkt       merged
12:19 nrzkt       same for #4864
12:19 ShadowBot   https://github.com/minetest/minetest/issues/4864 -- Use the outgoing split sequence number for every outgoing packet by Rogier-5
12:44 nrzkt       merged
14:24 est31       nice
14:33 nrzkt       same for #4864
14:33 ShadowBot   https://github.com/minetest/minetest/issues/4864 -- Use the outgoing split sequence number for every outgoing packet by Rogier-5
14:33 nrzkt       oops sorry :)
15:12 juhdanad    Hi! How does a map generator mod work? Is it necessary to call write_to_map or is it automatically done after on_generated ends?
15:14 Krock       I hope this help, juhdanad: https://github.com/SmallJoker/flatgen/blob/master/init.lua#L122-L130
15:14 Krock       *helps
15:14 Krock       the data is already set with set_data, so write_to_map could be left out
15:15 juhdanad    Thanks, this mod is perfect for experimenting!
15:15 Krock       other mods do it similar: https://github.com/paramat/asteroid/blob/master/init.lua#L333-L336
16:20 juhdanad    I need your suggestions!
16:21 juhdanad    There's a mod 'flatgen'. It uses singlenode mapgen with the nolight flag.
16:22 juhdanad    Therefore when on_generated is called, there are map blocks full of black air above the generated area.
16:22 juhdanad    And these mapblocks are marked as "generated".
16:23 juhdanad    Now, it would be logical to assume that there is a building or mountain above the generated area which casta the shadow.
16:24 juhdanad    This causes black patches in a newly generated world.
16:24 juhdanad    What should I do?
16:30 celeron55   flatgen should probably fill the above-ground mapblocks with sunlight
16:32 juhdanad    So mapgen mods should take care of lighting?
16:32 juhdanad    I thought it is the engine's task.
17:12 paramat     juhdanad erm, let me think on this
17:13 juhdanad    paramat Okay, thanks for your help!
17:13 paramat     mapgen mods that use 'nolight' in snglenode do it to avoid 2 lighting calculations
17:14 paramat     the first calculation is done is done after core mapgen when singlenode has just created chunks of empty air
17:14 paramat     (sorry double wording)
17:15 paramat     so that calculation is pointless, might as well wait until after the lua mapgen has added it's own stuff
17:16 paramat     so the lua mapgen does the light calculation in vm:calc_lighting
17:16 juhdanad    Would it break any mods if on_generated were called before any light calculation?
17:16 paramat     yes
17:17 paramat     well, probably
17:18 paramat     so yes, lua mapgen mods take care of lighting in vm:calc_lighting
17:19 paramat     they have to because they usually add stuff to core mapgen, or add stuff to empty air chunks in singlenode
17:20 paramat     some lua mapgen mods don't use 'nolight' for various reasons, especially if they are adding to core mapgen terrain.
17:20 paramat     also if a lua mapgen mod doesn't generate in every mapchunk then 'nolight' cannot be used
17:21 paramat     my lua mapgens are a mix of the 2 methods
17:22 juhdanad    On the other side, light calculation can be faster if light updating and writing to the map happen at the same time.
17:22 juhdanad    As I did in my PR.
17:22 paramat     (also in case you didn't know, the set 'water level' decides at which Y darkness is assumed if there is no generated mapchunk above)
17:23 juhdanad    So if you write a mapgen, you call update_lighting and then write_to_map, right?
17:24 paramat     'calc_lighting'
17:25 paramat     https://github.com/paramat/stability/blob/master/init.lua#L292 is the correct order
17:26 paramat     that's for mapgens that work in 'on generated', if a voxelmanip is used to alter a world after mapgen a different method is used: 'update_map'
17:27 juhdanad    Then I think write_to_map should check if it is a mapgen manipulator: if it is, then it just writes, otherwise it automatically calculates lighting to make it faster.
17:28 juhdanad    This is why #4967 deletes update_map
17:28 ShadowBot   https://github.com/minetest/minetest/issues/4967 -- New bulk node light update by juhdanad
17:28 paramat     the method for altering an existing world is this: https://github.com/paramat/catacomb/blob/master/init.lua#L444
17:29 paramat     where 'update_map' does the light calculation
17:30 paramat     afaik 'update_map' is a more complex lighting calculation, i think 'calc_lighting' is simplified due to asumptions that can be made due to it acting in 'on generated'
17:30 paramat     (assumptions)
17:31 paramat     you really should talk to hmmmm about this, when he has time
17:31 juhdanad    Yes, calc_lighting assumes that the map was darker before.
17:31 paramat     i think hmmmm will need to review your 2 lighting PRs
17:32 juhdanad    I'm looking forward to that :)
17:32 paramat     ah
17:33 paramat     yes any mapgen mod that doesn't use 'nolight' must use 'set_lighting(0)' first to set everything to darkness
17:33 paramat     https://github.com/paramat/pathv7/blob/master/init.lua#L433
17:34 juhdanad    (in that case calc_lighting is not really faster)
17:34 paramat     that mod adds roads to mgv7, and doesn't act in every chunk, so cannot use 'nolight'
17:34 paramat     hm
17:35 paramat     anyway, for examples of best mapgen mod practice see my recent mods (that sounds big headed but it's simply true heh)
17:38 paramat     "Is it necessary to call write_to_map" yes currently it is. hmmmm wrote the lua voxelmanip stuff btw
17:41 paramat     "Would it break any mods if on_generated were called before any light calculation?" yes, because a mod may use the existing light values in 'on generated'
17:42 * paramat   stirred up the pixie of doom
18:00 juhdanad    I'm testing my changes... Now stability and moretrees mods work together without lighting bugs!
18:05 paramat     with moretrees, have you fixed the very subtle shadows in water too?
18:06 juhdanad    Will see soon.
18:06 juhdanad    How frequents are the roads in pathv7?
18:06 paramat     see https://github.com/minetest/minetest/issues/3421#issuecomment-202032200 and following post
18:06 paramat     they can sometimes be very far apart
18:07 paramat     keep searching
18:07 paramat     possibly up to 1000 nodes apart
18:12 juhdanad    I found one! I like the lamps in the tunnels. And the lighting was correct.
18:14 juhdanad    And yes, subtle shadows are removed too.
18:19 paramat     because l-system treegen uses 'update lighting' it seems intended for use not in 'on generated' but moretrees uses it very soon after mapgen, which caused the dark black shadows due to chunks above not being generated
18:20 juhdanad    Yes, the top of the voxel manipulator is full of ignore nodes, which block sunlight.
18:21 paramat     yeah that was my suspicion
18:21 paramat     so essentially, don't worry if it's difficult or impossible to get l-system treegen working in 'on generated'
18:21 lhofhansl   #4951. I'm seeing actions rejected that should be legitimate.
18:21 ShadowBot   https://github.com/minetest/minetest/issues/4951 -- Various anticheat improvements by sfan5
18:22 sfan5       for example?
18:22 lhofhansl   Commented on the PR.
18:23 lhofhansl   ACTION[Server]: Player Lars tried to access  [node under=-179,23,193 above=-179,23,192] from too far: d=62.5343,  max_d=40. ignoring.
18:23 lhofhansl   I think the factor for max_d should sqrt(3) not 1.5.
18:24 lhofhansl   Since one could try to affect a node just in the furthest corner.
18:24 lhofhansl   Also the range of the wield-item and the hand are always -1, which I found strange. So it's always falling back to the default of BS * 4.0.
18:25 sfan5       that might be strange but it seems that that is how it works
18:25 sfan5       1.5 was chosen because it did not cause any problems in my tests
18:26 lhofhansl   I have not seen any case past 1.7. Which seems to match the math... sqrt(3) = 1.73
18:26 lhofhansl   I think we should change it to that
18:27 sfan5       yes it needs to be changed, why sqrt(3) though?
18:27 Krock       3d rooms, maybe?
18:27 lhofhansl   It's the diagonal of a cube.
18:28 Krock       pythagoras with X Y and Z, where it's sqrt(3) when each side is 1
18:28 sfan5       oh
18:28 lhofhansl   so the worst case is when you affect a node in the corner
18:28 lhofhansl   as seen from your position
18:29 Krock       I wonder why 1.5 was used
18:29 lhofhansl   (a unit cube that is, as Krock points out)
18:29 sfan5       Krock: read a few lines above
18:30 sfan5       hm does it make sense to use sqrt in the code for this?
18:30 Krock       oops. didn't read that
18:30 sfan5       since the value is static
18:30 lhofhansl   nah, just put 1.73 with a comment
18:30 lhofhansl   That's what we did at other places, for the occlusion culling for example.
18:31 lhofhansl   happy to do a trivial PR
18:31 Krock       why not a bit more, to give some tolerance? is the player's position really correct to that time?
18:32 lhofhansl   In all my tests I have not gotten beyond 40*1.73
18:32 sfan5       same here
18:32 sfan5       even while moving
18:32 lhofhansl   That seems quite safe. Could do 1.8 and call it a day.
18:33 lhofhansl   or maybe even 2. Wouldn't help much with cheating.
18:33 lhofhansl   I meant wouldn't help a cheater much :)
18:34 sfan5       0.07 would not be enough tolerance, digging has a tolerance of 1.2
18:35 juhdanad    Have you tested Vanessa's spiral stairs?
18:35 lhofhansl   Hmm... So 3? Although as I said, I have not been able to observe any problem with 1.73.
18:36 lhofhansl   It's was 14 before, so 3 is still a great a improvement.
18:36 juhdanad    If you dig it from above, node_under can be pretty far.
18:36 Krock       yeah, keeping it consistent and say factor 2 would be safe for any case
18:36 lhofhansl   So 2*1.73 then?
18:36 Krock       why 2* ??
18:36 juhdanad    why 1.73?
18:36 sfan5       <lhofhansl> It's the diagonal of a cube.
18:36 lhofhansl   sqrt(3) read above :)
18:37 juhdanad    But the player can reach a sphere, not a cube.
18:37 Krock       1.2 + sqrt(3) would mean we've got the same tolerances as digging, right? so that seems good
18:38 * Krock     hides
18:38 sfan5       Krock: 0.2 instead of 1.2
18:38 lhofhansl   Perhaps there's another problem too. In any case if you reach out up and sideways I get server logs like this:
18:38 lhofhansl   ACTION[Server]: Player Lars tried to access [node  under=-179,23,193 above=-179,23,192] from too far: d=62.5343, max_d=40.  ignoring.
18:39 lhofhansl   Biggest I've seen for 67.9.
18:39 sfan5       40 * sqrt(3) is 69.28203230275508
18:39 sfan5       so it really looks like we don't need any tolerance at all
18:39 lhofhansl   agreed.
18:40 garywhite   I think I figured out how to close the loophole that allows this hacked client to make no punch damage: Edit the engine to disallow negative damage (if that's possible, idk if healing uses negative damage to apply positive HP)
18:40 sfan5       http://sprunge.us/BhPK pushing this then
18:40 sfan5       if it turns out that tolerance is needed we can add it
18:41 Krock       depends if the player's position to calculate the distance is always correct
18:41 Krock       correct as in "up to date"
18:41 lhofhansl   perfect
18:41 sfan5       garywhite: we looked at it yesterday and didn't find a way to do this "negative damage" thing
18:41 juhdanad    I got it! The player can select items in a cubic area!
18:41 sfan5       pushed.
18:42 juhdanad    But the correct behavior would be to allow selecting nodes in a sphere, wouldn't it?
18:42 Krock       you point in a radius with fixed length, that's called sphere in a 3d room
18:42 Krock       so yes
18:48 juhdanad    So... The shootline is longer than it should be by one node: https://github.com/minetest/minetest/blob/master/src/game.cpp#L3828
18:49 lhofhansl   juhdanad: A sphere would be more intuitive indeed.
18:49 juhdanad    And Minetest only checks if the box intersects with this longer line. https://github.com/minetest/minetest/blob/master/src/game.cpp#L430
18:50 juhdanad    This is why it is possible to select nodes further than the maximal distance.
18:50 juhdanad    Even in the vanilla Minetest.
18:52 juhdanad    And #4346 fixes this. https://github.com/minetest/minetest/pull/4346/files#diff-18513665750ef5adf42b5ec29e14162eR3856
18:52 ShadowBot   https://github.com/minetest/minetest/issues/4346 -- Improved getPointedThing() by juhdanad
18:58 lhofhansl   Comments on #4959?
18:58 ShadowBot   https://github.com/minetest/minetest/issues/4959 -- Fix retrieving blocks in 3rd front camera view. by lhofhansl
18:58 lhofhansl   It's a bit of a bandaid (I think the player vs camera position needs some serious rethinking)
18:59 lhofhansl   But it does fix the strange issue of the server not sending blocks when using the 3rd front camera view
19:00 lhofhansl   And I think we should get #4895 in. The original causes a segmentation violation, but I found the problem (see code comment on PR).
19:00 ShadowBot   https://github.com/minetest/minetest/issues/4895 -- Use std::vector instead of std::map in class ABMHandler by Rogier-5
19:01 Krock       ^ testing this one and yet no issues
19:02 lhofhansl   Make sure you apply the fix I suggested. Otherwise there's a race between ABMHandler construction and calling the apply method
19:02 lhofhansl   Vector::operator[] does not perform a range check
19:08 Krock       sorry, what exactly do you mean? apply(MapBlock) does not modify the vector, so do you mean the m_aabms[c]->push_back part?
19:08 hmmmm       hmm
19:08 hmmmm       a vector of vectors
19:08 hmmmm       have you considered a multimap?
19:08 Krock       lol true
19:09 lhofhansl   yeah it ain't pretty
19:09 hmmmm       well nevermind that
19:09 lhofhansl   The issue was that map is too slow
19:09 hmmmm       just the resize() thing i dunno how that'll affect performance
19:09 hmmmm       it seems incorrect too
19:10 lhofhansl   His first version allowed 2^16 pointers ahead of time
19:10 hmmmm       disclaimer though, i haven't looked at the logic yet
19:10 Krock       but it's a fact that the lookup is a lot faster with this commit
19:11 hmmmm       that's not an excuse to merge code that might be sloppy
19:11 hmmmm       that's the same logic RBA used to push through obnoxiously bad stuff - "hey it works!"
19:11 lhofhansl   Krock: The part in ABMHandler::apply, where is retrieves from the vector by content_t. After construction new ABMs/ActiveObjects could have been created. That could cause access to an invalid entry.
19:13 lhofhansl   (and it does I looked at a core dump in gdb :) )
19:13 lhofhansl   It is noticeably faster. Which surprised me too, look at the comment up where I do some micro-benchmarking.
19:14 lhofhansl   I guess when active_block_range is sufficiently (I use 7) it really matters.
19:16 hmmmm       well I'll tell you where the majority of the performance improvement comes from in that PR
19:17 hmmmm       after it looks up the abm list from the abm map, it does a *deep copy* of the entire vector
19:17 hmmmm       and then it does a linear search on that vector
19:17 Krock       oh I see. Thanks a lot for the explanation, lhofhansl :)
19:24 paramat     #4965 is tested and ready for review, fairly simple correction of maths checking if any part of a block is over-limit
19:24 ShadowBot   https://github.com/minetest/minetest/issues/4965 -- Mapgen limit: Fix crash and don't load over-limit by paramat
19:24 paramat     i just need to improve the commit message
19:32 nrzkt       i also noticed a huge difference from switching to std::map => std::vector and pre-allocating the whole content_t values at start time (a little bit crazy but working) this permit to reduce the server loop step by 2
19:42 lhofhansl   hmmmm: So you're saying if we keep the map but have it store pointers to vectors instead we'd get the same perf improvement?
19:46 juhdanad    lhofhansl: now I tried the map of pointers, but it is still slow as it was.
19:47 hmmmm       i'm just making an observation
19:47 hmmmm       this code could be structured better in general
19:54 lhofhansl   My micro benchmark has 10m map lookup with integer keys at about 1.4.
19:55 hmmmm       well i never said it should be a map
19:55 hmmmm       but look is having a pointer to a vector a good idea?
19:56 hmmmm       a vector itself is two integers and a pointer
19:56 hmmmm       what's wrong with making it a vector of vectors, not a vector of pointers to vectors
19:56 hmmmm       that way you could let RAII do its trick and auto-cleanup
19:56 hmmmm       and save on allocations
19:57 hmmmm       to access an element, take a reference instead of a by-value copy of it
19:57 lhofhansl   I guess the way the code is structured in apply for loop over each node in each map block: 16^3 then for each node we look at each neighbor: 9^3. So up to 2.9m lookups per mapblock. Then there might be 1000's of mapblocks. Not all with have anything active in them, but still, it adds up.
19:59 lhofhansl   the resize would be bad then... So pre-allocate 2^16 vectors? Wouldn't be the end of the world.
20:00 Krock       that would be 256 or 512 KiB of RAM, when using pointers
20:01 lhofhansl   2 int + pointer is 16 bytes (on 64 bits) * 2^16 that's just 1mb.
20:01 hmmmm       do you actually need to preallocate anything?
20:01 lhofhansl   if not you need to resize. Or use a sparse data structure.
20:01 hmmmm       oh, it's sparse?
20:01 hmmmm       that's why you're using a vector?
20:02 hmmmm       i see now
20:06 lhofhansl   the ids of the ABMs are not contiguous. Map was the right data structure. Not sure why it's so slow. It is (unnecessarily in our case) preserving the order.
20:07 lhofhansl   Rogier-5 said he tried unordered_map as well, but it was equally slow.
20:08 lhofhansl   The std::vector is the strange part, if you want to store at index X all indexes 0 to X-1 need to be allocated. And yet it's faster.
20:09 hmmmm       what libstdc++ is being used?
20:09 hmmmm       i guess that's the real question
20:11 lhofhansl   libstdc++-6.3.1 (Linux) in my case. Multiple folks have observes this, though.
20:11 lhofhansl   Maybe it's a GCC issue. Who knows.
20:11 hmmmm       indeed, unordered_map is the correct data structure but seems incredibly slow here
20:12 hmmmm       i hate wasting memory but if it really is a 10x speedup from where it is right now, that sounds great
20:12 hmmmm       but to be fair the entire ABM system needs to be fixed
20:12 hmmmm       this is a great stopgap measure though
20:17 hmmmm       the crash you encountered in the PR is concerning, but it's nothing that would be caused by these code changes
20:17 hmmmm       i think i can gt on board with this PR
20:17 lhofhansl   You see the proposed fix?
20:17 lhofhansl   That was an actual bug.
20:18 hmmmm       no, what's the proposed fix?
20:18 lhofhansl   https://github.com/minetest/minetest/pull/4895/files#diff-baa4d2d0ffafdec2b86baf065fba252bR888
20:19 lhofhansl   I hope that shows the review?
20:19 hmmmm       ??  that line was already in the original PR
20:20 lhofhansl   There's a code review of mine on that line. I guess it's not visible.
20:20 lhofhansl   if (!m_aabms[c]) needs to be if (c >= m_aabms.size() || !m_aabms[c])
20:20 hmmmm       ah that'll do the trick
20:20 hmmmm       makes perfect sense
20:20 lhofhansl   Because new ABM/ActiveObjects might have been created after the ABMHandler's construction
20:21 hmmmm       good call
20:21 lhofhansl   cool... Took me a while to find that one.
20:21 hmmmm       yeah it's pretty obvious though
20:21 hmmmm       i'm ashamed i missed that.
20:22 lhofhansl   strange that the code-review I added does not appear to be visible to anybody else. Maybe some github issue.
20:23 hmmmm       that, and also the cast on NULL is completely unnecessary
20:23 hmmmm       i'd remove it tbh
20:24 lhofhansl   you mean https://github.com/minetest/minetest/pull/4895/files#diff-baa4d2d0ffafdec2b86baf065fba252bR825
20:24 lhofhansl   ?
20:24 hmmmm       yes
20:24 lhofhansl   Yeah, I thought NULL is frowned upon in C++ land anyway. Should just use 0.
20:25 hmmmm       please do not.  that's not only wrong but a violation of our code style guidelines.
20:25 hmmmm       0 is an integer, not a pointer
20:25 lhofhansl   fair enough
20:26 hmmmm       freaking tired of reading code that's like foobar = 0; and being mislead into thinking it's a counter
20:26 lhofhansl   got that mixed up. NULL is defined as 0 in C, not C++
20:27 hmmmm       don't worry about what NULL is defined as or isn't
20:27 hmmmm       the only requirement is that when compared as an integer expression, it is equivalent to 0
20:28 hmmmm       it could actually be represented as 0x53535353 in memory
20:31 lhofhansl   as long as entries in the outer vector are initialized to this we're good.
20:32 est31       paramat: it was my fault, I didn't mention I only approved of the concept
20:32 est31       not your fault :)
20:34 paramat     :]
20:37 VanessaE    paramat (et al.), could you comment on this?  http://pastebin.ubuntu.com/23703552/   I've seen this crash happen in two different, totally unrelated mods lately ("areas" shown here, item_tweaks also).
20:37 VanessaE    (particularly the errors from line 33 on)
20:39 lhofhansl   > ServerEnv: Trying to store id = 6587 statically but block (-20,12,44) already contains 2226 objects. Forcing delete.
20:40 lhofhansl   Whoa. It's the default 64 objects?
20:40 sfan5       VanessaE: sounds like player:getpos() returning garbage
20:40 VanessaE    ignore that, lhofhansl.  that's just old crap that never got cleared off of that block. leftover from another engine bug I think.
20:41 lhofhansl   That does remind me of something I just saw the past few days. I had increase that limit from 64, or players would get disconnected after that message.
20:42 VanessaE    lhofhansl: that's a different bug, not sure if that has been addressed yet.
20:47 lhofhansl   not in latest git HEAD :)
20:47 hmmmm       i git lots of HEAD
20:47 hmmmm       feels great
20:48 * celeron55 awards "worst joke of the year"
20:48 hmmmm       good thing i didn't spend too much time thinking about it.
20:51 celeron55   oh, i should ask publicly in here; is everyone ok with lhofhansl being a core dev?
20:51 sfan5       sounds good
20:51 hmmmm       well, how many contributions were made in total?
20:52 celeron55   something like 10 closed PRs it seems
20:53 hmmmm       is that really enough?  i'm under the impression that being a core developer means having a lot more familiarity with what minetest is
20:53 hmmmm       not only do you have commit privileges, but you're looked up to for guidance from other would-be contributors
20:53 hmmmm       well then again it doesn't matter much since there is still an approval process i suppose
20:55 celeron55   i'm ok with adding him now or adding later, altough then i want to know what would be a good time
20:56 hmmmm       he has more like twice as many PRs as that
20:56 hmmmm       i would be okay i suppose
20:57 garywhite   Guys what file are the minetest_game node names set in?
20:58 hmmmm       games/minetest_game/mods/default/nodes.lua
20:58 garywhite   ok thx
20:58 hmmmm       you couldn't use grep to find that?
20:58 garywhite   I'm not used to messing with stuff a whole lot
20:58 garywhite   I dunno how to use Git that much
20:59 hmmmm       learn how to search and you'll find yourself needing to ask much less questions
20:59 hmmmm       read man grep(1)
21:01 garywhite   OK, I kinda meant the names that show up in an inventory system, not the node names, but that was partially what I was looking for
21:01 hmmmm       not sure what you mean
21:01 sfan5       the node descriptions are also in there
21:02 hmmmm       either way this doesn't have a whole lot to do with minetest core development
21:02 garywhite   Well I figured dev was the best place to ask cause idk what channel it should have gone to
21:03 garywhite   I'm using Wuzzy's game#1473 as a start point to play around with some of the node names in a fork & see what I can come up with
21:03 ShadowBot   https://github.com/minetest/minetest_game/issues/1473 -- Bad item naming: Too generic names among specific names
21:03 celeron55   it seems the review and merge process is going quite fine currently by like at least 3 core devs doing stuff so i think it makes sense to wait for some months before adding anyone to the core team
21:04 garywhite   OK, found where the descriptions are, they're in the recipes. Thanks sfan5
21:05 celeron55   or like a month maybe; it doesn't really matter, my point is, lhofhansl doesn't need to be a core dev right now so let's not hurry with that
21:05 hmmmm       yes you hurried once before and look at what happened
21:07 celeron55   there are some people that very eagerly advocate new core devs and this is one of them
21:07 hmmmm       i agree though he is good
21:07 hmmmm       still not a reason to rush
21:10 lhofhansl   no need to rush, I had no issues getting my proposed changes merged, or my voice heard on other issues/PRs
21:11 hmmmm       lhofhansl, do you want to be a core developer?
21:12 lhofhansl   I'd be able to help for sure. I'm not emotionally attached, though.
21:12 hmmmm       this status does impose some level of responsibility you nevere intended to accept
21:12 hmmmm       s/nevere/never/
21:12 celeron55   that doesn't really matter; what matters is that people want it and one is ok with being one
21:12 hmmmm       my point is
21:13 hmmmm       you shouldn't push it on people
21:13 hmmmm       what if they already have like 20 other projects going on
21:13 lhofhansl   I'm a committer and PMC member of various large Apache projects... I'm well aware of the responsibilities.
21:13 celeron55   that's why i /msgd him before asking here
21:13 hmmmm       i'm a core developer and i don't feel like i should be anymore because i do have 20 projects going on and yet i'm expected to review 5000000000000000000000 PRs and other stuff
21:13 hmmmm       oh ok.
21:14 hmmmm       despite that I just got done with one of my big projects at work so
21:14 celeron55   well, making >10 PRs to something kind of indicates one has time and interest for whatever the PRs were for
21:14 hmmmm       I'm gonna try to get back into the swing of things with MT
21:15 hmmmm       i know i said this before and i implemented a new biome system but then i left something else half finished
21:16 hmmmm       this time will be different i promise
21:16 celeron55   the sad story of hmmmm unfolds
21:16 celeron55   it's not like i'm any better though
21:16 hmmmm       yeah
21:16 hmmmm       farmap
21:17 hmmmm       "don't bother with client side scripting, i'm gonna take over on that"
21:17 hmmmm       how's it going
21:21 celeron55   well i did some prototyping on that too
21:27 VanessaE    would be nice to see it go past the prototype stage.  that was a pretty decent feature, c55.
21:27 VanessaE    (well, farmap that is)
21:28 Fixer       juhdanad: you here?
21:28 Fixer       juhdanad: 4967 also includes ghost light fix? I don't have to apply both patches? only this one? //
21:34 hmmmm       wew lad
21:34 hmmmm       first time in months i've done this
21:34 hmmmm       [ryan@titan] ~% cd dev/minetest
21:35 celeron55   $ git pull
21:35 celeron55   Fast-forward
21:35 Fixer       VanessaE: farmap consumes mem like crazy right now
21:36 celeron55   *entire code replaced, good luck*
21:36 Fixer       ./buildwin64_compileonly_cmake.sh
21:36 hmmmm       lol
21:36 Fixer       nevermind
21:36 hmmmm       i wonder what uses more memory, farmap or my perlin noise buffers
21:37 Fixer       i had firefox and minetest with farmap - after some time Windows Process Killer warned me to close it down (FF was at 1GB)
21:37 Fixer       farmap loaded a lot of stuff and it looked quite amazing
21:38 Fixer       if you have good fps with 240 v_range + farmap - that is gonna be badass
21:40 celeron55   what farmap needs a shortcut to the map generator that would allow it to quickly generate low-resolution terrain
21:40 celeron55   without making individual nodes
21:41 celeron55   +is
21:41 juhdanad    Fixer: 4967 contains two commits: the first is actually the ghost lighting fix (you already tested it) and the second commit is the relevant one.
21:42 hmmmm       holy shit jitter
21:43 hmmmm       i'm just running the latest commit and there's so much jitter it's horrifying
21:43 hmmmm       something happened to performance recently
21:46 Fixer       hmmmm: lol, jitter was since 2011
21:46 Fixer       i was telling about this for years
21:46 juhdanad    What jitter?
21:46 VanessaE    hmmmm: you think it's bad with standard?  try it with HavenNG or HDX (or any other texture pack in the 128-256px range)
21:47 hmmmm       every time i take a break from minetest, then come back, i'm almost always faced with some kind of new performance degredation
21:47 hmmmm       i'm used to it
21:47 hmmmm       but this... my brain can't handle this jitter
21:47 Fixer       juhdanad: spikes on F5 graph: mesh draw time section
21:47 hmmmm       i'd like to just pick up where i left off but i need to bisect this to find the cause
21:48 hmmmm       ironically weren't there a lot of *performance enhacements* lately?
21:48 hmmmm       WTF?
21:48 Fixer       start bisecting from 2011
21:48 * Fixer     runs fast
21:49 hmmmm       fixer, seriously, shut up
21:49 hmmmm       if you don't have anything productive to say don't do it
21:51 Fixer       juhdanad: compiled with your light patch - will see
21:52 juhdanad    Thanks for testing!
21:52 Fixer       juhdanad: will try reproducing that light bugs as usual
21:53 hmmmm       SEnv step regularly taking 0.5-1 sec
21:53 hmmmm       when i left it this was literally at 0.053
21:54 hmmmm       wish i could run valgrind
22:01 lhofhansl   ran it through the linux perf counters some time ago. Most time spent in ABMHandler::apply (but that's async, so should be OK), and the mesh-combining code (forget the method right now) as new meshes are loaded, wonder whether that's worth it - gonna try without.
22:04 Fixer       SEnv step on fresh world: about 0.08 when idle
22:14 Fixer       juhdanad: TNT in water bug looks fixed to me
22:15 juhdanad    Great!
22:18 Fixer       juhdanad: have not noticed this earlier, but night TNT explosion give nice bright light blast
22:18 Fixer       nevermind
23:41 Fixer       get_biome_info
23:53 red-001     !seen two_steps
23:53 ShadowBot   red-001: I haven't seen two_steps in #minetest-dev.