Minetest logo

IRC log for #minetest-dev, 2016-12-29

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:03 proller joined #minetest-dev
00:15 fling joined #minetest-dev
00:26 proller joined #minetest-dev
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
00:50 zorman2000 joined #minetest-dev
01:01 proller joined #minetest-dev
01:11 proller joined #minetest-dev
01:35 proller joined #minetest-dev
01:45 MilllersMan joined #minetest-dev
01:51 proller joined #minetest-dev
01:57 jordan4ibanez joined #minetest-dev
02:09 proller joined #minetest-dev
02:20 Miner_48er joined #minetest-dev
02:31 turtleman joined #minetest-dev
02:32 proller joined #minetest-dev
02:49 lhofhansl joined #minetest-dev
02:50 Tmanyo joined #minetest-dev
03:15 proller joined #minetest-dev
03:17 DI3HARD139 joined #minetest-dev
03:21 proller joined #minetest-dev
03:42 eidy joined #minetest-dev
03:52 proller joined #minetest-dev
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
04:09 proller joined #minetest-dev
04:32 octacian joined #minetest-dev
04:36 proller joined #minetest-dev
04:53 proller joined #minetest-dev
05:04 lumidify joined #minetest-dev
05:11 proller joined #minetest-dev
05:26 proller joined #minetest-dev
05:45 proller joined #minetest-dev
05:56 Zeno` joined #minetest-dev
06:03 proller joined #minetest-dev
06:04 lumidify joined #minetest-dev
06:04 nrzkt joined #minetest-dev
06:04 Hunterz joined #minetest-dev
06:06 octacian joined #minetest-dev
06:06 octacian joined #minetest-dev
06:07 ssieb joined #minetest-dev
06:38 proller joined #minetest-dev
07:05 proller joined #minetest-dev
07:19 fling joined #minetest-dev
07:25 proller joined #minetest-dev
07:31 proller joined #minetest-dev
08:08 proller joined #minetest-dev
08:12 lumidify joined #minetest-dev
08:25 proller joined #minetest-dev
08:29 lhofhansl left #minetest-dev
08:39 proller joined #minetest-dev
08:58 proller joined #minetest-dev
09:12 proller joined #minetest-dev
09:38 proller joined #minetest-dev
09:43 Krock joined #minetest-dev
09:43 MillersMan joined #minetest-dev
09:52 Thomas-S joined #minetest-dev
09:53 proller joined #minetest-dev
10:24 harrison joined #minetest-dev
10:29 ^v^v joined #minetest-dev
10:35 proller joined #minetest-dev
10:36 xunto joined #minetest-dev
10:36 celeron55 joined #minetest-dev
10:36 Kray joined #minetest-dev
10:36 gentoobr1 joined #minetest-dev
10:37 Karazhan joined #minetest-dev
10:54 juhdanad joined #minetest-dev
11:43 troller joined #minetest-dev
11:43 YuGiOhJCJ joined #minetest-dev
11:54 lumidify joined #minetest-dev
11:59 Fixer joined #minetest-dev
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:32 troller joined #minetest-dev
12:44 nrzkt merged
12:48 lisac joined #minetest-dev
12:55 juhdanad joined #minetest-dev
14:18 STHGOM joined #minetest-dev
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/flat​gen/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/astero​id/blob/master/init.lua#L333-L336
15:42 zorman2000 joined #minetest-dev
15:47 red-001 joined #minetest-dev
15:49 red-001 joined #minetest-dev
15:52 lumidify joined #minetest-dev
16:02 rubenwardy joined #minetest-dev
16:08 Darcidride joined #minetest-dev
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.
16:33 red-001 joined #minetest-dev
16:45 Hunterz joined #minetest-dev
16:50 emptty joined #minetest-dev
17:04 red-001 joined #minetest-dev
17:10 paramat joined #minetest-dev
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/stab​ility/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/cata​comb/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/pat​hv7/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:34 Krock joined #minetest-dev
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 hmmmm joined #minetest-dev
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:02 proller__ joined #minetest-dev
18:05 paramat with moretrees, have you fixed the very subtle shadows in water too?
18:06 juhdanad Will see soon.
18:06 zorman2000 joined #minetest-dev
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:08 garywhite joined #minetest-dev
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:20 lhofhansl joined #minetest-dev
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 AcidNinjaFWHR joined #minetest-dev
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 STHGOM_ joined #minetest-dev
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/minete​st/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/minet​est/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/f​iles#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:05 red-001 joined #minetest-dev
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:21 ssieb joined #minetest-dev
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 red-001 joined #minetest-dev
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:44 rubenwardy joined #minetest-dev
20:47 lhofhansl not in latest git HEAD :)
20:47 hmmmm i git lots of HEAD
20:47 hmmmm feels great
20:47 emptty joined #minetest-dev
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:00 juhdanad joined #minetest-dev
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 red-001 joined #minetest-dev
21:14 red-001 joined #minetest-dev
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:14 jordan4ibanez joined #minetest-dev
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:25 DI3HARD139 joined #minetest-dev
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 lordfingle joined #minetest-dev
21:35 eidy joined #minetest-dev
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:47 paramat joined #minetest-dev
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:16 YuGiOhJCJ joined #minetest-dev
22:18 Fixer juhdanad: have not noticed this earlier, but night TNT explosion give nice bright light blast
22:18 Fixer nevermind
22:29 Tmanyo joined #minetest-dev
22:29 proller__ joined #minetest-dev
22:36 proller joined #minetest-dev
22:49 Tmanyo joined #minetest-dev
22:50 proller joined #minetest-dev
23:16 zorman2000 joined #minetest-dev
23:41 Fixer get_biome_info
23:42 ptv joined #minetest-dev
23:53 red-001 joined #minetest-dev
23:53 red-001 !seen two_steps
23:53 ShadowBot red-001: I haven't seen two_steps in #minetest-dev.

| Channels | #minetest-dev index | Today | | Google Search | Plaintext