| Time |
Nick |
Message |
| 01:00 |
erle |
Pexin i think the user should give more details about the graphics setup so we can see if this is a bug in minetest or – like the missing backface culling – in mesa or something |
| 01:08 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:11 |
rubenwardy |
The current number of PRs is the lowest it's been since 2018-04-04 |
| 02:12 |
rubenwardy |
graph: https://rwdy.uk/7fopS.png |
| 02:13 |
rubenwardy |
not sure why it exports the image so small |
| 02:13 |
rubenwardy |
https://rwdy.uk/cf8Bl.png |
| 02:19 |
rubenwardy |
If we close 3 more PRs, that'll be the lowest since 2014-09-14 |
| 02:21 |
|
behalebabo joined #minetest-dev |
| 02:30 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:54 |
rubenwardy |
here's the raw data: https://gist.github.com/rubenwardy/481171a8c0d46fa44334b886bf69bc40 |
| 02:59 |
rubenwardy |
It uses a PR's created_at and closed_at values, so it'll ignore a PR being closed and reopened |
| 03:05 |
Pexin |
now show spikes in number of new contributors |
| 03:05 |
rubenwardy |
ooh good idea |
| 03:05 |
rubenwardy |
new contributors each month |
| 03:06 |
rubenwardy |
or unique contributors each month |
| 03:06 |
rubenwardy |
hmm |
| 03:06 |
Pexin |
I meant new |
| 03:12 |
rubenwardy |
Not especially hyped to try and but them on the same graph in libreoffice, but here https://rwdy.uk/BUoeT.png |
| 03:12 |
rubenwardy |
added data to that gist |
| 03:16 |
Pexin |
that looks less interesting than I expected.. :\ |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:10 |
|
erle joined #minetest-dev |
| 05:14 |
|
calcul0n joined #minetest-dev |
| 06:32 |
|
independent56 joined #minetest-dev |
| 06:34 |
|
independent56 joined #minetest-dev |
| 07:49 |
|
erle joined #minetest-dev |
| 08:05 |
|
independent56 joined #minetest-dev |
| 08:23 |
|
independent56 joined #minetest-dev |
| 08:25 |
|
independent56 joined #minetest-dev |
| 08:33 |
|
erle joined #minetest-dev |
| 08:35 |
|
independent56 joined #minetest-dev |
| 08:47 |
|
independent56 joined #minetest-dev |
| 08:50 |
|
independent56 joined #minetest-dev |
| 08:55 |
|
independent56 joined #minetest-dev |
| 09:03 |
|
Warr1024 joined #minetest-dev |
| 09:23 |
|
Fixer joined #minetest-dev |
| 10:15 |
|
HuguesRoss joined #minetest-dev |
| 11:26 |
|
behalebabo joined #minetest-dev |
| 12:22 |
HuguesRoss |
Merging #12453 in 30 |
| 12:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/12453 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob |
| 12:24 |
Zughy[m] |
If I could, I'd merge #12504 myself, considering how silly it is |
| 12:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/12504 -- Fixed spelling inconsistency by DerZombiiie |
| 12:25 |
HuguesRoss |
Oh, sure that seems fine. I'll merge that too while I'm at it |
| 12:28 |
MTDiscord |
<ROllerozxa> I'm sure there are a lot of other such british/american english differences in the docs. which should prevail, anyways? |
| 12:28 |
HuguesRoss |
Well, in this case like took a quick look lua_api.txt and it looks like colored is used in literally every instance except that one |
| 12:28 |
HuguesRoss |
*I |
| 12:30 |
rubenwardy |
Unfortunately, it was decided to use American English |
| 12:33 |
MTDiscord |
<MNH48> tbf, a lot of software and web in general also uses American English (see how colour in CSS is 'color') so ig using American English will be in harmony with other existing stuff |
| 12:35 |
MTDiscord |
<ROllerozxa> yeah the API itself uses American spelling for things too (i.e. ^[colorize) |
| 12:37 |
MTDiscord |
<MNH48> tfw I usually spelt that as 'colourize' when talking about it ... which is not American but also not British |
| 13:16 |
MTDiscord |
<GoodClover> 'colourize' is Canadian and Oxford British |
| 13:17 |
MTDiscord |
<GoodClover> I think CSS accepts both spellings? Or that might be an nonstandard leeway thing the web likes to do. |
| 13:48 |
|
TheCoffeMaker joined #minetest-dev |
| 14:08 |
sfan5 |
~tell erle https://github.com/minetest/minetest/issues/12035#issuecomment-1027192813 |
| 14:08 |
ShadowBot |
sfan5: OK. |
| 14:15 |
|
erle joined #minetest-dev |
| 14:38 |
rubenwardy |
Reminder that the core dev meeting is today |
| 14:38 |
erle |
thanks sfan5 :) |
| 14:40 |
Pexin |
if that comment will be referenced in the future, might not be a terrible idea to change it to nproc |
| 14:42 |
erle |
sfan5 what would be needed to have this stuff be included in the README or easier accessible in some other way? |
| 14:42 |
Pexin |
(though a better idea is to fix the build process) |
| 15:24 |
|
rtypo_bot joined #minetest-dev |
| 15:24 |
|
rtypo_bot left #minetest-dev |
| 15:50 |
Zughy[m] |
considering MT has reached the estimate date for 5.6 release, wouldn't be best to skip 5.5.2 and just roll 5.6 instead? |
| 15:55 |
kilbith |
https://github.com/minetest/minetest/pull/10100 -> dude have rebased two times already, just saying |
| 15:56 |
Zughy[m] |
you're right, the problem is that, out of 13 core devs, just 4-5 of them are really active |
| 15:57 |
rubenwardy |
who was discussing 5.5.2? |
| 15:57 |
rubenwardy |
like where are you getting that from |
| 15:59 |
Zughy[m] |
past meeting log: https://dev.minetest.net/Meetings#2022-06-05 |
| 16:00 |
rubenwardy |
That was a month ago, things may have changed now |
| 16:01 |
rubenwardy |
Also those notes are rubbish |
| 16:01 |
rubenwardy |
Small meeting I guess |
| 16:02 |
erle |
maybe it would be good to have a dedicated note taker each meeting who does not take part in the discussion. when we do this at work, notes are okay, when not, they are all over the place (some good, some awful, some nonexistent) |
| 16:02 |
erle |
but then at the end of each point the group needs to approve the notes so everything is captured, which adds friction |
| 16:06 |
rubenwardy |
these PRs can be merged if the author approves their own work: #12441 #12486 #12458 |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/12441 -- Add utility script to stress-test mapgen by sfan5 |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/12486 -- Sounds: Various little improvements by SmallJoker |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/12458 -- Add missing item alias metatables to async environment by sfan5 |
| 16:34 |
kilbith |
I need someone (preferably a core-dev) who take this over as I already work on other things: https://github.com/minetest/minetest/pull/11345 |
| 16:43 |
erle |
sfan5 in the stress_mapgen.sh in #12441, you should quote variables. otherwise users with a space in directory names are going to be VERY unhappy when it does the thing with … rm -rf $worldpath |
| 16:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/12441 -- Add utility script to stress-test mapgen by sfan5 |
| 16:44 |
* Pexin |
sees rm -rf with a variable and backs against the wall in terror |
| 16:45 |
erle |
i think steam once managed to use that on deinstallation and there was a code path where it evaluated to rm -rf / |
| 16:45 |
erle |
i'd suggest to not use “rm -rf” at all and use “unlink” with specific known filenames, but i doubt that would cut it here |
| 16:49 |
erle |
Pexin sfan5 there exists a great linter for shell scripts called shellcheck. you can outgrow it (i.e. if you *need* unquoted variables to be split on separators), but it is often entirely right because sh and bash even more are horribly designed languages: https://www.shellcheck.net/ |
| 17:04 |
sfan5 |
rubenwardy: 5.5.2 was discussed last meeting but nobody except else seemed interested and I was busy |
| 17:21 |
|
MTDiscord joined #minetest-dev |
| 17:23 |
sfan5 |
erle: I can do that but it'd be easier if someone fixed it on all existing scripts at once |
| 17:44 |
sfan5 |
when is the meeting again |
| 17:44 |
Krock |
https://github.com/orgs/minetest/teams/engine |
| 17:44 |
Krock |
1900 UTC |
| 17:45 |
Krock |
that's 21:00 for you ;) |
| 17:45 |
HuguesRoss |
kilbith: I'll adopt #11345 if no-one else does first, but I'm still recovering so that will probably wait a few weeks |
| 17:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/11345 -- GUIScrollbar: Add styling by kilbith |
| 17:50 |
rubenwardy |
I'd love that, that PR is on my wishlist |
| 17:50 |
rubenwardy |
for the menu redesign, I'd like a more modern thinner scrollbar without the buttons |
| 17:52 |
Pexin |
disposable I meant. dern vocabulary |
| 17:52 |
Pexin |
doh. wrong chan :( |
| 17:59 |
kilbith |
HuguesRoss: go for it then, recovering is your top priority tho |
| 18:46 |
|
fluxionary joined #minetest-dev |
| 19:01 |
Krock |
===> meeting time :) https://dev.minetest.net/Meetings#2022-07-03 |
| 19:02 |
rubenwardy |
yo |
| 19:02 |
Krock |
presence checking... HuguesRoss sfan5 |
| 19:02 |
sfan5 |
. |
| 19:02 |
HuguesRoss |
here |
| 19:03 |
Krock |
> Feature freeze date for 5.6.0 |
| 19:03 |
Krock |
https://github.com/minetest/minetest/milestone/19 |
| 19:03 |
Krock |
the last blocker is soon to be merged from what I can see |
| 19:04 |
sfan5 |
I guess the milestone'd PRs are exempt anyway so the freeze could start right now |
| 19:04 |
sfan5 |
unless we have some other PRs that we also want in |
| 19:04 |
Pexin |
#11939 pls |
| 19:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin |
| 19:05 |
Krock |
Pexin: noted that one for later |
| 19:05 |
Krock |
(to discuss later on in this meeting) |
| 19:06 |
Krock |
but it's a good point. maybe at the end of this meeting we'll have more of an idea what to includein 5.6.0 |
| 19:06 |
sfan5 |
there are plenty of nice PRs but I wouldn't add any more to 5.6, we're already short on time as is |
| 19:07 |
HuguesRoss |
Looking at our open PRs, I don't see anything else that seems super important to get in. The most interesting things are too early to get in for 5.6 |
| 19:08 |
HuguesRoss |
And of course, there's no reason we can't accept non-features like bugfixes and doc improvements during the early stages of the freeze |
| 19:08 |
MTDiscord |
<FatalError> fuck |
| 19:08 |
MTDiscord |
<FatalError> are we not even going to get the DPI/screen size PR? |
| 19:08 |
Krock |
not in 5.6 |
| 19:08 |
MTDiscord |
<FatalError> sigh |
| 19:08 |
MTDiscord |
<FatalError> ok |
| 19:08 |
HuguesRoss |
I believe that's being discussed in this meeting at any rate |
| 19:08 |
HuguesRoss |
it's in the topic |
| 19:09 |
HuguesRoss |
I would hope to see it in early 5.7 |
| 19:09 |
Krock |
but I agree with sfan that a release is overdue, so pushing towards feature freeze soon seems reasonable |
| 19:09 |
Krock |
if not even from today |
| 19:09 |
HuguesRoss |
Esp. since there are features we removed in 5.5, promising to make a 5.6 soon-ish after |
| 19:10 |
HuguesRoss |
we should keep to that |
| 19:10 |
MTDiscord |
<FatalError> what features were removed in 5.5 anywho |
| 19:10 |
HuguesRoss |
Shadows right? |
| 19:10 |
HuguesRoss |
And there was another, but I can't remember atm |
| 19:10 |
MTDiscord |
<FatalError> weird... |
| 19:10 |
Krock |
rubenwardy: opinions on when to start the feature freeze? now? |
| 19:10 |
erle |
i think shadows were not removed, just disabled for release? |
| 19:11 |
rubenwardy |
sometime this month, maybe 17th |
| 19:11 |
erle |
(IMO this is a case for feature flags) |
| 19:11 |
HuguesRoss |
yeah, but they're effectively not present for users |
| 19:11 |
HuguesRoss |
Oh right, the changes to debug info was the other thing I was thinking of |
| 19:11 |
HuguesRoss |
I got chewed out for that at the time |
| 19:11 |
MTDiscord |
<FatalError> oh right |
| 19:11 |
sfan5 |
rubenwardy: what not now? |
| 19:11 |
erle |
oh yeah, that was fun (as in: dwarf fortress is fun. losing is fun. anarchy servers are fun.) |
| 19:12 |
MTDiscord |
<FatalError> I remember people being pissed about debug options being re-added last minute |
| 19:12 |
Pexin |
wasnt it basic_debug? |
| 19:12 |
HuguesRoss |
yes, exactly |
| 19:12 |
sfan5 |
rubenwardy: why* |
| 19:12 |
rubenwardy |
6 months since the last release is July 30 |
| 19:12 |
sfan5 |
ah |
| 19:12 |
rubenwardy |
plus I have pet features I want in |
| 19:13 |
rubenwardy |
(: |
| 19:13 |
sfan5 |
do you think they'll make it in 2 weeks? |
| 19:13 |
sfan5 |
I don't know which obv but I have doubt |
| 19:13 |
sfan5 |
+s |
| 19:13 |
rubenwardy |
the biggest pet has been ready for review for 2 months |
| 19:13 |
rubenwardy |
and was partially reviewed |
| 19:13 |
erle |
someone promised in the blog that rendering lego bricks will be less of a performance hog in 5.6, has that happened? or did the new culling only affect snow? i think the fact that the studs reach into other nodes makes it a bit more difficult. |
| 19:13 |
rubenwardy |
#12284 |
| 19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/12284 -- [Manual Squash] Show dep errors in Select Mods modal by rubenwardy |
| 19:13 |
sfan5 |
I am pretty sure that's part of the milestone |
| 19:14 |
sfan5 |
anyway |
| 19:14 |
sfan5 |
yep |
| 19:15 |
sfan5 |
so I guess we're starting the freeze on 17th? |
| 19:15 |
erle |
otherwise i suggest to edit https://blog.minetest.net/2022/05/08/April/ so that it does no longer say “But be aware, this may reduce performance - at least until 5.6.0.” |
| 19:15 |
sfan5 |
erle: how does this relate to the current meeting point |
| 19:15 |
erle |
sfan5 oh sorry, i did not realize the meeting had started. i'll be silent. |
| 19:16 |
Krock |
rubenwardy: why's there a distinction of errors by color? I think highlighting the problematic mods with a simple yellow tone would suffice |
| 19:16 |
Krock |
I did yet not have a look at it due to the vast code line changes, but will set it on my todo list |
| 19:17 |
Krock |
* relatively vast, considering it appears as a simple coloring PR (it isn't) |
| 19:18 |
Krock |
two weeks you say? I suppose this will do. |
| 19:18 |
rubenwardy |
it's to show the difference between direct (red) and indirect (orange) errors |
| 19:18 |
rubenwardy |
direct=this mod has an error, indirect=a mod this mod is depending on has an error |
| 19:19 |
Krock |
I see. |
| 19:20 |
erle |
rubenwardy the red-on-green and yellow-on-green text is difficult to read for me in 12284. the reason is probably because the colors are too close in brightness. you can replicate the effect with normal eyesight by desaturating the image in gimp, the text should become almost unreadable. |
| 19:21 |
Krock |
yes, the text color is very persistent. that can be tweaked when necessary. |
| 19:21 |
Krock |
anyway. feature freeze on 17th |
| 19:22 |
Krock |
updated the milestone accordingly |
| 19:22 |
Krock |
next up: 12367 |
| 19:22 |
Krock |
#12367 |
| 19:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/12367 -- Add minetest.get_player_window_information() by rubenwardy |
| 19:23 |
Krock |
rubenwardy: is this about collecting ideas on how to implement? |
| 19:23 |
erle |
rubenwardy additionally, i noticed that the red-on-green in 12284 is definitely borked with the red-green-color-blindfilters in gimp. i do not have that affliction, so i can not possible comment on that. but 8% of men and 0.5% of women have it. |
| 19:24 |
rubenwardy |
erle: which is why there's icons, I was planning to add a different one for indirect but couldn't think of one |
| 19:24 |
rubenwardy |
Krock: there's three questions there. First two are on the implementation, last one is whether this should be added to the prioritise |
| 19:24 |
rubenwardy |
-prioritise +5.6 milestone |
| 19:24 |
sfan5 |
"How to resist fingerprinting?" <- either don't or do some minimal rounding (e.g. divisible by 8), has some other advantages too |
| 19:25 |
sfan5 |
"Move to player ObjectRef?" <- IMO no for consistency with get_player_information |
| 19:25 |
rubenwardy |
1) yeah, it's a problem in browsers because there's a lot more information available and because ads are super common. So probably not a concern? |
| 19:25 |
erle |
rubenwardy if you are interested in this, i can help you later with selecting colors that are visible under many different colorblind or contrast vision problem scenarios. i have done this before for my own software and it does not belong in this meeting. |
| 19:25 |
sfan5 |
"Should this be prioritised for 5.6?" <- would be nice but not going to happen |
| 19:26 |
MTDiscord |
<FatalError> ? |
| 19:26 |
rubenwardy |
2) Yeah I was originally thinking that, but the reason get_player_information exists is because it needs to be accessible when there's not a player obj yet - during prejoin - whereas this is only available after emerge |
| 19:26 |
erle |
how to resist fingerprinting: allow overriding the values to some default? |
| 19:26 |
rubenwardy |
but I'm fine with keeping it consistent, as is |
| 19:26 |
rubenwardy |
3) :'( but fair |
| 19:26 |
Krock |
rubenwardy: how's this information relevant in prejoin? |
| 19:26 |
erle |
rubenwardy is this supposed to be only used for formspecs or some other purpose too? |
| 19:26 |
erle |
yeah what Krock asked |
| 19:27 |
MTDiscord |
<FatalError> HUD |
| 19:27 |
MTDiscord |
<FatalError> but, I don't see why prejoin is needed? |
| 19:27 |
HuguesRoss |
Honestly I think trying to resist fingerprinting might not matter as much in this environment. I'm not opposed to letting the client override values if people feel it's necessary, but I'm not sure how much value it will add |
| 19:27 |
Krock |
oh sorry, I misread. I thought you meant yminetest.get_player_window_information() |
| 19:27 |
rubenwardy |
minetest.get_player_information() returns info in prejoin. minetest.get_player_window_information() will never return info in prejoin |
| 19:29 |
Krock |
fingerprinting is already possible using IP addresses. |
| 19:29 |
Krock |
I don't see a need to round the window size, but could be done to ensure nice numbers to work with on Lua side |
| 19:29 |
erle |
i think the correct way to do this is not have this method, but make formspecs and huds adaptive – once you have it, you are going to be stuck with it. |
| 19:29 |
erle |
think CSS media queries |
| 19:30 |
HuguesRoss |
That's easier said than done |
| 19:30 |
sfan5 |
we have evaluated the "correct" solution and determined it will not happen in 10 years |
| 19:30 |
MTDiscord |
<FatalError> didn't we already try that? offset exists, but it simply sucks |
| 19:30 |
rubenwardy |
That reasoning is why this feature hasn't been added before, and why modders are stuck with crappy formspecs |
| 19:30 |
erle |
anyway, why not send some default value to resist fingerprinting? distributions will probably patch it anyway (like torbrowser) |
| 19:30 |
Krock |
with this data, mods will know whether to show detailed or minimal formspecs. this cannot be done using static expressions |
| 19:30 |
rubenwardy |
Adaptive GUI will require the formspec replacement |
| 19:30 |
MTDiscord |
<FatalError> the only correct solution is to give modders the information they need so that they can do it themselves |
| 19:31 |
MTDiscord |
<FatalError> because the engine will never provide it |
| 19:31 |
erle |
like, make a checkbox for it that sends a value that is broadly correct or so |
| 19:31 |
HuguesRoss |
yeah, stuff like offering a touch-oriented UI instead of a mouse-oriented one for instance |
| 19:31 |
erle |
oh i hate it when that happens based on screen dimensions ;) |
| 19:32 |
HuguesRoss |
sure, but people would probably riot if we provided the actual hardware info to servers |
| 19:32 |
HuguesRoss |
this is a compromise |
| 19:32 |
rubenwardy |
the plan is to add another api that will tell you if there's a touchscreen |
| 19:33 |
Krock |
or the same function, which includes all client visual data |
| 19:33 |
Krock |
client I/O relevant information, so to say. |
| 19:33 |
Krock |
relevant: #12264 |
| 19:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/12264 -- Add API to get user input mechanisms (ie: touchscreen? gamepad? keyboard?) |
| 19:33 |
erle |
i hereby predict a lot of bugs where someone sends 0 as the dimensions and then some stuff gets infinitely large on the server side |
| 19:34 |
erle |
oh yes that |
| 19:34 |
HuguesRoss |
Anyway, adaptive GUI is semi-possible in lua if we have something like this but to do it on the engine side we'd need some massive API changes |
| 19:34 |
erle |
the thing is, what you actually want is probably not “does the user have a touchscreen” but “is the pointing device fine-grained or coarse-grained”. i have had a bunch of devices with a touchscreen and stylus. |
| 19:35 |
erle |
so you'd not send “user has a touchscreen” but ”user has a coarse-grained pointing device” |
| 19:35 |
HuguesRoss |
Or, "will this UI element fit correctly into this window size" |
| 19:35 |
HuguesRoss |
Which is not a given today! |
| 19:35 |
erle |
this difference is important and i'm not going to elaborate as it's a red herring |
| 19:35 |
erle |
indeed HuguesRoss |
| 19:36 |
erle |
so about the fingerprinting: what about the scenario where debian or something inevitably hardcodes some bogus value for this bc privacy? |
| 19:36 |
erle |
(i have no good answer) |
| 19:36 |
sfan5 |
scenario: debian breaks users software on purpose, result: debian users can't play minetest |
| 19:37 |
sfan5 |
? |
| 19:37 |
MTDiscord |
<Jonathon> Does debating break browsers window sizes? I believe not |
| 19:37 |
rubenwardy |
I don't think we need to worry about that yet, given it'll take 5 years for debian to notice the release |
| 19:37 |
HuguesRoss |
In that hypothetical scenario, those users can be sent a UI designed for the "average size" and will have to hope their window isn't unusually large or small |
| 19:37 |
MTDiscord |
<Jonathon> *debian |
| 19:37 |
MTDiscord |
<FatalError> wut |
| 19:38 |
MTDiscord |
<FatalError> HuguesRoss, that doesn't work |
| 19:38 |
erle |
HuguesRoss yeah my suggestion is to just do that right away as an option to have control over whatever ugly hack ppl will add to this ugly hack |
| 19:38 |
erle |
or the sfan5 suggestion, but with a rounding factor more than 8 obv |
| 19:38 |
HuguesRoss |
Sure it work, it's just up to the modder. If you get back a number that makes no sense, you can just pass whatever you think is roughly correct instead |
| 19:38 |
MTDiscord |
<FatalError> scaling isnt an ugly hack |
| 19:39 |
erle |
the ugly hack is that the server mods have to do it, that's all. i understand it is not easy to do otherwise. |
| 19:39 |
sfan5 |
can we move on to the next meeting point |
| 19:39 |
Krock |
exact implementation details can be discussed in the PR |
| 19:39 |
erle |
this is not going anywhere yes |
| 19:39 |
Krock |
#12284 |
| 19:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/12284 -- [Manual Squash] Show dep errors in Select Mods modal by rubenwardy |
| 19:39 |
Krock |
back to this again |
| 19:40 |
rubenwardy |
can move on again now, given that people have requested reviews |
| 19:40 |
Krock |
#12480 |
| 19:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/12480 -- [No Squash] Redesign/unify mainmenu settings interface by rubenwardy |
| 19:41 |
Krock |
concept-wise? hell yes |
| 19:41 |
HuguesRoss |
I like where this is going at a glance, but I have doubts that it'll make it in. We *do* have two more weeks though, so I wouldn't rule it out entirely.... but I think it would be safer to wait a release to give this plenty of time to be battle-tested |
| 19:41 |
HuguesRoss |
And yeah, imo this is a long time coming |
| 19:41 |
erle |
same. also this is probably going to run into some gui scaling bugs with these icons sooner or later? |
| 19:41 |
rubenwardy |
yeah I agree |
| 19:42 |
erle |
or has that been sorted out |
| 19:42 |
sfan5 |
I'm also in the "yes but not in 5.6" camp |
| 19:42 |
erle |
is anyone in the “this needs to be done in the next 2 weeks” camp? |
| 19:42 |
Krock |
good, then that's sorted too. |
| 19:42 |
rubenwardy |
I think it'll take more than 2 weeks to review, let alone the follow up PRs |
| 19:42 |
rubenwardy |
*yet alone? |
| 19:43 |
rubenwardy |
I'm having an existential crisis |
| 19:43 |
HuguesRoss |
*let alone |
| 19:43 |
HuguesRoss |
you were right |
| 19:43 |
Krock |
I think details can be discussed later on since it's generally an accepted solution. |
| 19:43 |
rubenwardy |
requirements for submission => can probably skip this one and leave to PR review |
| 19:43 |
Krock |
#11939 |
| 19:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin |
| 19:44 |
Krock |
moving forward a bit. there's a lot on the list today |
| 19:44 |
HuguesRoss |
What's left? Just review? |
| 19:44 |
Krock |
review, yes. I would like to know whethe or not 5.6 |
| 19:45 |
HuguesRoss |
I'd be fine with that, it already has one approval and has been in progress for 6 months |
| 19:45 |
sfan5 |
PR doesn't look high risk so should be no issue |
| 19:45 |
sfan5 |
but I haven't looked into it much |
| 19:45 |
HuguesRoss |
+ it's marked as bugfix, so |
| 19:45 |
Krock |
the PR only has an effect on bouncy nodes, and trampolines currently suck, hence my motivation for this one- |
| 19:45 |
Krock |
would be great if someone could have a look, so maybe we could get it into 5.6 |
| 19:46 |
Krock |
thanks in advance to the volunteer(s). next up: #12493 |
| 19:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/12493 -- Remove `repeat_place_time` setting, it's plain cheating |
| 19:46 |
Krock |
what to do? sanitize the bounds. |
| 19:47 |
sfan5 |
I added that point, the more precise question is: if the long-term goal is to get rid of the setting, do we want to add clamping for 5.6 already? |
| 19:47 |
sfan5 |
(haven't read recent replies to the issue btw) |
| 19:47 |
Krock |
I'd be fine with short-term removing this setting. it could be re-introduced if anyone feels the need for it |
| 19:48 |
MTDiscord |
<luatic> This should presumably be limited both client- and serverside, otherwise people will use pre-5.6 clients to have an advantage in PvP |
| 19:48 |
erle |
i think the simple way is to have a lower bound server-side |
| 19:48 |
sfan5 |
does this apply to punching? |
| 19:48 |
Pexin |
placing nodes fast is an advantage in pvp? |
| 19:48 |
erle |
i have indeed played on servers where this is abused. |
| 19:49 |
HuguesRoss |
This seems like the sort of setting the server could (should?) have rather than the client |
| 19:49 |
MTDiscord |
<luatic> Pexin: Yes it is. |
| 19:49 |
erle |
Pexin griefers use it to encase people in obsidian jails |
| 19:49 |
Krock |
sfan5: no, only for placing. |
| 19:49 |
MTDiscord |
<luatic> In CTF, people like to build massive pillars at ridiculous speed |
| 19:49 |
HuguesRoss |
Makes sense, punch speed is based on the item iirc |
| 19:49 |
MTDiscord |
<luatic> Or to block large entraces (think 4²) in a fraction of a second |
| 19:50 |
erle |
i think the setting should not getten rid of, it is very useful if it exactly matches the walking speed so you can build stuff walking. but walking speed is different per game. |
| 19:50 |
Krock |
the object hit delays are hardcoded, for example. |
| 19:51 |
HuguesRoss |
erle: I agree, but that's evidence the game/mods should control it rather than a client setting |
| 19:51 |
HuguesRoss |
imo |
| 19:51 |
MTDiscord |
<FatalError> I don't think getting rid of it is a good idea, what if people want to reduce it? maybe just set a cap |
| 19:51 |
Krock |
and the nodig_delay_timer for nodes in capped to max. 0.3s |
| 19:51 |
erle |
on clamity (RIP) and oysterity and some other servers, instabuilding by players was/is encouraged and is part of the server culture. people have CSMs to build specific structures or to assist in building. they still need the resources and no one is going to give them worldedit privs. |
| 19:51 |
erle |
a server-side setting would make it possible to preserve that |
| 19:51 |
MTDiscord |
<FatalError> I agree with what HuguesRoss is saying, but cant the mod just check that they're not placing to fast if they wanted that anyway |
| 19:51 |
erle |
also server-side clamping based upon a setting is BY FAR the easiest way to do it? |
| 19:52 |
Krock |
please not server-side discussions at this point. either clamp that shit or remove it |
| 19:52 |
sfan5 |
in theory the object hit delay and other suchs things should be configurable too |
| 19:52 |
Krock |
I don't see a practical use of changing this somehow by the server. for object punching the default worked just fine |
| 19:53 |
Krock |
what if I include this bounds check in the other setting limit PR? |
| 19:54 |
HuguesRoss |
I see uses, different games may have different expectations of how the player is expected to build. Increasing/decreasing to fit the game makes sense to me, and I could also see it used as a game mechanic--like a piece of equipment or activated ability to speed up certain actions |
| 19:54 |
HuguesRoss |
But for now, bounds-checking is a good start |
| 19:54 |
sfan5 |
then let's go with "clamp for 5.6, server-configurable in 5.7" as the plan? |
| 19:54 |
HuguesRoss |
makes sense to me |
| 19:55 |
HuguesRoss |
Once it's configurable we can simply have the clamp respect that setting |
| 19:55 |
Krock |
it kinda misses the intentions of the other PR. I'll write a patch for this separately soon. |
| 19:55 |
erle |
i guess this will ruin someones day. the CTF cheaty CSMs are the same as the allowed structure-building CSMs. |
| 19:55 |
erle |
i.e. both just place stuff in range very fast |
| 19:56 |
erle |
it is entirely a policy thing, not a mechanism problem |
| 19:56 |
Krock |
#12483 |
| 19:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/12483 -- FOV mouse sensitivity setting by SArpnt |
| 19:56 |
erle |
maybe clamp it when CSMs are not allowed |
| 19:56 |
HuguesRoss |
Well, assuming we do it like this ideally they can just skip an update at worst right? |
| 19:56 |
Krock |
we might discuss that topic in the PR that I'll propose soon, is that okay? |
| 19:56 |
erle |
HuguesRoss generally, what happens instead is that they do not and then randomly patch servers. i have to go though. you can ask me later. |
| 19:56 |
HuguesRoss |
sure |
| 19:56 |
erle |
ok |
| 19:57 |
sfan5 |
erle: CSMs cannot place nodes, you need a modified client anyway, so why can't that client also remove the delay? |
| 19:57 |
HuguesRoss |
Well if the delay is server enforced the client can't. But back on topic, I don't really have any opinions on that FoV change tbh |
| 19:58 |
Krock |
mhm server enforcement will be needed sooner or later for that as well |
| 19:58 |
sfan5 |
12483 -> no complaints, just need a better name |
| 20:00 |
Krock |
suggestion? |
| 20:01 |
sfan5 |
no idea |
| 20:01 |
Krock |
heh okay. we'll see. |
| 20:01 |
Krock |
#12463 |
| 20:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/12463 -- http client fetch by devnexen |
| 20:02 |
Krock |
what's to discuss here? |
| 20:02 |
sfan5 |
unfinished and basically useless, will comment there |
| 20:02 |
Krock |
good, thanks. |
| 20:03 |
rubenwardy |
Yeah, Minetest isn't a cli program |
| 20:03 |
Krock |
even for verbosestream this is too verbose |
| 20:04 |
Krock |
#12353 |
| 20:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/12353 -- Fix acceleration by appgurueu |
| 20:04 |
MTDiscord |
<rubenwardy> @Benrob0329 |
| 20:05 |
HuguesRoss |
I support the intent, though I'm not sure how best to actually implement a change like this into Minetest without causing issues for existing content |
| 20:05 |
MTDiscord |
<luatic> Probably everyone around here agrees that I should revert the changes to old_move |
| 20:05 |
erle |
this will take more than 2 weeks to sort out ig |
| 20:05 |
MTDiscord |
<luatic> erle: what no |
| 20:06 |
erle |
luatic is it possible to change some constant so these graphs overlap https://user-images.githubusercontent.com/1497498/173239738-c5e8cb30-29f0-4a3c-b1dd-004610b8dcbc.png |
| 20:06 |
erle |
? |
| 20:06 |
Krock |
I don't care about old_move, may it be removed with 6.0. |
| 20:06 |
Pexin |
from my superficial lookover, wouldnt reverting old_move produce no gravity? |
| 20:06 |
MTDiscord |
<luatic> erle: no, because one of them is dtime-dependant while the other is not |
| 20:06 |
MTDiscord |
<luatic> Krock, Fleck & I have analyzed this extensively, see the issue, PR & Fleck's PR |
| 20:07 |
Krock |
which PR? |
| 20:07 |
MTDiscord |
<luatic> Pexin: I would readd the wrong code, which applies the speed change before doing the collisions. |
| 20:07 |
MTDiscord |
<luatic> Krock: #11855 |
| 20:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/11855 -- Correct gravity calculation by EliasFleckenstein03 |
| 20:08 |
sfan5 |
to me it seems too quick how 12353 goes over "yeah this won't break existing parkours" but I can also agree with Krock's "technically it's broken since 5.2" comment |
| 20:08 |
sfan5 |
so if enough coredevs agree then by all means merge it |
| 20:08 |
Krock |
it's just about the concept approval for now, but I do think it's not too much of a concern to wait for 6.0 |
| 20:09 |
HuguesRoss |
Well, I certainly approve of the concept |
| 20:09 |
Krock |
* to justify delaying it until 6.0 |
| 20:09 |
MTDiscord |
<luatic> sfan5: for client dtime -> inf everything approaches the ideal values produced by my PR ;) |
| 20:10 |
MTDiscord |
<luatic> This basically fixes the fact that players with lower FPS would fall faster |
| 20:10 |
MTDiscord |
<luatic> Players with decent FPS will hardly notice a difference |
| 20:10 |
MTDiscord |
<luatic> Players with insane FPS will notice no difference |
| 20:10 |
Krock |
the problem is rather the server, not the client. |
| 20:11 |
MTDiscord |
<luatic> Yes |
| 20:11 |
MTDiscord |
<luatic> anyways, gtg; I take it I should return old_move to it's previous state? |
| 20:11 |
MTDiscord |
<luatic> I mean it's called old_move for a reason |
| 20:11 |
MTDiscord |
<luatic> its* |
| 20:12 |
Krock |
actually nvm. the server appears to be untouched |
| 20:13 |
Krock |
only LuaEntitySAO was changed, which is trivial refactoring without an effect |
| 20:13 |
Krock |
nvm, src/collision.cpp is used by both. anyway. concept is approved. |
| 20:13 |
Krock |
#10850 |
| 20:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/10850 -- Allow server to use media from texture_path by yamanq |
| 20:14 |
|
independent56 joined #minetest-dev |
| 20:14 |
sfan5 |
looks undesirable as explained in first comment |
| 20:14 |
Zughy[m] |
(sorry, just finished eating) 12493, my issue -> you're clamping it but I still see no practical usecase for keeping it. Just remove it already, please |
| 20:16 |
sfan5 |
accessibility? |
| 20:17 |
Zughy[m] |
how lowering or increasing the number increases accessibility? I still don't get it |
| 20:17 |
rubenwardy |
Removing settings is good for maintenance |
| 20:18 |
Zughy[m] |
oh wait, are we talking about people who can't move their muscles as fast as the average and that might place too many blocks with one click even if they didn't want to? In that case, you're right |
| 20:19 |
sfan5 |
that would fall under accessibility |
| 20:19 |
Krock |
oh it seems that I misunderstood 10850 |
| 20:20 |
Krock |
they wanted to have a decentralized location for textures, but with the caveat of using the client's selected texture pack for local hosted servers |
| 20:23 |
Krock |
commened. |
| 20:23 |
Krock |
#10587 |
| 20:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/10587 -- Only count entity as "on ground" if they are colliding on the Y axis. by nathanfranke |
| 20:23 |
sfan5 |
breakage potential too high, -1 |
| 20:24 |
Krock |
the "after video" doesn't look as how I'd expect it |
| 20:25 |
Krock |
1m high jumps aren't that easy to pull off when compared to IRL, hence double-jumping is rather strange. stair nodes can still be used for climbing faster.... |
| 20:26 |
Krock |
sfan5: concept rejected; close? |
| 20:26 |
sfan5 |
imo yes |
| 20:26 |
rubenwardy |
As for accessibility, maybe they accidentally place multiple. I'd want to actually get confirmation from people though |
| 20:26 |
Krock |
yes, I'd go for closing too. messing more with collision for such a feature doesn't seem quite right. |
| 20:28 |
Zughy[m] |
can we move the Settings design overhaul PR to 5.6 if a friend and I test it as much as we can? It's 2 weeks before the feature freeze, and 4 before the actual release |
| 20:29 |
Krock |
i.e. to adopt ruben's PR? |
| 20:29 |
Zughy[m] |
yeah. I'd like to see the main menu going somewhere, it'd be great to show people Minetest is moving in a nice UI/UX direction |
| 20:29 |
Zughy[m] |
I've been working with ruben on the PR anyway, design wise |
| 20:30 |
HuguesRoss |
Personally I'm not strictly opposed to getting that and 5.6 if enough eyes are on it. I just don't expect it to happen in that time and I don't think we should force ourselves to that timeline either, so if you want it in then I don't mind you throwing more effort at it |
| 20:30 |
HuguesRoss |
Obviously I'm not the final arbiter of these things ofc, but that's my opinion at least |
| 20:30 |
Krock |
I guess you three could coordinate that, but rushing it doesn't seem to be the wisest strategy for features |
| 20:30 |
HuguesRoss |
*that in |
| 20:31 |
sfan5 |
I don't think rushing it is a good idea either |
| 20:32 |
Krock |
you could work on it for sure, and having it earlier would be nice. but I wouldn't depend 5.6 on it, but rather give it time for testing in 5.7.0-dev |
| 20:32 |
HuguesRoss |
One thing we could do to show the direction--it could be showcased on the blog once its merged, even if it doesn't go 'live' until 5.7 |
| 20:32 |
HuguesRoss |
That would lend it some visibility long before the release |
| 20:33 |
Krock |
third last point: #9424 |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/9424 -- Implement the 'userdata' commandline option by vilhelmgray |
| 20:34 |
sfan5 |
uhh dunno |
| 20:35 |
erle |
maybe they accidentally place multiple → me |
| 20:36 |
HuguesRoss |
I feel like if a user has enough technical know how to be using an alternate shell that doesn't support overriding environment variables they can probably find a way to launch with a custom environment anyway... I'd be more supportive of an environment-based solution personally, but maybe I'm projecting |
| 20:36 |
Krock |
for example, Wine uses environment variables for their prefix too, hence I wonder why it has to be a command line option for Minetest |
| 20:36 |
sfan5 |
overriding HOME definitely isn't ideal but an env variables might make more sense yes |
| 20:36 |
Krock |
yes, HOME was a stupid idea from my side |
| 20:37 |
HuguesRoss |
Yeah it doesn't have to be HOME, but I do feel like environment is a good way to handle it |
| 20:38 |
sfan5 |
next: #7728 |
| 20:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/7728 -- Add keep_newlines argument to wrap_text by theFox6 |
| 20:38 |
sfan5 |
+1 for concept from my side |
| 20:38 |
rubenwardy |
Yeah makes sense |
| 20:38 |
HuguesRoss |
+1 as well |
| 20:39 |
Krock |
in my last tests this was still flawed, thus changes might still be required |
| 20:39 |
|
independent56 joined #minetest-dev |
| 20:39 |
Krock |
but concept-wise okay. might need adoption at this point |
| 20:41 |
sfan5 |
next: #7712 |
| 20:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/7712 -- Add an item pick up callback (2) by Desour |
| 20:41 |
sfan5 |
personally I don't know and don't care to read through it right now |
| 20:41 |
HuguesRoss |
I'm concerned that some of the listed use-cases will not actually function if I understand what this feature does correctly... |
| 20:42 |
Krock |
it's basically useful to exactly one type of entity |
| 20:42 |
Krock |
dropped items. |
| 20:42 |
HuguesRoss |
Because it does not apply to taking an item out of an inventory like, say, a chest. I'm not opposed to the concept since I literally implemented it in my own game... but I'm not sure if it needs to be at engine-level or not |
| 20:42 |
Zughy[m] |
as a modder, that would be very useful |
| 20:42 |
HuguesRoss |
Player inventory callbacks might be better |
| 20:44 |
sfan5 |
well since the engine provides the item entity it should also provide this |
| 20:44 |
HuguesRoss |
Anyway, I guess I'll leave this as "not opposed on my end" |
| 20:44 |
HuguesRoss |
But I don't think it will enable everything the author expects |
| 20:47 |
Krock |
well idk. could be useful... |
| 20:48 |
HuguesRoss |
I can confirm that the feature is useful, at any rate |
| 20:50 |
Krock |
updated the wiki |
| 20:50 |
|
proller joined #minetest-dev |
| 20:50 |
Krock |
thanks for coming. I'll take my leave now. |
| 20:50 |
HuguesRoss |
seeya |
| 21:06 |
erle |
, |
| 21:10 |
MTDiscord |
<luatic> ; |
| 21:55 |
|
independent56 joined #minetest-dev |
| 21:59 |
|
independent56 joined #minetest-dev |
| 22:16 |
|
independent56 joined #minetest-dev |
| 22:18 |
|
erle joined #minetest-dev |
| 22:23 |
|
erle joined #minetest-dev |
| 22:24 |
|
independent56 joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:56 |
Zughy[m] |
can this user be banned? It's the third time they spam their stream of consciousness, flooding my mail with useless notifications. They were also banned from CDB and - I think - the forum https://github.com/minetest/minetest/issues/6733#issuecomment-1173185597 |
| 22:59 |
rubenwardy |
just banned them for 3 days |
| 23:01 |
sfan5 |
merging #12458, #12441 in 5m |
| 23:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/12458 -- Add missing item alias metatables to async environment by sfan5 |
| 23:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/12441 -- Add utility script to stress-test mapgen by sfan5 |
| 23:01 |
Zughy[m] |
thahnks |
| 23:01 |
Zughy[m] |
*thanks |
| 23:08 |
Zughy[m] |
80 PRs, and it's 2014 all over again. Gg :) |
| 23:25 |
kilbith |
not quite |
| 23:25 |
kilbith |
in 2014 there were still some alpha males like hmmmm around here |
| 23:27 |
schwarzwald[m] |
What's the matter with having lots of PRs open? |
| 23:27 |
|
independent56 joined #minetest-dev |
| 23:30 |
Zughy[m] |
chaos development and people feeling down because of all the things to do |
| 23:30 |
Zughy[m] |
also, contributors not being considered for years |
| 23:31 |
schwarzwald[m] |
People have real life things to do. I think the core devs should consider their priorities and move at the pace they feel comfortable with. |
| 23:34 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:35 |
Zughy[m] |
Yeah, half of the core devs are definitely following that suggestion, having 4/5 core devs doing all the work in the meanwhile |
| 23:45 |
schwarzwald[m] |
In my role as an end user I haven't noticed a whole lot of the development going on. The things I have noticed are security vulnerability reports, shadows, and ContentDB. ContentDB is huge. That makes me question whether the devs are contributing the things they want or the things the playerbase wants. Of course, I may only speak for myself here, but that's what I notice as a player. |
| 23:45 |
schwarzwald[m] |
The main menu changes being discussed are also something that, as a player, I'm quite hyped for. |
| 23:46 |
Zughy[m] |
the main menu issue is from 2017 |
| 23:49 |
schwarzwald[m] |
Right, I'm curious what all was done that was more important than revamping the main menu. Not that there weren't a lot more important things done, but prioritizing things is definitely an issue. This is why I closed my PR for changes the database options. Even though it was a request, the value to the community as a whole is considerably lower I think than other things. After all, nobody has complained that I closed it. |
| 23:55 |
Zughy[m] |
I wasn't here in 2017, but if I had to take a guess, there were no common vision. When I joined in 2019, there were basically an old core dev copy-pasting everything Celeron said and blocking a lot of potential new features |
| 23:55 |
Zughy[m] |
*there was |
| 23:55 |
schwarzwald[m] |
Looking back, the dungeon master being removed from the default game was a major change almost on the level of ContentDB for me. Not sure who even remembers that now, but that change was great. |
| 23:56 |
MTDiscord |
<GreenXenith> speaking of main menu redesign |
| 23:57 |
MTDiscord |
<GreenXenith> im playing with utilities for making writing forms easier on that (and probably overengineering it already) |
| 23:57 |
schwarzwald[m] |
Similar to the luk3yx's formspec designer? |
| 23:57 |
MTDiscord |
<GreenXenith> Yeah not really |
| 23:58 |
MTDiscord |
<GreenXenith> would this make it past review: E"label"{1,2}{"foo bar"}() |
| 23:58 |
schwarzwald[m] |
Not without documentation. |
| 23:58 |
MTDiscord |
<GreenXenith> Of course (internal doc) |
| 23:59 |
MTDiscord |
<GreenXenith> But it is quite a weird syntax to work with |
| 23:59 |
MTDiscord |
<GreenXenith> My main goal is to make using variables with forms easier |
| 23:59 |
MTDiscord |
<GreenXenith> But when all im doing is redesigning the main menu, I probably shouldnt go that far |
