Time |
Nick |
Message |
01:09 |
MTDiscord |
<exe_virus> Ronaldo, right there with you:) |
01:14 |
|
Edgy19 joined #minetest-dev |
01:34 |
lhofhansl |
Perhaps a dumb question... Do we need to save generated blocks at all, until someone actually modifies them? As is we save a block as soon as it is generated. |
01:36 |
lhofhansl |
If they are not save they'll just be generated again. That is (currently) slower than loading them back, but it avoids storing stuff. |
01:55 |
|
absurb joined #minetest-dev |
02:53 |
|
Fractalis joined #minetest-dev |
03:35 |
|
lhofhansl joined #minetest-dev |
04:41 |
|
Fractalis joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
06:59 |
|
NetherEran joined #minetest-dev |
07:44 |
MTDiscord |
<IhrFussel> Just my 2 cents: If generated areas would regenerate all the time servers would lag horribly...it'a a huge difference between generation and loading from DB even on my server's SSD and I only use 2 of the most common mods that trigger on mapgen (caverealms, nether)...there are servers that rely on much heavier lua mapgens |
08:00 |
|
ShadowNinja joined #minetest-dev |
08:09 |
|
calcul0n joined #minetest-dev |
08:10 |
|
fluxflux joined #minetest-dev |
08:30 |
|
Fractalis joined #minetest-dev |
09:00 |
|
YuGiOhJCJ joined #minetest-dev |
10:09 |
|
ronoaldo joined #minetest-dev |
10:23 |
|
proller joined #minetest-dev |
10:53 |
|
Fixer joined #minetest-dev |
11:33 |
|
Fixer_ joined #minetest-dev |
11:45 |
|
kb1000 joined #minetest-dev |
12:16 |
|
NetherEran joined #minetest-dev |
12:23 |
|
Fixer joined #minetest-dev |
12:23 |
|
ronoaldo joined #minetest-dev |
12:30 |
|
zughy[m] joined #minetest-dev |
12:30 |
|
nathanfranke[m] joined #minetest-dev |
12:30 |
|
_Zaizen_[m] joined #minetest-dev |
12:30 |
|
Kimapr[m] joined #minetest-dev |
12:30 |
|
anon5[m] joined #minetest-dev |
12:30 |
|
Benrob0329[m] joined #minetest-dev |
12:30 |
|
celeron55[m] joined #minetest-dev |
12:39 |
|
Fleckenstein joined #minetest-dev |
13:26 |
|
ronoaldo joined #minetest-dev |
13:36 |
|
ronoaldo joined #minetest-dev |
13:52 |
|
T4im joined #minetest-dev |
14:41 |
|
ronoaldo joined #minetest-dev |
14:54 |
|
ronoaldo joined #minetest-dev |
14:57 |
|
lisac joined #minetest-dev |
15:15 |
|
ronoaldo joined #minetest-dev |
15:20 |
|
turtleman joined #minetest-dev |
16:08 |
|
Fixer_ joined #minetest-dev |
16:28 |
Fleckenstein |
What are the core dev's opinions about dual wielding? |
16:43 |
sfan5 |
sounds fine to me as a concept |
17:01 |
|
T4im joined #minetest-dev |
17:10 |
specing |
How does one use the other item? |
17:10 |
specing |
how would* one use it |
17:21 |
|
T4im joined #minetest-dev |
17:23 |
|
T4im joined #minetest-dev |
17:26 |
MTDiscord |
<Lone_Wolf> Depends on the item |
17:55 |
MTDiscord |
<Jordach> on_use_alt_hand on_punch_alt_hand etc |
17:55 |
MTDiscord |
<Jordach> Same type of calls for the main hand |
18:12 |
MTDiscord |
<Lone_Wolf> Oh, that's a thought |
18:12 |
Krock |
yeah sure why not |
18:13 |
specing |
I mean |
18:13 |
specing |
How would a player use it? |
18:13 |
Krock |
I suppose the other item is just used as placeholder for shields? |
18:13 |
Krock |
I've seen that on some Minecraft videos, so that might be the idea |
18:44 |
|
fluxflux joined #minetest-dev |
19:08 |
|
proller joined #minetest-dev |
19:29 |
|
homthack joined #minetest-dev |
19:32 |
|
Taoki joined #minetest-dev |
19:37 |
|
lhofhansl joined #minetest-dev |
19:38 |
lhofhansl |
Merging #10670. The one where sfan5 had done a lot of thinking :) |
19:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/10670 -- Avoid marking map blocks dirty upon deserialization. by lhofhansl |
19:39 |
|
pgimeno joined #minetest-dev |
19:43 |
lhofhansl |
Can we merge #10660? |
19:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/10660 -- Improve sky rendering performance by numberZero |
19:45 |
rubenwardy |
yes, it has two approvals and no objections |
20:18 |
|
Fractalis joined #minetest-dev |
20:46 |
|
lhofhansl joined #minetest-dev |
20:48 |
lhofhansl |
Krock: Hopefully that re-loading of blocks already generated will go away after my fix. |
20:48 |
lhofhansl |
Ok... Merging #10660 |
20:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/10660 -- Improve sky rendering performance by numberZero |
20:49 |
Krock |
why no squash? |
20:50 |
lhofhansl |
whoa... Did I do it the wrong way? |
20:50 |
Krock |
you did the rebase merge. unless that's the way you wanted it |
20:50 |
lhofhansl |
I did. |
20:50 |
lhofhansl |
Didn't want that. |
20:51 |
lhofhansl |
I can force push the squash. |
20:51 |
lhofhansl |
Or we can leave it. |
20:51 |
sfan5 |
yeah that'd be good |
20:51 |
Krock |
git rebase -i HEAD~10 for manual squash |
20:51 |
Krock |
dunno whether there's "git squash" tbh |
20:53 |
rubenwardy |
I mean, at least the commits largely make sense |
20:54 |
|
proller joined #minetest-dev |
20:54 |
Krock |
what's more worrying is that we're approaching open issue N°1000 |
20:56 |
lhofhansl |
Not a fan of force pushes. Lemme know. Sorry I didn't squash before merging. |
20:57 |
sfan5 |
leaving it is also okay |
20:57 |
rubenwardy |
yeah, I think it's fine to leave it |
20:58 |
lhofhansl |
Meh.. Sorry about that folks. |
20:59 |
Krock |
more commits = more gooder |
20:59 |
lhofhansl |
I always amend my commits on my branch, so I forgot about it here. |
21:02 |
|
kilbith joined #minetest-dev |
21:02 |
kilbith |
stars are much clearer than before, normal? |
21:03 |
kilbith |
I mean brighter |
21:05 |
Krock |
feature |
21:05 |
sfan5 |
I did notice that too but didn't investiage it |
21:05 |
sfan5 |
investigate* |
21:06 |
sfan5 |
I'm pretty sure it still respects the star color |
21:08 |
kilbith |
maybe a ARGB->RGBA confusing |
21:08 |
kilbith |
since gl_FragColor is RGBA and SColor is ARGB |
21:10 |
Krock |
how can there be a segfault in "no code"? https://github.com/minetest/minetest/pull/10661#issuecomment-733948983 |
21:10 |
rubenwardy |
try building with debug info, to get the line |
21:11 |
rubenwardy |
also, end of function sounds like a destructor |
21:11 |
sfan5 |
0x000000000000007e surely won't have debug info |
21:11 |
sfan5 |
Krock: did you try my suggestion with -fsanitize=address? |
21:12 |
Krock |
sfan5: no sorry. did I mess this message earlier? |
21:12 |
Krock |
*miss |
21:12 |
sfan5 |
<sfan5> Krock: for 10661 I suggest testing your code compiled with -fsanitize=address |
21:12 |
sfan5 |
<sfan5> because the segfault you have looks like a buffer overflow or similar |
21:12 |
Krock |
oh! |
21:21 |
sfan5 |
pushing http://sprunge.us/rzvY6s?diff (two commits!) in 10 minutes |
21:28 |
Krock |
L111 } ; |
21:32 |
Krock |
heap-use-after-free.. the struct contains a pointer which is then double-freed.. oh no. |
21:37 |
Krock |
thank you, sfan5. issue solved |
21:41 |
sfan5 |
oops long 10 minutes |
21:42 |
sfan5 |
pushed |
21:56 |
sfan5 |
lhofhansl: what was the purpose of blockpos_requested in struct BlockMakeData? |
21:59 |
lhofhansl |
There wasn't any. :) |
22:05 |
sfan5 |
ah so the removal is not related to the other change |
22:17 |
sfan5 |
I wonder what those awful lack spikes are when you fly through lots of terrain |
22:17 |
sfan5 |
please dont tell me it's the VBO clearing |
22:22 |
sfan5 |
hmm now it's not as bad as before |
22:23 |
sfan5 |
nah that's not it |
22:25 |
sfan5 |
anyway: when there's lots of blocks loaded(?) and you have infinite view range enabled there are frametime spikes every few seconds, this doesn't coincide with HW buffer clearing |
22:25 |
sfan5 |
I guess it's doing something to all loaded blocks since culling is disable with infinite view range (is it?) |
22:26 |
sfan5 |
also relevant: I'm moving fast in the direction of unexplored land (so none of those whatever thousand blocks in memory are visible) |
22:26 |
sfan5 |
well whatever |
22:29 |
celeron55 |
is transfer of blocks continuous and not coincidentally spiky with that behavior? |
22:37 |
sfan5 |
sometimes? maybe? |
22:43 |
lhofhansl |
Sorry... Cooking dinner on the side :) |
22:44 |
sfan5 |
I don't see any obvious correlation of the debug graphs here -> https://0x0.st/iRlW.mp4 |
22:44 |
lhofhansl |
I do not know what these spikes are, but when I tried, pretty sure that they are not due to the HW buffer clearing. |
22:45 |
sfan5 |
the errorstream is not visible there, but hw buffer clearing only happens every 10 seconds |
22:45 |
lhofhansl |
The lag is (still) mostly due to meshing, I think (not all meshes come from the mesh generator thread) |
22:45 |
lhofhansl |
But it |
22:45 |
lhofhansl |
's so much better than before. |
23:03 |
|
Taoki joined #minetest-dev |
23:53 |
|
Miner_48er joined #minetest-dev |
23:54 |
lhofhansl |
I'm going to merge #10637 soon'ish. |
23:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/10637 -- Avoid generating the same chunk more than once with multiple emerge threads by lhofhansl |
23:54 |
lhofhansl |
(Thanksgiving fun) |