Time Nick Message 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: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: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 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 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: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: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 appears for the first time (not like the guy you are talking about) 20:53 MTDiscord i would guess liso, but probably not? 20:53 MTDiscord I cant guess bc i left mt for sometime... 20:54 MTDiscord 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 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 celeron55: hecktest 21:23 MTDiscord hecktest is the guy that was doing that 21:24 pgimeno hecktest is his GitHub handle, hecks is his IRC nick 21:24 MTDiscord 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:25 zughy[m] The only anime guy I can think of is hecktest, but he's still active on GitHub 21:25 MTDiscord 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 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 23:12 ronoaldo the more I play with the game and code, review issues, the more I like this project :)