| 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/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 |
| 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/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: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/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: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. |
