| Time |
Nick |
Message |
| 00:02 |
|
Sokomine joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:01 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:05 |
|
calcul0n joined #minetest-dev |
| 07:20 |
|
calcul0n_ joined #minetest-dev |
| 07:56 |
[MTMatrix] |
<Zughy> Reminder that today's meeting is at 15:00 UTC (in ~7 hours) and not at 18 UTC |
| 07:58 |
[MTMatrix] |
<Zughy> ..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:08 |
|
calcul0n joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:33 |
|
grorp joined #minetest-dev |
| 08:44 |
|
grorp joined #minetest-dev |
| 08:46 |
|
Warr1024 joined #minetest-dev |
| 08:47 |
|
erle joined #minetest-dev |
| 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 |
| 12:30 |
|
Desour joined #minetest-dev |
| 12:42 |
|
hifi joined #minetest-dev |
| 14:21 |
Krock |
Meeting in 40 minutes |
| 14:40 |
|
Desour joined #minetest-dev |
| 14:50 |
|
srifqi joined #minetest-dev |
| 15:01 |
|
grorp joined #minetest-dev |
| 15:01 |
[MTMatrix] |
<Zughy> 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] |
<Zughy> guy who's been to about a dozen convnetions in the last year: please let's debundle it in 5.8 |
| 15:23 |
[MTMatrix] |
<Zughy> *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 |
|
appguru joined #minetest-dev |
| 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 |
|
srifqi1 joined #minetest-dev |
| 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 |
<rollerozxa> 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 |
|
habeangur joined #minetest-dev |
| 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 |
|
Farooq joined #minetest-dev |
| 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] |
<Zughy> 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 |
<luatic> 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 |
<rollerozxa> the only reason BMP was kept was due to the built-in irrlicht font |
| 16:10 |
MTDiscord |
<rollerozxa> however, this can be easily converted into png |
| 16:11 |
MTDiscord |
<luatic> 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 |
<luatic> erle: I'm aware |
| 16:11 |
MTDiscord |
<rollerozxa> 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 |
<luatic> yeah |
| 16:12 |
erle |
yes |
| 16:12 |
MTDiscord |
<luatic> 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 |
<luatic> deprecate .x as easily* |
| 16:13 |
[MTMatrix] |
<Zughy> lawsuit from Musk incoming |
| 16:13 |
MTDiscord |
<rollerozxa> modlib .x reader when? :^) |
| 16:13 |
MTDiscord |
<rollerozxa> (so we can convert them into b3d) |
| 16:13 |
MTDiscord |
<luatic> 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 |
<luatic> erle: haha, i don't think anyone is generating .x |
| 16:13 |
MTDiscord |
<rollerozxa> .x is a wild format. it has both a binary and text format |
| 16:14 |
MTDiscord |
<rollerozxa> dog squad: hecks once mentioned generating text format x models :^) |
| 16:14 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
|
imi joined #minetest-dev |
| 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] |
<Zughy> 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] |
<Zughy> 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] |
<Zughy> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
| 17:38 |
|
grorp left #minetest-dev |
| 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) |
| 19:41 |
|
x2048 joined #minetest-dev |
| 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] |
<localhost> 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] |
<Zughy> x2048: that's obviously pretty sad to hear and I wish you the best |
| 20:23 |
[MTMatrix] |
<Zughy> 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 |
<greenxenith> 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 |
<greenxenith> 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] |
<localhost> staff changes, right? Well circle of life... |
| 21:00 |
[MTMatrix] |
<localhost> Also, where bot git merging? You disable it? (sorry for too many questions, maybe I'm distracting you too much) |
| 21:02 |
|
Desour joined #minetest-dev |
| 21:28 |
|
appguru joined #minetest-dev |
| 21:37 |
MTDiscord |
<luatic> x2048: Thank you. Good luck in your future endeavours! |
| 22:16 |
sfan5 |
@x2048 thank you for your work so far |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 23:29 |
|
YuGiOhJCJ joined #minetest-dev |
