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 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: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.. :\ 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 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 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 yeah the API itself uses American spelling for things too (i.e. ^[colorize) 12:37 MTDiscord tfw I usually spelt that as 'colourize' when talking about it ... which is not American but also not British 13:16 MTDiscord 'colourize' is Canadian and Oxford British 13:17 MTDiscord I think CSS accepts both spellings? Or that might be an nonstandard leeway thing the web likes to do. 14:08 sfan5 ~tell erle https://github.com/minetest/minetest/issues/12035#issuecomment-1027192813 14:08 ShadowBot sfan5: OK. 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: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: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 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 fuck 19:08 MTDiscord are we not even going to get the DPI/screen size PR? 19:08 Krock not in 5.6 19:08 MTDiscord sigh 19:08 MTDiscord 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 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 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 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 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 ? 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 HUD 19:27 MTDiscord 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 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 the only correct solution is to give modders the information they need so that they can do it themselves 19:31 MTDiscord 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 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 *debian 19:37 MTDiscord wut 19:38 MTDiscord 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 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 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 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 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 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 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 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 @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 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 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 erle: no, because one of them is dtime-dependant while the other is not 20:06 MTDiscord Krock, Fleck & I have analyzed this extensively, see the issue, PR & Fleck's PR 20:07 Krock which PR? 20:07 MTDiscord Pexin: I would readd the wrong code, which applies the speed change before doing the collisions. 20:07 MTDiscord 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 sfan5: for client dtime -> inf everything approaches the ideal values produced by my PR ;) 20:10 MTDiscord This basically fixes the fact that players with lower FPS would fall faster 20:10 MTDiscord Players with decent FPS will hardly notice a difference 20:10 MTDiscord Players with insane FPS will notice no difference 20:10 Krock the problem is rather the server, not the client. 20:11 MTDiscord Yes 20:11 MTDiscord anyways, gtg; I take it I should return old_move to it's previous state? 20:11 MTDiscord I mean it's called old_move for a reason 20:11 MTDiscord 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 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 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 Krock thanks for coming. I'll take my leave now. 20:50 HuguesRoss seeya 21:06 erle , 21:10 MTDiscord ; 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: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: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 speaking of main menu redesign 23:57 MTDiscord 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 Yeah not really 23:58 MTDiscord would this make it past review: E"label"{1,2}{"foo bar"}() 23:58 schwarzwald[m] Not without documentation. 23:58 MTDiscord Of course (internal doc) 23:59 MTDiscord But it is quite a weird syntax to work with 23:59 MTDiscord My main goal is to make using variables with forms easier 23:59 MTDiscord But when all im doing is redesigning the main menu, I probably shouldnt go that far