| Time |
Nick |
Message |
| 00:14 |
|
lhofhansl joined #minetest-dev |
| 01:07 |
|
Ritchie_ joined #minetest-dev |
| 01:14 |
|
Ritchie joined #minetest-dev |
| 01:38 |
|
Fractalis joined #minetest-dev |
| 02:47 |
|
fluxflux joined #minetest-dev |
| 04:16 |
|
MTDiscord joined #minetest-dev |
| 04:36 |
|
Foz joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:17 |
|
lhofhansl joined #minetest-dev |
| 06:05 |
|
olliy joined #minetest-dev |
| 07:14 |
|
m42uko joined #minetest-dev |
| 07:24 |
|
Flitzpiepe joined #minetest-dev |
| 07:57 |
|
calcul0n joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:13 |
|
NetherEran joined #minetest-dev |
| 10:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:25 |
|
Fractalis joined #minetest-dev |
| 10:33 |
|
proller joined #minetest-dev |
| 11:18 |
|
Fixer joined #minetest-dev |
| 11:34 |
|
proller joined #minetest-dev |
| 12:00 |
|
Fleckenstein joined #minetest-dev |
| 13:42 |
|
Taoki joined #minetest-dev |
| 14:24 |
|
Fleckenstein joined #minetest-dev |
| 14:28 |
|
lisac joined #minetest-dev |
| 14:49 |
|
ronoaldo joined #minetest-dev |
| 14:50 |
ronoaldo |
Hi! I'm new to minetest, but I'm a developer and would like to contribute with the project. |
| 14:52 |
ronoaldo |
I would love to help getting some improved UX on Android. Saw some PRs and Issues related but would like to discuss the proposed changes, how to properly test them and help getting them into the next planed Android release. |
| 14:53 |
rubenwardy |
Building for Andorid is as simple as getting Android Studio then opening minetest/build/android in it |
| 14:53 |
rubenwardy |
discussing is as simple as using github |
| 14:53 |
rubenwardy |
testing is building them and checking them out |
| 14:54 |
|
absurb joined #minetest-dev |
| 14:55 |
ronoaldo |
Perfect Thanks for the pointers. I'll keep the discussion on Github then! |
| 14:55 |
specing |
mm monopolyhub |
| 16:05 |
ronoaldo |
rubenwardy, got it up and running with Android Studio, thanks for the heads up! I'll follow up with the GH issues. |
| 16:05 |
rubenwardy |
coolio |
| 16:05 |
rubenwardy |
You can still discuss things here, but PR discuss happens mostly on GH |
| 16:16 |
|
Fleckenstein joined #minetest-dev |
| 16:37 |
ronoaldo |
great... I'm just trying to avoid duplicate work actually, that's why I joined here |
| 16:38 |
ronoaldo |
I'm reading some issues, mostly bugs, to help bug squashing... I have some good skills with scripts and Linux (around 10yeras+) so I can help with the ones related to build/release scripts. |
| 16:44 |
rubenwardy |
I believe the issue with that is that the configs changed, so the scripts no longer match the correct thing |
| 16:44 |
rubenwardy |
they also need to increment twice currently |
| 16:56 |
ronoaldo |
ok, I'll test it out running the script and sharing the results, I spotted the -dev part missing currently but maybe I looked at the wrong place. To perform a release, what steps you usually take? |
| 16:58 |
rubenwardy |
runnign the script does the automated bit |
| 16:59 |
rubenwardy |
full process is here: https://dev.minetest.net/Releasing_Minetest |
| 16:59 |
rubenwardy |
(it's way too long) |
| 16:59 |
ronoaldo |
perfect, ill check it out |
| 17:16 |
ronoaldo |
ok the process is indeed quite complex... the script currently does bumps some versionCode +2.. Last time you did this for 5.3 you had to change and build for each arch, right? |
| 17:18 |
ronoaldo |
I wonder if a CI/CD flow is something desired for the project? would simplify some of these steps, and it is something I may be able to help working on |
| 17:30 |
rubenwardy |
we have a CI/CD flow |
| 17:30 |
rubenwardy |
but CI/CD can't modify commits |
| 17:30 |
ronoaldo |
hmm, makes sense |
| 17:31 |
rubenwardy |
It would be good to actually use the Windows build built by CI in a release |
| 17:31 |
rubenwardy |
I suppose versions could be based entirely on tags, then it wouldn't need to modify commits |
| 17:32 |
ronoaldo |
yeah.. that could work |
| 17:32 |
ronoaldo |
it would be a matter of fetching the current tag of commit and use it instead of prompting in build.sh probably. |
| 17:33 |
ronoaldo |
This is the pipline build for CI/CD? https://github.com/minetest/minetest/tree/master/.github/workflows |
| 17:33 |
rubenwardy |
yes |
| 18:16 |
|
fluxflux joined #minetest-dev |
| 18:22 |
|
lhofhansl joined #minetest-dev |
| 18:23 |
|
lhofhansl left #minetest-dev |
| 18:23 |
|
lhofhansl joined #minetest-dev |
| 18:33 |
|
Fixer_ joined #minetest-dev |
| 18:55 |
|
proller joined #minetest-dev |
| 19:00 |
Krock |
RemotePlayer::serialize and PlayerDatabaseFiles::serialize are identical |
| 19:00 |
* Krock |
fixes |
| 19:05 |
lhofhansl |
Any more input on #10637? It seems MapGen itself is to blame. It seems to build up some internal state, and since each emerge thread get it's own MapGen it's not right. You can observer this without 10637 where some of the blocks are flickering between versions until settling to whatever was rendered last. |
| 19:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/10637 -- Avoid generating the same chunk more than once with multiple emerge threads by lhofhansl |
| 19:06 |
lhofhansl |
10637 just picks the first version. But that's not all. Now that not all chunks are generated on all threads (which defeats having multiple threads anyway) some internal state differs. |
| 19:07 |
lhofhansl |
(mapgen v7) |
| 19:09 |
pgimeno |
lhofhansl: just FYI, threaded generation has a serious problem of concurrency, where several threads write some shared objects without blocking |
| 19:10 |
pgimeno |
I wrote a fix maybe a year ago or so, but it was too hacky |
| 19:10 |
lhofhansl |
pgimeno: The shared state is handled correctly via locking, though. |
| 19:11 |
lhofhansl |
What was wrong specifically? Everything is done under the "env" lock. |
| 19:11 |
pgimeno |
the noise object is shared IIRC |
| 19:12 |
pgimeno |
let me search the issue number |
| 19:12 |
|
homthack joined #minetest-dev |
| 19:12 |
lhofhansl |
Hah. That might explain what I see. If you "pull" a new random number, you then different outcomes based on the order of execution. |
| 19:13 |
|
Miner_48er joined #minetest-dev |
| 19:14 |
pgimeno |
the big issue there is to isolate that also on the Lua side |
| 19:15 |
lhofhansl |
That one part I want to fix. Right now with multiple emerge threads the Lua code is called multiple times. If you're unlucky as often as there are emerge threads. |
| 19:15 |
lhofhansl |
(called multiple time for the same map chunk) |
| 19:16 |
pgimeno |
can't find it right now, sorry |
| 19:16 |
lhofhansl |
Hmm... recall the title or some keyword? |
| 19:18 |
pgimeno |
it might have 'race' or 'emerge' in the title |
| 19:18 |
pgimeno |
or both |
| 19:18 |
lhofhansl |
lemme look. A quick look at the code shows no global, shared state, though. |
| 19:19 |
pgimeno |
ah sorry |
| 19:19 |
pgimeno |
https://github.com/minetest/minetest/issues/8300 |
| 19:19 |
pgimeno |
#8300 |
| 19:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/8300 -- Segfault in noise.cpp |
| 19:21 |
pgimeno |
the ghost in that thread was me before I deleted my account |
| 19:21 |
pgimeno |
https://github.com/minetest/minetest/issues/8300#issuecomment-470714660 |
| 19:21 |
sfan5 |
that was fixed |
| 19:21 |
pgimeno |
was it? |
| 19:21 |
pgimeno |
I had no idea |
| 19:22 |
sfan5 |
https://github.com/minetest/minetest/pull/9627 |
| 19:24 |
pgimeno |
oh nice |
| 19:25 |
lhofhansl |
Looking at it for clues for what I'm seeing. |
| 19:30 |
lhofhansl |
Looks like I am just seeing the "infamous y=48 bug". And 10637 increases the likelihood of seeing that. |
| 19:32 |
sfan5 |
paramt said it wasn't that bug in the thread |
| 19:35 |
lhofhansl |
In that case I think we should merge that (10637). It does not make things logically worse, it avoid generating the same chunk multiple times, and avoid calling Lua on_generated. It simply picks the first attempt to generate a chunk rather than the last. |
| 19:36 |
pgimeno |
sfan5: looks like #8346 is not totally fixed. See last few paragraphs: "The fix is to check if the thread isRunning() before checking if isCurrentThread() within EmergeManager::getCurrentMapgen(). But there's a catch. There's a possible TOCTTOU race between isRunning and isCurrentThread where the thread is deleted right after the first check." That's why my patch https://gitlab.com/pgimeno/minetest/-/commit/4be3b84431ab213eb5f466f0d0477498041 |
| 19:36 |
pgimeno |
b464c added a mutex. |
| 19:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/8346 -- Segfault on server finalization when num_emerge_threads > 1 |
| 19:36 |
pgimeno |
iios |
| 19:36 |
lhofhansl |
Then we can look into the block boundary issues with multiple threads. |
| 19:36 |
pgimeno |
posting the link again which was broken: https://gitlab.com/pgimeno/minetest/-/commit/4be3b84431ab213eb5f466f0d0477498041b464c |
| 19:36 |
pgimeno |
iios = oops |
| 19:37 |
pgimeno |
lhofhansl: I agree it's an improvement, and I don't think it will make things worse |
| 19:38 |
pgimeno |
if it makes certain issues more likely, these issues need to be addressed separately |
| 19:38 |
sfan5 |
pgimeno: there's https://github.com/minetest/minetest/commit/cb159f8d8af4556391db8a6875657625733eeb11 but I don't think that fixes the race |
| 19:38 |
lhofhansl |
Mapgen with num emerge threads = 0 is 3-4x faster on my machine (it'll use 14 threads since I have 8 cores with 2 HTs each) |
| 19:38 |
sfan5 |
and it should be possible to fix the issue in Thread without a mutex |
| 19:40 |
lhofhansl |
Just to be sure... I am not seeing a thread correctness issues. What I am seeing is slightly different mapchunks being generated based on the order of things. |
| 19:40 |
sfan5 |
yeah that's sort of an issue |
| 19:40 |
lhofhansl |
It is :) |
| 19:41 |
pgimeno |
sfan5: ok, just note that the mutex is not a performance bottleneck, so it's not a big deal to use it if it makes the code simpler |
| 19:41 |
lhofhansl |
10637 does not change that. It just avoids lots of duplicate work. |
| 19:42 |
sfan5 |
just so it's clear: I don't see any issue with your PR whatsoever, just haven't had the time to test it yet |
| 19:43 |
lhofhansl |
Cool. |
| 20:02 |
|
Anchakor_ joined #minetest-dev |
| 20:05 |
|
Anchakor left #minetest-dev |
| 20:20 |
|
Fractalis joined #minetest-dev |
| 20:21 |
lhofhansl |
BTW. Changing MAP_BLOCKSIZE from 16 to 32 gets me almost 4x higher FPS on the client! (#10647). Not something I would have expected. |
| 20:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/10647 -- Optimize map rendering |
| 20:22 |
lhofhansl |
Not saying we should do that, just that there's a lot of room for improvement! |
| 20:29 |
Krock |
> pushes partial changes where it's still not working |
| 20:29 |
Krock |
> compiles again, nothing modified |
| 20:29 |
Krock |
> unittests work |
| 20:29 |
Krock |
me: *surprised* |
| 20:41 |
celeron55 |
lhofhansl: back when i decided on that value 16 made a lot of sense, and these days many people still run either phones or very old hardware that need such a lot value |
| 20:41 |
celeron55 |
these days on any performance oriented computer it's way too low of course |
| 20:42 |
celeron55 |
the variety of computers really has exploded during this time |
| 20:42 |
celeron55 |
you can get new laptops that are almost as slow as laptops were 10 years ago |
| 20:47 |
celeron55 |
there probably should be an extra layer for rendering that would recombine blocks into whatever size fits the machine's rendering performance |
| 20:48 |
lhofhansl |
Exactly. We should be able to coalesce on the client. |
| 20:48 |
celeron55 |
it would increase cpu load though so it might have to have a mode for slow machines that just renders them as-is like now |
| 20:48 |
lhofhansl |
Yeah... As a client config option. |
| 20:50 |
celeron55 |
there was the one guy that popped up in here from time to time a few months ago who was writing lots of rendering improvements |
| 20:50 |
celeron55 |
he's disappeared since then though and didn't publish the code |
| 20:50 |
celeron55 |
or did he have a personal repo? i never saw a link |
| 20:51 |
celeron55 |
he always used an anime character model in his short videos or gifs |
| 20:52 |
MTDiscord |
<wwar> appears for the first time (not like the guy you are talking about) |
| 20:53 |
MTDiscord |
<Jonathon> i would guess liso, but probably not? |
| 20:53 |
MTDiscord |
<wwar> I cant guess bc i left mt for sometime... |
| 20:54 |
MTDiscord |
<Jonathon> https://www.reddit.com/r/Minetest/comments/jx41ti/working_on_dynamic_shadow_mapping_for_mt/ and https://forum.minetest.net/viewtopic.php?f=7&t=25556 possibly who you are thinking of? |
| 20:56 |
lhofhansl |
There's no reason that MAP_BLOCKSIZE is a power of 2, right? Perhaps we can start by making it configurable. Probably controlled by the server, and needs to be part of the map metadata. |
| 21:02 |
celeron55 |
Jonathon: no i don't think that's the one |
| 21:02 |
MTDiscord |
<Jonathon> ah ok, sorry |
| 21:02 |
celeron55 |
i never saw him anywhere but on irc |
| 21:03 |
celeron55 |
lhofhansl: having it constant allows compiler optimization of performance critical loops in lighting, map generation and whatnot |
| 21:03 |
celeron55 |
maybe worth testing, but constants are good |
| 21:09 |
pgimeno |
that was hecks, he shows up from time to time but I don't think he's too interested in sending PRs |
| 21:11 |
celeron55 |
having the code available would be nice |
| 21:12 |
pgimeno |
if he distributes his modified version, he's obliged to share his modified sources |
| 21:13 |
celeron55 |
of course |
| 21:13 |
celeron55 |
i'm hoping he doesn't just drop it and leave it unpublished on his hard disk |
| 21:14 |
pgimeno |
how does one comply with this part of the LGPL 2.1 as it applies to Minetest? "The modified work must itself be a software library" (condition 2a) |
| 21:20 |
Krock |
heh. no idea |
| 21:20 |
celeron55 |
you apply it like it is applied in the original distribution |
| 21:20 |
celeron55 |
i guess in this case the library interface is the modding API |
| 21:21 |
celeron55 |
of course you could replace it with another library interface, even a native one like for what LGPL was originally intended for |
| 21:22 |
MTDiscord |
<GreenXenith> celeron55: hecktest |
| 21:23 |
MTDiscord |
<GreenXenith> hecktest is the guy that was doing that |
| 21:24 |
pgimeno |
hecktest is his GitHub handle, hecks is his IRC nick |
| 21:24 |
MTDiscord |
<GreenXenith> ah right |
| 21:24 |
specing |
Well see, this is really simple |
| 21:24 |
specing |
you relicense your own fork of minetest to GPL or AGPL and be done with it |
| 21:24 |
|
GreenXenith joined #minetest-dev |
| 21:25 |
zughy[m] |
The only anime guy I can think of is hecktest, but he's still active on GitHub |
| 21:25 |
MTDiscord |
<GreenXenith> Well thats the guy he's referring to |
| 21:26 |
zughy[m] |
I mean, it'd make sense according to his knowledge: https://github.com/minetest/minetest/issues/10647 |
| 21:45 |
celeron55 |
yeah hecktest for sure |
| 21:58 |
|
proller joined #minetest-dev |
| 22:06 |
lhofhansl |
Merging #10667 soon. |
| 22:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/10667 -- Fix camera panning glitches (partially revert #10489) by lhofhansl |
| 22:11 |
sfan5 |
Krock: for 10661 I suggest testing your code compiled with -fsanitize=address |
| 22:11 |
sfan5 |
because the segfault you have looks like a buffer overflow or similar |
| 22:57 |
|
fluxflux joined #minetest-dev |
| 23:12 |
|
olliy joined #minetest-dev |
| 23:12 |
ronoaldo |
the more I play with the game and code, review issues, the more I like this project :) |
| 23:16 |
|
olliy_ joined #minetest-dev |
