Minetest logo

IRC log for #minetest-dev, 2022-07-03

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext