Time Nick Message 07:56 [MTMatrix] Reminder that today's meeting is at 15:00 UTC (in ~7 hours) and not at 18 UTC 07:58 [MTMatrix] ..I now realise we might have not informed people outside the staff about this. In case, I'm sorry. We chose to do it so that srifqi can take part in it without going to sleep at 3AM 08:57 grorp Merging #13859, #13836 in 20 min 08:57 ShadowBot https://github.com/minetest/minetest/issues/13859 -- Misc. mainmenu fixes by grorp 08:57 ShadowBot https://github.com/minetest/minetest/issues/13836 -- Android: Add `field_enter_after_edit[]` formspec element by grorp 09:07 Krock I find it strange how an experimental feature is documented in the lua_api regardless 09:08 Krock and even increasing the formspec version ... well anyway. not that it hurts anyone 09:14 grorp The formspec version needs increasing anyway, because of the new "focused" selector. 09:15 Krock fair 09:18 erle so why was it not increased when focused happened? 09:19 Krock because only mods would rely on that for feature detection. there is no other technical reason 09:23 erle well it is really version detection here, not feature detection 09:25 erle having done very little with formspecs (basically only the node-associated ender chest formspec hack in mcl2) … why is there not a feature table for it then? i guess it does not make sense on some level? 09:32 Krock formspecs are client-side 14:21 Krock Meeting in 40 minutes 15:01 [MTMatrix] hello 15:01 srifqi hello 15:01 grorp hi 15:01 Krock Hello. Let's get started. 15:01 Desour hi 15:01 Krock obligatory ping for rubenwardy 15:02 rubenwardy hi 15:02 Krock hello :) 15:02 Krock okay. 5.8.0 release is one of the topics today 15:02 Krock https://github.com/minetest/minetest/milestone/22 15:02 rubenwardy sfan5 15:03 Krock he did not react to the discussion point, thus I assume he's not available. let's see anyway 15:03 Krock s/point/post/ 15:03 Krock how's the progress of MTG debundling? 15:03 grorp #13850 needs a review 15:03 ShadowBot https://github.com/minetest/minetest/issues/13850 -- Notify users that they need to reinstall MTG if they still want it by grorp 15:04 Krock I see. it's a seamless transition to CDB 15:04 Krock assuming that the user has access to the internet, of course. 15:05 Desour if they don't, they can't upgrade minetest 15:05 Krock new users might not realize what's happening 15:05 grorp and we have to decide whether #13799 should be a blocker for debundling MTG 15:05 ShadowBot https://github.com/minetest/minetest/issues/13799 -- Allow games (just MTG?) to enforce lock-step upgrades with versions 15:06 rubenwardy I have a review in progress for #13850 15:06 ShadowBot https://github.com/minetest/minetest/issues/13850 -- Notify users that they need to reinstall MTG if they still want it by grorp 15:06 Krock MTG could in theory be continued to support multiple Minetest versions just like any other game 15:06 Krock at the cost of additional backwards compat effort 15:07 rubenwardy I think min_minetest_version + update detection is enough to resolve that issue 15:07 Krock old clients would have to download the zip manually from github in that case 15:08 Krock also: is the upgrade notification dialog shown before this prompt? it would be important to check for this order too 15:08 rubenwardy Update detection only works when installed from contentDB though. If an old version of MTG remained installed (for example, their update method is to extract a zip file) then the old version will remain without any update prompts 15:08 rubenwardy This affects Android and Windows predominantly 15:08 Krock also: what if there's no compatible minetest_game found on CDB? that needs testing too. this startup lua file must not error in any case 15:09 Krock are there still Windows installer builds for Minetest? 15:09 rubenwardy theres' not 15:09 rubenwardy I'd like to see that 15:09 Krock huh. I thought there was one on the forums 15:10 rubenwardy there's also official support in Minetest, it's just not used as sfan5 isn't confident of MSVC 15:10 Krock ah. there we go https://forum.minetest.net/viewtopic.php?p=423886#p423886 15:10 rubenwardy #9166 15:10 ShadowBot https://github.com/minetest/minetest/issues/9166 -- Create official Windows releases with installers using GitHub CI 15:10 Krock well, MTG would have to be detected in this case too (but that's a task for later) 15:11 Krock otherwise they will always have to ship MTG with new installers which would otherwise fail to find updates based on the old version 15:11 Krock (assuming that I interpreted your message correctly) 15:13 rubenwardy the installer should either remove MTG or migrate to the CDB version 15:13 rubenwardy we have an 'installer' on android 15:13 Krock makes sense 15:15 Krock would you say that it's okay to debundle MTG for 5.8.0? 15:16 Krock in regard to CDB reliability and assuming that this PR works 15:16 erle tangent: did anyone talk with the maintainers of linux distributions about the unbundling efforts? otherwise they might continue shipping minetest_game as part of packages with names like minetest-data (which contains builtin and stuff on debian) 15:16 rubenwardy yeah, we'd need to request that - but at least that wouldn't break anything, they'd just continue to bundle MTG 15:16 erle same for devtest btw 15:17 srifqi is devtest still shipped in minetest-data? 15:18 erle yes 15:19 erle https://packages.debian.org/sid/all/minetest-data/filelist 15:19 Desour devtest should already be included, if they don't explicitly set INSTALL_DEVTEST, or do run-in-place builds 15:19 Krock so let's see how quickly we can review #13850. it does not appear to be a feature but I'd prefer to have it done better sooner than late to fix up issues if needed 15:19 ShadowBot https://github.com/minetest/minetest/issues/13850 -- Notify users that they need to reinstall MTG if they still want it by grorp 15:19 rubenwardy <+Krock> would you say that it's okay to debundle MTG for 5.8.0? 15:19 rubenwardy Doing so delays the release but could be worth it 15:20 Krock a delay by about one or two weeks again 15:20 rubenwardy on the other hand, leaving it for 5.9.0 would give more time to refine things (ie: have the CDB redesign) 15:20 Desour erle: that's 5.6.1 15:22 Krock considering that there's not much else on the milestone I'd prefer to start the feature freeze today and keep the debundling for early 5.9.0-dev for plenty of testing 15:22 erle Desour it is ”sid” though. indicating how the update-in-lockstep stuff might go: you would always have old clients in case of unbundling and need to handle them somehow, unless you want users of those distributions to rely on the minetest_game of their distribution 15:22 Krock erle: MTG and Minetest used to be in lockstep anyway so that's fine for those builds 15:22 rubenwardy another thing to refine would be the new user messaging - making it clear that MT is a game creation platform, and doing user testing to make sure users understand it 15:23 [MTMatrix] guy who's been to about a dozen convnetions in the last year: please let's debundle it in 5.8 15:23 [MTMatrix] *conventions 15:23 Krock rubenwardy: yes that sounds reasonable, hence the early merge for 5.9.0-dev 15:24 Krock perhaps we can gain a better 5.8.0 release overview (or rather its delays) by having a look at #13476 15:24 ShadowBot https://github.com/minetest/minetest/issues/13476 -- Settings UI mega-issue 15:24 erle how about offering two versions on the download website for 5.8 and seeing how it is received? 15:24 erle like one with and one without minetest_game 15:25 Krock erle: sfan's Windows dev builds would take care of that without additional effort 15:25 erle well they are more like release and playetst, but yeah, if users can find them, you are probably right 15:25 Desour it doesn't matter how it's received. we already decided we want to debundle mtg. doing two release versions sounds like useless work overhead 15:25 erle ok 15:26 Krock rubenwardy: what's left to do for the settings UI? is there anything that would delay 5.8.0? 15:26 Krock or rather .. what's your progress on the open points? 15:26 rubenwardy there's hiding the "Minetest" background image and also a filter to hide all advanced settings, I haven't started either and neither is fully blocking 15:27 Krock right. the UI does work and looks good. I think it's good enough for 5.8.0. if one of the points can be addressed in the feature freeze, the better. 15:28 grorp Since we have "decided" that we only want to hide whole setting pages, the advanced settings thing should be quite easy to do 15:28 grorp I could make a PR 15:28 rubenwardy yeah. It will hide all mapgen pages and those in the advanced section 15:29 Krock ^ https://github.com/minetest/minetest/pull/13730#issuecomment-1712665824 15:29 Krock grorp: it would be great if you could have a look at that. thank you. 15:30 rubenwardy Let's say that two weeks gives us time to do this settings thing, and the remaining debundling stuff. Seems worth it to me 15:31 Krock hmm 15:32 Krock two weeks is enough to test the debundling? I don't think many people would actually test that. it would be pretty much dev-only testing. 15:32 rubenwardy two weeks plus two weeks feature freeze 15:33 Krock so it would be good to have the debundling merged in the next few days to give it plenty chance for testing in the wild 15:33 Krock * few days or week 15:33 grorp for the "reinstall MTG" PR, I made the assumption that MTG has already disappeared when the user first starts the new version 15:34 rubenwardy that makes sense - we do need to handle the case where it's not uninstalled though 15:34 rubenwardy like when a user updates by extracting a zip on windows 15:34 rubenwardy I'm not that available in the next two weeks, actually, so I wouldn't be able to help much with a release, settings, or debundling 15:34 Krock why not? RUN_IN_PLACE builds might take the old games and mods, simply replacing builtin, textures and bin 15:35 rubenwardy we probably don't want users to remain on MTG 5.7 forever 15:35 erle some users remain on much older versions, see the debian thing ;) 15:36 rubenwardy and they won't be using an up to date engine either 15:36 Krock this migration is rather difficult due to lack of version control of preinstalled content 15:37 grorp perhaps we can just check if there is a MTG without a version in game.conf, and if there is, always consider it updatable? 15:38 Krock Minetest could detect it well if Minetest game came preinstalled including the CDB version information. Although the entire point is to debundle it now... 15:39 rubenwardy grorp: you'd also need to make sure MTG isn't in a readonly directory 15:39 Krock (^ mainly in case of Linux system-wide installations) 15:41 grorp and what about people who use a Git version of MTG? their MTG would always be shown as updatable 15:42 rubenwardy can use min_minetest_version to only do special stuff for MTG 5.7 15:42 rubenwardy s/use/check/ 15:42 Krock grorp: game.conf does not contain the "release" field in that case, thus is also not shown as updatable 15:43 Desour why would you want to update non-contentdb mtg installs in the first place? 15:43 Krock so yes blindly assuming that it could be updated is not a good strat 15:43 rubenwardy Desour: for situations where old installs of MTG are kept when updating MT 15:44 Krock or rather when they survive overwriting of folder contents 15:44 grorp Krock: what could be a better strategy though? 15:44 rubenwardy When updating MT from 5.7 to 5.8, you might end up with MTG forever at 5.7 with no notice to the user that ther'es a new copy available 15:45 Krock grorp: to have MTG shipped with the "release" line in game.conf upon Minetest installation. However, that would habe to be done a year ago since we're now talking about removing MTG 15:46 Desour can such situations, where the old mtg is somehow kept, be changed to replacing the mtg folder with some empty file 15:46 Desour ? 15:46 erle what do you mean exactly? 15:46 rubenwardy the issue we're having is how to detect an old MTG install vs one just cloned from git 15:46 rubenwardy turns out game.conf doesn't have min_minetest_version 15:47 rubenwardy it won't have release because it's not from CDB 15:47 erle i am probably missing something here, but something cloned from git will have a .git folder? 15:47 rubenwardy or installed manually from .zip 15:47 srifqi1 wait, which kind of users are we talking about? i mean, there are many ways to use Minetest. when i did not know much about how MT work or how to update it, i just extracted the new version and copied mods/*, worlds/*, and games/* (except minetest_game). i can know that the minetest_game is missing in the new version's games folder. (i use Windows) 15:48 Krock Windows users who download the Minetest *.zip, primarily. 15:48 erle yes my friend also did this on windows: install new minetest, copy over stuff 15:48 Krock installers could be changed to remove minetest_game 15:49 Krock (like the one distributed on the Minetest forums) 15:49 MTDiscord the windows version really should keep share and user data separate... 15:49 Desour that's where I meant we could replace the minetest_game folder with an empty file. if the file is there, the file browser will warn and not just copy over the old mtg 15:49 rubenwardy how about MTG 5.8 comes with `min_minetest_version = 5.8`. The minetest engine can check whether that .conf field exists, if it doesn't exist then it could show a prompt to update to a CDB install 15:50 rubenwardy Desour: oh interesting approach, hmm, won't it just skip copying over the file though? 15:50 Desour rubenwardy: what if I want to test out an old git version of mtg? 15:50 Krock unless it's read-only or has a .git dir 15:50 rubenwardy can ignore any prompts that are added 15:50 rubenwardy yeah or that 15:50 Desour rubenwardy: pcmanfm at least would ask for each conflicting file 15:51 grorp btw, I probably won't be available much in the next few weeks either 15:51 Krock Desour: the empty file trick only works on Linux/UNIX because folders are files. on Windows you can have both 15:52 Desour oh no 15:52 erle oh LOL 15:53 Desour empty folder with some file then? :D 15:53 Krock considering that both grorp and rubenwardy are not around much I wonder whether we can get the debundling step through in the next 2 weeks 15:53 Krock otherwise we'll again delay a release by another 2 weeks 15:55 Krock maybe let's poll? Option 1: +2 weeks time for debundling (and maybe other fixes) or Option 2: enter feature freeze now, debundling later 15:55 Desour if we delay the release, then please don't already begin feature freeze. delay before freeze is kinda ok, but delay in feature freeze, causing it to last weeks is kinda annoying 15:57 Krock Desour: yes, that's why I'd like to hear what's preferred. delay or freeze + postpone 15:58 Krock tbh I don't care whether or not we wait 15:58 Desour I'd also be fine with both options 16:00 Krock rubenwardy grorp srifqi - opinions? freeze or +2 weeks? 16:00 srifqi i'd like to have MTG be debundled in the next release, so option 1 16:01 grorp I'm fine with both options too 16:02 Krock so let's give it +2 weeks time and let's see then how far we've got 16:03 Krock updated milestone to Oct 29, feature freeze in 2 weeks. 16:04 erle what exactly do i have to do to get the dev team to drop the TGA deprecation before 5.8.0, just make a PR and see how it goes? i have so far debugged a TGA memory corruption within 4 hours, updated tga_encoder, and told upstream irrlicht which resulted in patches for every issue AFAIK. right now i worry that future complaints about breakage in texture-generating mods will be pointless if the deprecation notice stays in. this is 16:04 erle as a purely procedural question – so if you have opinions on texture formats please do not write them here please. 16:05 Krock I'd prefer to skip the #11016 topic. This discussion has been going on for so long that I already forgot what the seemingly best choices would be 16:05 ShadowBot https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 16:05 Krock I'll keep it mentioned as a friendly reminder for devs to read through the discussion briefly and perhaps judge suggestions or provide new ones 16:06 erle related and amusing, but also sad: I noticed that BMP has somehow not been deprecated, despite it being more code, less used AFAIK (is it used at all?) and a shitty format that could easily be removed. make of this what you will. 16:07 Krock erle: please propose a PR that is according to your preferences which then will serve as a place to collect opinions from various sides 16:07 erle ok thanks 16:08 erle until when would it need to happen? this is a non-functional after all. 16:08 [MTMatrix] about #11016: basically we've left the author hanging for months 16:08 ShadowBot https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 16:08 Krock erle: 2 weeks until feature freeze 16:08 erle yes but features are functionals 16:08 Krock Zughy: this shows how tricky it is to fix 16:09 erle but if you say within 2 weeks, i get it 16:10 MTDiscord erle: I've not been able to find a single BMP file in the latest releases of all packages currently on ContentDB. xmaps seems to be the only package on CDB using TGA (well, besides devtest...). 16:10 Krock erle: ah. I now see what you meant with "non-functional" (not in the sense of "defective"). More than 2 weeks in this case. Not sure how much, depending on the progress of the other PRs 16:10 MTDiscord the only reason BMP was kept was due to the built-in irrlicht font 16:10 MTDiscord however, this can be easily converted into png 16:11 MTDiscord I think deprecating BMP is a good idea. 16:11 erle luatic, you are missing a huge point here, it is a texture format for generated textures after all. this was discussed already, query me if you want a proper explanation. 16:11 MTDiscord erle: I'm aware 16:11 MTDiscord I don't think there's any BMP encoders for minetest in the wild... 16:12 Krock might it be possible to offload this BMP deprecation idea to a separate issue? 16:12 MTDiscord yeah 16:12 erle yes 16:12 MTDiscord sadly we can't deprecated .x, it seems quite a few packages have .x models (about 202 .x files in latest releases) 16:12 MTDiscord deprecate .x as easily* 16:13 [MTMatrix] lawsuit from Musk incoming 16:13 MTDiscord modlib .x reader when? :^) 16:13 MTDiscord (so we can convert them into b3d) 16:13 MTDiscord i think i peeked at .x and then was like "hell nah" 16:13 erle luatic you have to understand the code though. i am sure that the ”TGA in item meta” thing is a bit weird, but for anything that can be easily generated (can .x?) you can not just assume that filenames are enough 16:13 Desour regarding dual wield: I thought the author would follow their suggested agenda, as described in https://github.com/minetest/minetest/pull/11016#issuecomment-1458561048 . iirc, the points is what we requested in irc. my suggestion (which I, but only I, so doesn't matter, would still would prefer) may have caused confusion. sorry if that's the case 16:13 MTDiscord erle: haha, i don't think anyone is generating .x 16:13 MTDiscord .x is a wild format. it has both a binary and text format 16:14 MTDiscord dog squad: hecks once mentioned generating text format x models :^) 16:14 MTDiscord the most i've seen modders (besides me) generate (concerning modes) is obj 16:14 erle it's beside the point to discuss it here if it can not be deprecated at all 16:14 erle please, there are still issues for the meeting, or not? 16:15 erle zughy i do not know if you are aware, but lizzy (author of dual wild PR) maintains their own minetest client (dragonfire) and i am not even aware if they put it in dual wield (i can not find it) 16:15 MTDiscord i've got a one approval bone override thingy PR that has been collecting dust for a while now but realistically it's probably too late for it to get a second approval and make it into 5.8 16:16 Desour luatic: the milestone has been delayed 2 weeks. so it can be merged in the next 2 weeks and go into 5.8 16:16 MTDiscord hmm nice, guess i'll just drop it here then if anyone wants to take a look: #12388 16:16 ShadowBot https://github.com/minetest/minetest/issues/12388 -- Extend bone override capabilities by appgurueu 16:17 Krock Desour: the suggested agenda seems reasonable. although, such experimental setting (to force items) might not even be needed 16:20 erle has anyone contacted lizzy since she last said something about the PR? 16:20 Desour Krock: if you mean the proposed allow_offhand itemdef field, iirc it would be required so that old mods that don't take the extra offhand parameter in callbacks won't break, e.g. by assuming the passed item is the wielded item 16:21 Krock Desour: no, I meant the global setting 16:21 Desour ah, I'm blind, sry 16:23 Desour you can only sent the offhand item via lua api, right. I don't see a need for the setting then either 16:24 Krock would be fancy if we could modify the itemstack metadata to contain the source of it 16:25 Krock but that's only wishful thinking because the ItemStack() constructor discards that 16:25 Desour sounds like an ugly hack 16:25 Krock heh :3 16:26 erle the whole offhand problem space seems to me like it contains a bunch of non-obvious solutions and given past APIs for non-obvious use cases … why not start with purely visual support for a second wieldmesh? 16:27 erle like, mcl2 shields-but-better? 16:28 Krock I also mentioned that idea a few times but it hasn't reached popularity 16:28 erle well the whole 2 handed thing has not reached ”popularity” if you ask me ;) 16:29 Desour I keep seeing people requesting this feature though 16:29 erle yes, but almost no one knows *exactly* how it should work if they propose it 16:30 erle i.e. it would probably be easier to agree on how to enlarge maps (fix all datatypes, work around inaccuracies) 16:30 erle anyway, i think anything that enables mcl2 to implement hacky lua offhands might yield knowledge about how the *shape* of the API might look ideally 16:30 erle and tbh i would like to have users to have an xmaps map in offhand 16:30 erle so i don't have to use the HUD for this 16:31 erle which as far as i can see, would be a purely visual thing 16:31 erle also other items might work like that: compasses for example 16:31 erle or death compasses or player markers or clocks 16:32 erle Krock have you tried implementing it or are you not that invested? 16:32 erle (i am not that invested truly) 16:38 Desour another PR in the 5.8 milestone: #13192. author wanted the revise it, to add an option, but hasn't done it in months. @Zughy: is there a reason why you marked it as draft, and did not add "action/change needed"? 16:38 ShadowBot https://github.com/minetest/minetest/issues/13192 -- Enable LTO building on supported platforms by default by tamara-schmitz 16:40 srifqi my guess is that the author waits sfan5's reply to the author's explanations, so no work has started 16:40 srifqi a simple "yes" or "approve" reaction might do 16:41 srifqi but since sfan5 self-requested a review, the author might become hesitant to do any work for the PR 16:41 Krock okay. left an opinion from my side. hopefully this helps a little bit to proceed with the PR 16:42 srifqi thank you for that. hopefully, the agenda will start soon 16:43 Krock Desour: this Draft mark seems to be incorrect 16:43 Krock > is a good idea to add that. gonna revise the patch 16:43 Krock okay it seems that the author has different priorities 16:45 Krock it was added to the milestone very early on. Minetest survived without LTO for over ten years at this point, thus it does not seem to be a blocker 16:46 Desour +1 16:46 Krock I'll put a note into the meeting points. maybe it'll make it into 5.8.0-dev in the next two weeks 16:47 Krock did someone already have a look at #13764? 16:47 ShadowBot https://github.com/minetest/minetest/issues/13764 -- Refactored the liquid system, and added an optional feature for liquids to flow to the next slope. by cosin15 16:49 Desour I quickly checked the answer for "Do we need an extra option to disable this or does cmake already provide one?". there seems to be none. (there's CMAKE_INTERPROCEDURAL_OPTIMIZATION, but that enables it for all targets, and doesn't turn it off. and idk if you can set it from command line) 16:50 Krock Desour: you could post your findings there. it would at least put a reminder for the author 16:50 Desour yes 16:52 Desour done 16:52 Krock any inputs regarding the liquid system? is there a demand for that' 16:53 erle well, the single thing about the liquid system that prevents lavacasting is falling speed of fluids being the same i think, regardless of spreading speed. i might be wrong here. 16:54 Desour no coredev has expressed concept approval for > 2 weeks. so we should close it as of roadmap rules, right? 16:54 erle lol 16:54 Krock judging by the PR reactions it seems to be a liked feature, though. 16:55 erle if refactoring and adding tests needs concept approval i have lost all hope lol 16:56 [MTMatrix] If MTG is getting debundled, reminder that it'd be nice to add #13282 as well 16:56 ShadowBot https://github.com/minetest/minetest/issues/13282 -- Remove controls listed in the pause menu (no touchscreen) by Zughy 16:56 Desour erle: well good then that it's not about only refactoring and tests 16:56 erle what do the controls in the pause menu have to do with mtg? 16:57 [MTMatrix] you can't say anymore "well, we left them there since they're all useful because of MTG shipped by default" 16:57 srifqi i'd like to have it (13764) a separate PR first since the concept of refactoring the liquid system is good for me 16:57 erle other games *do* use them too and do not display them in-game (might be different for arena games obv) 16:58 srifqi but it seems like the author wants to have the concept approved first before the refactoring process 16:58 [MTMatrix] not all the games, and the list of controls is incomplete. Please read comments in the PR before writing 16:58 srifqi (which is acceptable in my opinion) 16:58 srifqi ah, sorry for the interruption 16:59 grorp more off-topic: #13861 opened, as discussed 16:59 ShadowBot https://github.com/minetest/minetest/issues/13861 -- Add advanced settings checkbox and hide advanced settings by default by grorp 16:59 erle okay, i'll refrain of commenting on the usefulness of removing information from the interface for now 16:59 Krock thank you grorp 16:59 erle Desour well you either follow the roadmap or not, but it might make sense to have a graveyard of rejected stuff 17:00 erle also you can give concept approval, not? 17:00 Desour erle: there are closed issues and PRs, that's a searchable graveyard 17:00 Desour I can but I don't want to, as already said last meating 17:00 Desour ee* 17:00 Krock srifqi: I'd also prefer the refactor first, which then helps to test the performance 17:01 Krock surely there's less liquid flow happening - but only with the new method 17:01 Krock it has to be as performant or faster as the current implementation 17:02 Krock so let's give the concept approval? 17:03 erle Desour yeah, but it's not really giving the full picture, given that the number of good stuff rejected for procedural or emotional reasons is relatively little (as far as i can see) compared to the number of things that are just not useful. 17:03 Krock the tests will then judge about its fate 17:03 srifqi Krock: yes, i think 17:03 erle Desour it might make sense to have a graveyard for ”rejected, but not on technical grounds, can be tried again”. compare this with “rejected, but on technical grounds” or “rejected, on project direction grounds”. 17:04 erle and no, the labels on closed issues are NOT useful for that 17:04 erle (so far) 17:04 srifqi the author also has stated that it can be an optional feature, so if the changes turn out to be not working (or not as good as the concept), it should be easy to remove/improve it 17:05 erle having worked with the liquid code a bit and ultimately not chosen to improve it due to uncertainties of what this would entail, i'd love tests 17:05 sfan5 did I miss anything? 17:06 sfan5 (I have a short moment to comment on something if there's anything) 17:06 srifqi i _might_ pinged you about when we were discussing about dual wielding 17:06 Desour srifqi: if we want to keep the option open to remove it later, we should definitely mark it as experimental, or else players will get broken worlds 17:06 srifqi i agree with that 17:06 erle what do you mean with ”mark it as experimental”? 17:07 MTDiscord On the topic of tests, I am still waiting for next actions on https://github.com/minetest/minetest/pull/13609 from rubenwardy. He hasn't been responding to me, so if someone else would be able to tell me what the next steps are that would be helpful. 17:07 Desour erle: documentation, e.g. for the setting if there's a setting 17:07 erle Desour, as web browsers have shown, devs use stuff. if you want it to be experimental, hide it behind a feature flag and make it otherwise invisible. 17:08 erle the whole ”we can just mark this as experimental” thing has led to things in css being prefixed with -webkit or -moz and never ever being dropped 17:08 erle it simply does not work as you think it does to assign blame 17:09 erle like the best case you have is stuff still breaks but you can point fingers and said “it is your fault, not mine” 17:09 erle which may be ego-preserving, but the breakage is still there 17:09 Desour "this feature is experimental and if you use it, you might loose your world after an update" should be fine though, for 1 or two releases 17:09 erle again, the proven way to make users REALIZE this is to make it a feature flag 17:10 rubenwardy josiah_wi: I don't have any comments on that PR as I haven't started reviewing it, I only attempted to see if I could setup catch2 in clion but couldn't. I don't really have time to mess with that now 17:10 erle i refuse to elaborate further 17:10 Desour erle: feature flag as in compile flag? that would be good 17:10 Krock @josiah_wi since we already make use of Catch2 I don't see any reason why this shouldn't be merged 17:10 erle Desour yeah for example 17:11 MTDiscord rubenwardy, I am ready to install CLion, learn how to use it, and figure out how to set up Catch2, but I hoped you had more details so I wouldn't be shooting in the dark. 17:11 MTDiscord I was under the impression everything should be IDE-agnostic. 17:11 erle i would also like to have tests. i do understand that the dev team as a whole does not believe in test-driven development, but i do. 17:12 erle i.e. 1. add failing test case. 2. make it pass. 3. repeat 17:12 Krock Is there any other topic or note that I should add to the meeting? 17:12 erle maybe anything changing about hardware/platform support/requirements that needs discussion? 17:12 erle or has this not changed so far 17:13 Krock OpenGL 3 is yet WIP, thus no changes. 17:14 Desour removing #13192 from milestone (forgot that earlier) 17:14 ShadowBot https://github.com/minetest/minetest/issues/13192 -- Enable LTO building on supported platforms by default by tamara-schmitz 17:15 srifqi oh, if there is still time, can we quickly discuss about #13808? 17:15 ShadowBot https://github.com/minetest/minetest/issues/13808 -- Language blacklist does not exclude translations on Android 17:16 srifqi should we add a filter to the src/gettext.cpp or just at build time (like what CMake does for now)? 17:16 Krock srifqi: this needs addressing but I have no idea about this code 17:18 Krock either way would be fine, I think. 17:18 srifqi i was thinking about doing both 17:18 Krock if there's already relevant code in CMake it seems intuitive to me to implement it there first 17:19 Krock if it's too complicated, do it in gattext.cpp 17:19 Krock *gettext.cpp 17:19 srifqi so, double check: (1) not compiling the blocked language at build time and (2) not selecting the blocked language at run time 17:20 MTDiscord What about sfan's comment that it might be hard to defer that to CMake? 17:20 erle josiah_wi btw i suggest to watch my talk about build system failure modes i did at CCC camp if you are still interested in that problem space. 17:20 erle (can't query a discord user) 17:21 srifqi test 17:21 Desour passed 17:21 Krock srifqi: as long they're properly referenced from one to the other I suppose that's okay 17:22 Krock to not have them go out-of-sync 17:22 srifqi ah, the bridge from IRC to Discord broke 17:22 srifqi Krock: that's the hard part, i guess 17:23 srifqi since those are located in different places 17:24 erle i have one more thing: i talked with some people and i think it might make sense to actually write down the real-world contribution issues to waste less time. not sure. 17:24 Krock Completed the meeting notes. I'll be back later. Thank you for participating. 17:24 erle like, tests without a fix for the issue being tested will never been taken. 17:24 Desour thanks for organizing 17:24 erle should i open an issue for that once i can figure out what to write? 17:27 srifqi erle: probably 17:27 srifqi thank you everybody for participating in this night 18:07 erle Krock, apparently purely visual offhand is already possible somewhat with mcl_offhand: https://codeberg.org/mineclonia/mineclonia/pulls/505 18:07 erle the issue here being that any functions regarding placement etc. would run on the server, so it would not be too nice to place nodes 18:07 erle (except in singleplayer obv) 20:08 x2048 celeron55, everyone. As life goes on, I won't have time for contributing to minetest in the forseeable future and I'd like to step down as a core developer. I've learned a lot while working on MT and hope I made a difference. 20:12 x2048 Soneone will need to take over or close #13833 and #13834... 20:12 ShadowBot https://github.com/minetest/minetest/issues/13833 -- Cascaded Shadow Maps by x2048 20:12 ShadowBot https://github.com/minetest/minetest/issues/13834 -- Batched rendering of particles by x2048 20:12 erle x2048 are you stopping immediately? 20:14 x2048 yes, I've effectively stopped 6 months ago. 20:22 celeron55 acknowledged. i'll remove x2048 from the github org some time later as a security precaution, if he doesn't do it himself. it was nice having x2048 on the team 20:22 [MTMatrix] Hello. I have question about `minetest.register_on_shutdown(function())`, why not have reason pass to the callback? eg. minetest.register_on_shutdown(function(reason)) 20:22 [MTMatrix] x2048: that's obviously pretty sad to hear and I wish you the best 20:23 [MTMatrix] do you think you can bring those 2 PRs to an end if someone reviews them or it's more of a cold turkey approach? 20:26 rubenwardy sorry to see you go, x2048. If you get time again then feel free to reach out again 20:27 rubenwardy (also do note that there's no minimum requirements for participation, it's fine to go on hiatus as a dev without formally leaving the team) 20:30 MTDiscord I hate to be that guy but wasnt Warr1024 removed from core dev for inactivity 20:36 rubenwardy I think that was more an end to an experiment into including game devs into the core team, he never really did any core dev stuff and didn't intend to 20:37 MTDiscord Aha, fair enough 20:37 rubenwardy but you are also right though - there is actually a precedure for moving core devs that are inactive to an "inactive" team and from the "current" to "previous" in the credits 20:37 rubenwardy so not entirely inaccurate 20:38 rubenwardy -in 20:38 rubenwardy in any case, x2048 would be welcome back - hopefully soon :) 20:42 [MTMatrix] staff changes, right? Well circle of life... 21:00 [MTMatrix] Also, where bot git merging? You disable it? (sorry for too many questions, maybe I'm distracting you too much) 21:37 MTDiscord x2048: Thank you. Good luck in your future endeavours! 22:16 sfan5 @x2048 thank you for your work so far