Time Nick Message 00:39 rubenwardy sfan5: what should be the behaviour when connecting to a localhost server? #12284 00:39 ShadowBot https://github.com/minetest/minetest/issues/12284 -- [No Squash] Show dep errors in Select Mods modal by rubenwardy 00:39 rubenwardy Oops 00:39 rubenwardy #12185 00:39 ShadowBot https://github.com/minetest/minetest/issues/12185 -- Add login/register dialog to separate register and login by rubenwardy 00:41 rubenwardy Options: 00:41 rubenwardy * hide register button, register from login 00:41 rubenwardy * keep register button, but allow register from login 00:41 rubenwardy * No change 00:52 rubenwardy I'm worried that users will think the button disappearing means you can't register 00:52 rubenwardy But also then it makes the feature undiscoverable 02:24 MTDiscord Client knows who they've registered/visited before, correct? Have the button change to match that fact on a per server basis? 02:25 rubenwardy they don't know for certain - the user may have connected on a different client, they may change their username, or the server may have deleted their account 02:33 MTDiscord Fair, well then no change 02:36 rubenwardy can always go with no change and see if it's annoying 09:22 sfan5 rubenwardy: no idea, I didn't look at that PR at all yet 11:41 sfan5 rubenwardy: localhost should be consistent with any other server, power users can use the setting 11:46 erle which setting? 11:49 sfan5 Zughy[m]: you seem to have puts lots of issues that don't fit in any other category into "@ Startup / Config / Util", I don't think that fits 11:50 erle rubenwardy, i thought a bit about the interface and i wonder: UX-wise, if you only get to know during a login process if you need to register an account, what is the motivation to have a system with an impedance mismatch? 11:51 rubenwardy What does that even mean? 11:51 erle rubenwardy like, the way the process works “on the wire” is currently mirroring the interface. why would anyone, ever, want to introduce something that has transformational overhead? 11:51 erle oh wait, i can explain 11:51 rubenwardy sfan5: yeah I noticed that too, I've been relabelling it 11:51 rubenwardy erle: user experience 11:51 rubenwardy It's much better than the current confirmation dialog, and will match user experience better 11:52 rubenwardy UX expectations* 11:52 rubenwardy It's rare for sites to have login to register, that feels like a 90s chatroom thing 11:53 erle rubenwardy in computing systems, you can encounter situations where some process or some data does not match the interface you are using to access it. this can be a GUI issue or a library API issue. this is called an “impedance mismatch” (borrowed from the electrical engineering term). 11:54 erle rubenwardy you might be familiar with bugs or confusion arising from that if you ever accessed a relational database using an object-relational mapper (ORM). the term is “object-relational impedance mismatch”. 11:54 rubenwardy The protocol does distinguish between login and register 11:54 rubenwardy That's the reason why this is possible 11:55 erle it can happen in UX too, when the UI does not match the process. by far the most common way i have seen this happen is if some system has an established way to do it and then years later someone decides or suspects that users “want” or “expect” it differently. you can pretty easily distinguish the ones who actually care what users think from those who have only a rough idea by asking if they have made user studi 11:55 erle es. the nielsen group for example, does this. 11:56 erle yes, i know how the protocol looks 11:57 erle however, the impedance mismatch here is not between the ”protocol” as in “network protocol”, but as in “protocol” like “the entire sequence of user actions”. 11:57 erle (this is the “turing complete user” POV that olia lialina wrote about) 11:58 erle so in this case, the mismatch occurs not on the network, but exactly where you already spotted it 11:58 erle they don't know for certain - the user may have connected on a different client, they may change their username, or the server may have deleted their account 11:59 erle but i already figured it out, from your other statement 11:59 rubenwardy That's already the case with existing websites 11:59 erle websites? 11:59 erle It's rare for sites to have login to register, that feels like a 90s chatroom thing 11:59 rubenwardy With an existing website, it shows both login and register. It doesn't assume you have an account or not 11:59 rubenwardy I have done user studies, although that was targeted towards a menu redesign 12:00 rubenwardy "how do I create an account on a server" and not having a password are two common complaints as well 12:00 erle that statement – correct me if i am wrong – seems to me as if “UX expectations” you worry about are about *new* users, not about existing users. 12:00 rubenwardy Yes 12:01 erle yeah, that eplains it then 12:01 erle for me 12:01 rubenwardy A big part of user experience is onboarding 12:01 rubenwardy By which I mean making clear what something does without the user doing it 12:01 erle true. it is also very common for old systems to not match whatever is expected by some rando with no experiences. 12:01 erle (no experiences with that specific system) 12:02 freshreplicant[m I suppose for registration, you'd generally worry about new users, rather then old users who are probably registered already, no? 12:03 erle not necessarily. new servers pop up all the time. 12:03 erle so even if you played minetest for years you might register at one today. 12:03 erle accounts are not global (for good measure, lol) 12:04 erle freshreplicant[m the tension here is between making the interface as appealing as possible to newcomers without upsetting existing users (i.e. they think the option went away or so) 12:04 erle at least that is my interpretation of it after reading what rubenwardy wrote 12:05 rubenwardy Exactly that 12:05 erle curiously, a lot of software works just fine without optimizing onboarding. it is often neglected, because devs and power users know all the idiosyncrasies. 12:05 rubenwardy Which is why the login dialog is still on that tab, and there's a setting to remove separate register 12:06 erle in fact, you can see this in minetest mods and games very often. with the exception of crafting – where the inventory may help, a lot of mechanics remain unexplained. 12:07 erle i have been struggling with this realization for a while tbh 12:07 erle like, how would anyone, without reading the documentation, know that you have to punch a tree? it's not a thing you'd accidentally do. 12:08 erle this is, of course, not the fault of the minetest engine. it's a game design thing. 12:08 sfan5 you wouldn't accidentally punch a tree? 12:08 erle and games can overcome it. achievements, for example, hint at what is possible and create a riddle for the player. 12:08 erle sfan5 it does not drop immediately. i think nodecore is a typical example for minetest players how random game mechanics can feel. 12:09 sfan5 true 12:09 sfan5 I do find nodecore confusing and hard to discover how things are supposed to work 12:10 erle same, i gave up playing it. but imagine you had a friend who would tell you! 12:10 erle like some nodecore expert 12:10 erle i think minetest game (and many other things) basically works because everyone who recommends it can also say “punch a tree and also the pickaxe recipe is this and that” 12:11 erle i haven't had a good solution for this, but i'm planning to add a bunch of hints every time someone complains 12:12 erle like, you know, player gets into a minecart and you get a “punch the minecart to accelerate” 12:12 erle i would love to be able to solve it in a more general way, but i doubt that is easily possible within the engine 12:12 erle or rather, every engine feature that would make it possible is kind of spoileriffic 12:13 erle though i think the weapon cooldown should have some visual indicator. hmm, is it an engine feature even? 12:18 erle it seems not https://github.com/minetest/minetest/issues/5823 12:19 erle i think i meant full_punch_interval 12:20 erle is there any way to have an indicator for that? 12:20 MTDiscord Currently? 12:20 erle yes 12:20 MTDiscord Yes. Server-controlled and thus laggy though. 12:21 erle sounds bad, but pls give me a link 12:21 MTDiscord Options include abusing tool wear our registering your own HUD elements. 12:21 MTDiscord or* 12:21 MTDiscord NodeCore's onboarding experience is actually one of the things that most of the design energy goes into. 12:21 erle “you do not do much more damage if you click super fast” is hard to explain 12:21 MTDiscord ah that's another issue, but tool bars can convey this 12:22 MTDiscord also I believe the swinging anim kinda conveys it? 12:22 MTDiscord I'm not 100% satisfied with it, but keeping its target audience just 1 or 2 steps shy of rage quitting is not easy. 12:22 erle Warr1024 it's not that nodecore is bad. it just suffers from not having 10 years of history and being entirely unlike most other games. exile for example, is a lot different than other games, but still similar enough. or repixture. 12:23 MTDiscord Yeah, people complain that it's "not intuitive" but then of course they haven't invested the time in building an intuition for it like they have for other games... 12:23 erle luatic you would think that, right? yet, look at #4714 12:23 ShadowBot https://github.com/minetest/minetest/issues/4714 -- Visual weapon swing time doesn't correspond with full punch interval 12:23 MTDiscord Having game devs able to control the speed of some animations would be nice, yeah. 12:26 erle i just realized that “keeping its target audience just 1 or 2 steps shy of rage quitting” might be the fundamental design principle behind nodecore and now i feel enlightened! 12:30 MTDiscord I sort of ended up optimizing it for hardcore puzzle players who are tired of being spoonfed by other games. 12:30 erle that's legit 12:30 erle i mean, if i want a puzzle on rails i'll go play “inside the box” 12:31 MTDiscord It does also seem to feel like it appeals to other types of gamers too, though some of that may be an accident to some extent. 12:31 rubenwardy I prefer puzzles where the rules aren't so opaque. Games like Portal and Inside the box are good at introducing things gradually 12:32 MTDiscord ITB I found didn't really have much of a creative angle to the solving though. The solutions too often were "in the box" in the original sense. 12:33 MTDiscord Portal has the level of flexibility necessary to allow for creative solutions, but it was too skill-dependent. I wanted a puzzle game that was more purely about solving puzzles and not so much about executing solutions. 12:34 erle rubenwardy i bet you like the original half-life and half-life 2. bothe are great at introducing mechanics gradually. also they have some pretty interesting game design ideas: like aliens in half life making a sound before they teleport in or attack. or you being able to hear the radio of the combine soldiers in half life 2 (they act tactical and you can basically listen to that and deduce who spotted the player). 12:34 erle rubenwardy, am i right? :) 12:34 rubenwardy Yeah I do like those 12:35 MTDiscord Besides, for me to instruct players I would need to know in advance everything about the game, and if it weren't for players discovering things about NodeCore all the time that I hadn't anticipated, I might have just lost interest in developing it long ago. 12:36 erle oh yeah, players discovering random stuff is great. i try to preserve useful glitches because of that. 12:36 MTDiscord I liked the original half-life games too, up until they ran out of new content and then depended on mods, most of which were pretty blah. 12:37 Zughy[m] sfan5: I couldn't fit some issues on any "@ " and I thought to put it in "util", I was kinda desperate 12:37 MTDiscord Trying to make a game that lasts a long time and doesn't suddenly run out of replay value is super hard. 12:39 erle Warr1024 you can definitely sabotage any effort to take the simple way out though. for example, “dungeon crawl: stone soup” has both an “autoexplore” and an “autofight” key, to go to unexplored parts of a level and to punch/shoot the nearest enemy. turns out if you mash both of those, you get reliably nowhere, because the game was made deliberately to avoid players having success with grinding. 12:39 erle given that i mentioned that 12:41 erle rubenwardy sfan5 how much resistance would be there to make digging a toggle-able thing, like going forward? i have read the reviews of repixture and i must say, clicking a lot does indeed put strain on hands. also autodig alone is no cheat (can't even dig a tunnel with it, because the player is 2 high). 12:41 rubenwardy Zughy[m]: you don't have to label everything with @, and that could be a sign that an @ is missing 12:41 rubenwardy erle: that makes sense for accessibility 12:42 rubenwardy most game accessibility guides recommend having alternatives for things that require holding a button or spamming a button 12:42 rubenwardy how would you distinguish between punch and dig? 12:43 erle input-wise, there is no difference. so why does that matter? 12:43 rubenwardy it's useful to be able to dig stuff 12:43 erle spamclicking punches does not give you an advantage because of the punch interval 12:43 rubenwardy *punch 12:43 rubenwardy Punching a mesecons button will flip it, digging will dig it 12:44 erle oh, you mean dig vs use 12:44 rubenwardy so if you make it togglable or autodig, you'd need a key rather than just clicking the button 12:44 rubenwardy use is on the item you're holding, if the item has no use callback it punches what you're focusing on 12:44 rubenwardy as an oversimplification 12:45 erle but i was not saying autouse 12:45 MTDiscord I've actually had some accessibility challenges due to input controls. I needed an extra form of interaction, so developed the "pummel" from repeated punching. I originally designed it to be time-based rather than spam-clicky due to mobile (it's better to develop a slow rhythm) but even that was a lot for some players with repetitive strain injuries. Luckily things like input macros and alternative control devices seemed to help. 12:45 rubenwardy you still need to be able to use though - you can't just toggle with the mouse button. So you'd need a key for it 12:46 MTDiscord I couldn't use punch alone because (1) I wanted it not to be fast, and (2) I wanted it to be possible to dig without triggering the action, and you can't dig without punching first. 12:46 erle there is only one use case i have seen for autouse so far and it is autoeat. and the intervals are far too big for any toggle switch to be of use, except for the case of “falling through the void from the end onto the nether roof”. as the story goes, someone™ managed to do this with chugging a lot of healing potions, surviving 1000 nodes of void damage or so. 12:46 erle the autoeat mod is btw how i spot cheaters. they eat in perfect intervals. ;) 12:47 MTDiscord Theoretically, on desktop you have a lot of "bucky" options, like you can dig, sneak-dig, aux-dig, sneak-aux-dig, and in some cases do wild things like walk left and right at the same time while sneak-aux-digging, so there's already a lot of flexibility to the controls ... it's just not very obvious and some of those are a huge pain. 12:47 erle R.I.P. going left-right while autoforward :/ 12:48 erle (it was useful for boats and mountable animals, holding down forward hurts for me) 12:50 erle rubenwardy i would think that autodig would have a similar “just hold down the button” feeling as autoforward 12:50 erle i.e. have a key to toggle it on and off 12:50 erle then players could have it on and move around 12:50 erle and stop complaining about long digging times 12:52 erle Zughy[m] any interest in confirming this one? https://github.com/minetest/minetest/issues/11749 13:01 MTDiscord "Holding forward hurts for me" is a WASDism ? When mouselook started to become a thing in the early 90's, rather than just defaulting to WASD, I did a little thinking and came up with my own ergonomic key scheme. "Forward" ended up on the spacebar, which is actually pretty easy to hold. One rather curious consequence is that it's trivial for me to hold all 4 directions at the same time... 13:02 rubenwardy Pushing trivial bug fix in 5 minutes: https://github.com/rubenwardy/minetest/commit/9824a451bb8d6f632aa80abc186f440f8d5a745a 13:02 rubenwardy !title 13:02 ShadowBot Fix mods not being recursively enabled · rubenwardy/minetest@9824a45 · GitHub 13:02 rubenwardy So many bugs found just by testing the darned thing 13:05 sfan5 unittests when 13:05 rubenwardy soon :tm: 13:05 rubenwardy I plan it as part of the src/content refactor 13:06 rubenwardy one implementation, unit tested 13:06 erle Warr1024 bold of you to think i use WASD (i use neo2) 13:09 MTDiscord Everyone uses WASD and I don't understand it ? 13:09 MTDiscord What is neo2? 13:13 erle Warr1024 https://en.wikipedia.org/wiki/Neo_(keyboard_layout) 13:13 rubenwardy sfan5: would you be happy for #12253 to be merged as trivial? 13:13 ShadowBot https://github.com/minetest/minetest/issues/12253 -- Fix enabling of dependencies with identical names by TurkeyMcMac 13:13 erle Warr1024 it's a useful layout for german/english, math/science and programming characters. puts less strain on hands too. 13:14 sfan5 merge it if you think it's good 13:14 erle rubenwardy sfan5 does #12253 always prefer the already enabled mod? 13:14 ShadowBot https://github.com/minetest/minetest/issues/12253 -- Fix enabling of dependencies with identical names by TurkeyMcMac 13:14 erle it looks like it 13:42 rubenwardy another trivial one #12202 13:42 ShadowBot https://github.com/minetest/minetest/issues/12202 -- Enable dependencies when enabling modpacks by TurkeyMcMac 13:45 erle rubenwardy wouldn't it make sense to have unit tests for exactly these kinds of changes? 13:45 erle to ensure nothing goes wrong 13:45 rubenwardy <+rubenwardy> I plan it as part of the src/content refactor 13:46 rubenwardy I'm making a list of test cases 13:46 erle well, at least i wouldn't have much faith in that this simple action does not mess up anything without having at least some tests for that. 13:46 rubenwardy I currently have 7 mods folders with different test cases 13:46 erle neat 13:46 erle show? 13:47 erle (i want to confirm the dep issues i found are in there) 13:47 rubenwardy they're all attached in PRs 13:51 rubenwardy I could make integration tests for the pkgmgr code already, those could end up being quite portable. Having to commit the mods into the repo is annoying though. Could make a function to make them temporarily 14:08 rubenwardy Hmm, Minetest does show a chat error for unsatisfied mods already, so maybe we can get away with making it a hard error now 14:08 rubenwardy RE: #12217 14:08 ShadowBot https://github.com/minetest/minetest/issues/12217 -- Prevent loading a world with unresolved dependencies 14:10 rubenwardy #12284 will make it much easier to resolve as well 14:10 ShadowBot https://github.com/minetest/minetest/issues/12284 -- [No Squash] Show dep errors in Select Mods modal by rubenwardy 14:31 erle rubenwardy i think you can not get away with making it a hard error unless the “optional dependencies turned into hard dependencies” bugs are all fixed. are they? 14:32 rubenwardy not a bug 14:32 rubenwardy it's intended behaviour, optional dependencies are only optional at Select Mods time 14:33 rubenwardy so the solution to this is to throw an error, and make users disable those mods if they don't want to use them 14:33 rubenwardy Please read that issue for more context 14:33 rubenwardy and that PR has a screenshot in a comment showing what happens when you have "optional dependencies turned into hard dependencies" 14:57 erle rubenwardy does your mod unit test thing have a test that equals the “can you still break stuff in mineclone2” test? 14:58 rubenwardy that's way too vagu 14:58 rubenwardy do you mean an optional dependency in a game causing a game mod to break? 14:58 erle right 14:58 erle i explain 14:59 rubenwardy that's something I have tested manually for the modconfig PR, added to the list now 14:59 rubenwardy #12295 14:59 ShadowBot https://github.com/minetest/minetest/issues/12295 -- Content/pkgmgr test plan 15:04 rubenwardy here's what happens if a game mod opt-depends on a mod with errors: https://user-images.githubusercontent.com/2122943/167278461-2a79f660-2f70-43d6-8791-3965e281ade5.png 15:04 rubenwardy well, in that screenshot butterflies -> flowers -> uses_notinstalled -XX-> notinstalled 15:06 erle rubenwardy, about the breaking stuff in mineclone2: in the absence of dependency constraints, minetest loads mods reverse alphabetical order. people have been relying on that to be able to load mods as late as possible. the best example is _mcl_autogroup, which wants to be loaded after all tools and nodes are loaded to set dig groups so that the dig times closely match minecraft. 15:06 rubenwardy ah 15:06 erle so, uh, multiple attempts at removing or refactoring this awful hack have resulted in people unable to dig stuff 15:06 rubenwardy well, that's not actually guaranteed by the mod dependency system 15:07 rubenwardy there's an issue for loads first mods 15:07 rubenwardy mcl2 should probably have all its mods depend on _mcl_autogroup 15:07 erle no 15:07 erle you misunderstand 15:07 erle no mod is allowed to depend on _mcl_autogroup 15:07 erle it must load AFTER everything else 15:07 rubenwardy ah 15:08 rubenwardy why not use register_on_mods_loaded? 15:08 erle some reason that escapes me. you are not the first to suggest it. 15:08 erle in fact, there exists mcl_autogroups and _mcl_autogroups, with only the code that can not reasonably be stuffed into the first put into the latter, if i am not mistaken. 15:10 erle even if it is not officially guaranteed, the “in the absence of anything else, load reverse alphabetical” seems to be really simple to do once you have a topological sort of the dpendencies (which i assume you want before loading them) 15:11 MTDiscord _mcl_autogroup needs to be able to change item definitions right? so it would be too late in register_on_mods_loaded, because I remember seeing someone trying to do a similar thing on minetest discord using that callback to edit definitions after all mods have been loaded and failing 15:11 erle and yes, the most common suggestions were register_on_mods_loaded(), minetest.after(0, […]) and “make it depend on everything else”, which all seemed to not work (the last one is most obvious, it will not work with third party mods ever). 15:11 erle oh yeah that could it be 15:11 erle it certainly has not stayed that way for lack of trying 15:12 sfan5 rubenwardy: you can merge #12202 too if you consider it alright 15:12 ShadowBot https://github.com/minetest/minetest/issues/12202 -- Enable dependencies when enabling modpacks by TurkeyMcMac 15:12 erle not sure though, i suggest to ask Elias Åström 15:13 rubenwardy I was testing but then got distracted by more testing 15:13 erle i think that should be made the official slogan of minetest 15:14 MTDiscord I thought the official slogan of minetest was "Build with blocks, then get bored, then spend the rest of your week programming in Lua." 8) 15:14 erle rubenwardy anyways, as long as there is no alternative to handle the “my mod needs to load as late as possible, given the stated dependency graph” case, changing the mod load order in ways that _mcl_autogroups is loaded before any mod that starts with an ASCII letter will make many people very unhappy. 15:15 erle given that it's easy and cheap to have the reverse alphabetic constraint since it does not interfere with anything else, i suggest to simply document it and add it to the unit tests. 15:16 erle (it does not interfere bcause it can always be applied after everything else is calculated, just by sorting the sublists of the dep tree) 15:18 erle and yes, it's a silly constraint for a dependency resolution system. as i have said, this hack is there because nothing else seemed to work. 15:18 rubenwardy It would be nice to know why they can't use on mods loaded 15:27 erle https://git.minetest.land/MineClone2/MineClone2/pulls/1961 15:29 erle https://irc.minetest.net/minetest-dev/2022-01-22#i_5925812 15:29 erle > the reason for the _mcl_autogroups naming hack is that, to work correctly, the code in _mcl_autogroups needs to be run after all other mods have loaded, but before all on_mods_loaded callbacks defined by other mods 15:30 erle rubenwardy that clear enough? 15:30 rubenwardy You can inject to the start of that callback using table.insert 15:31 erle (in the old irc discussion you also see the misunderstanding “make a mod depend on autogroups” vs the reality “autogroups has to depend on every mod inexistence for it to continue to work without the underscore hack”) 15:31 erle inexistence → in existence 15:33 erle rubenwardy do you have an example of that a) working well b) being guaranteed to not also change some time? 15:34 erle well, the code to workaround any sorting order changes is likely orders of magnitude more than a simple sort operation. anyways, i just wanted to make you aware of this so that you can keep it in mind. 15:38 MTDiscord hm, I just tried enclosing the overwrite function call in _mcl_autogroup a register_on_mods_loaded function and it... did not blow up, it still works? or block breaking still worked at least 15:39 erle ROllerozxa now you hae to verify that this also works for all digtimes with all enchantments and if any other mod does something funny on_mods_loaded 15:40 erle in particular enchantments are quite funny. as in, horrible. 15:40 erle for the sake of not relying on awful hacks, i'd welcome a solution here. 15:41 sfan5 you were given suggestions but it seems to me that you expect other people to do all the work for you and deliver a finished package to your doorstep 15:51 erle sfan5 more like “everyone who i have seen actually trying to solve this has failed so far, so i am not likely to believe anyone who comes up with a new suggestion” 15:52 erle i have wasted hours on this myself 15:52 MTDiscord It is indeed a tricky issue: How do you make a mod that does hacky (but necessary) API overrides load before all other mods? 15:53 MTDiscord The only way currently is to use naming hacks (or to use even worse hacks to make all other mods depend on that mod) 15:53 MTDiscord TBF the cleanest solution I can imagine is some mcl_default mod depending on mcl_autogroup and all MCL mods depending on mcl_default. 15:54 erle this just seems like the kind of problem to me where every obvious approach is subtly wrong. i know a bunch of other problems like that, but the most common I know is “how to implement dependency resolution in the context of a build system” (which is similar to, but not the same as mod loading order). 15:55 sfan5 erle: you have both my suggestion(s) from January and what rubenwardy said now, if nobody actually tests these out I have to assume that MCL* devs are not actually interested in a fix 15:58 rubenwardy Would be interesting to shuffle mods before resolving dependencies as a mod Dev tool, would allow finding missing deps 15:59 erle sfan5 i am under the impression that none of your suggestions work for the general case (which includes third-party mods), except for “1) modifying all tools thus far and 2) redefining register_tools for all tools to come”, which I have not tried and i am not aware anyone did. 15:59 erle i can assure you, it's not out of lazyness, it's that any replacement has to be as good as the underscore hack 16:03 erle rubenwardy i strongly support having a shuffle as a debugging option. however, if it is activated, it should probably also output the load order it came up with, to aid debugging. 16:43 sfan5 merging #12288, #12283, #12277 in 10-20mm 16:43 ShadowBot https://github.com/minetest/minetest/issues/12288 -- strict.lua: remove unused variable WARN_INIT by Zughy 16:43 ShadowBot https://github.com/minetest/minetest/issues/12283 -- Fix mapblock geometry optimisation not working by rollerozxa 16:43 ShadowBot https://github.com/minetest/minetest/issues/12277 -- [no squash] Random performance improvements by sfan5 16:43 sfan5 s/mm/m/ 16:46 rubenwardy Nice 16:46 rubenwardy Milliminutes 16:46 rubenwardy 0.06s 16:46 rubenwardy Well, x10-20 16:47 rubenwardy So 0.6s-1.2s. You're late 16:47 MTDiscord Millimetres xD 17:35 sfan5 when's the meeting again 17:35 rubenwardy 7pm UTC? When did the clocks go back, I don't remember it being this late 17:36 rubenwardy 27 march in the UK, a while ago 17:37 rubenwardy Make sure to update the agenda if you have anything 17:37 rubenwardy !dev Meetings 17:38 ShadowBot Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings 17:38 Cosmosis[m] Is this channel the same as the IRC one? 17:40 sfan5 this is #minetest-dev on irc.libera.chat 17:40 Cosmosis[m] Is anyone allowed to participate in the meetings? 17:40 rubenwardy Yes, but you should only discuss the current meeting point 17:41 Cosmosis[m] Ok, will do 17:41 rubenwardy The top of the meetings page has some info 17:44 Cosmosis[m] So the meeting is 4PM EDT? 17:45 sfan5 if that's in 1h15m, then yes 17:45 rubenwardy Haha 17:45 Cosmosis[m] wait, is it 7pm UTC? 17:45 rubenwardy We should use that time is link to handle all these time conversions 17:47 Cosmosis[m] nvm it's 3PM EDT 17:47 Cosmosis[m] time is hard 17:49 rubenwardy https://time.is/1900_8_May_2022_in_UTC?Minetest_core_dev_meeting 17:50 rubenwardy wish it would show the local time more prominently 17:50 Cosmosis[m] neat 17:50 rubenwardy https://www.timeanddate.com/worldclock/fixedtime.html?msg=Minetest+core+dev+meeting&iso=20220508T19&p1=1440&ah=1 18:30 Krock in 30 minutes. that's not timezone dependent. 18:37 rubenwardy for me, it shows the UTC time in medium size, local time in small size, and countdown in large size 18:38 rubenwardy imo it should be small/med/large rather than med/small/large 18:38 rubenwardy I suppose for actual events you may be interested in the time at the event location 18:38 rubenwardy actual -> irl 18:39 sfan5 if someone volunteers to pay for accomodation and travel we can do irl meetings too 18:39 rubenwardy haha 18:40 Krock guys I just found a new purpose for the donation button /s 18:40 rubenwardy Mese Con confirmed 18:53 Pexin "mese con" took me a minute but I got there 19:01 Krock > Minetest core dev meeting - Event in progress 19:03 rubenwardy hello 19:03 HuguesRoss hey 19:03 erle ih 19:03 erle hi 19:03 Krock there's not much in today's meeting 19:03 erle a mese con would obviuosly need to happen in minetest itself 19:03 sfan5 I'll go for a bathroom break bu perhaps yall can think about 5.5.1 in your mind already 19:04 sfan5 +t 19:04 Krock https://github.com/minetest/minetest/commits/backport-5 19:04 erle given that there is already the backport-5 branch (which shows a need) what arguments except “doing a release is work” are there? 19:05 erle also, is that branch suitable as a 5.5.1? 19:06 erle btw, i bet distro packagers appreciate not having to figure out which patches to backport 19:06 Pexin where is the roadmap list for 5.6? 19:06 Krock https://github.com/minetest/minetest/milestones according to this, we're 76% done 19:07 paradust (side note: the discord/irc bridge is broken) 19:07 HuguesRoss From a quick look at that backport branch, I'm not 100% on if #12000 would fit in a X.X.1 or would be better left to 5.6 19:07 ShadowBot https://github.com/minetest/minetest/issues/12000 -- Fix builtin statbar backgrounds by appgurueu 19:08 HuguesRoss That one's a bugfix, but I believe it's a fairly long-standing bug and it's a minor change in behavior 19:08 HuguesRoss I wouldn't go as far as to call it a feature though 19:08 * sfan5 back 19:09 Krock so the question is whether to priorize 5.6.0 or delay for a 5.5.1 release 19:09 sfan5 we can do both 19:09 Krock if it doesn't cause too much work 19:10 HuguesRoss I'd like to avoid any big delays to 5.6 since it has some stuff that was pushed back from 5.5 19:10 HuguesRoss But as long as 5.5.1 doesn't take too long it could be nice to have 19:10 rubenwardy release early, release often is preferable - this applies to patches too though 19:10 Krock I don't think there's another disadvantage from releasing a 5.5.1 version 19:11 Krock so #12000 could be included as well as a less important fix 19:11 ShadowBot https://github.com/minetest/minetest/issues/12000 -- Fix builtin statbar backgrounds by appgurueu 19:11 sfan5 last time my concerns with 5.5.1 were 1) doing a release is work and 2) someone might come around with a new critical bug soon (given that public servers are currently under an involuntary stress test) 19:11 sfan5 this is not to say that I'm against it 19:12 Krock critical bugs can always appear and it's been like that forever 19:12 HuguesRoss Yeah, as long as people are fine with it we can leave it in, it's already in backport-5. I wanted to mention it just so folks were aware of the change, but it's not a big deal either way 19:12 erle IMO “someone might find a new critical bug soon” is no good argument against doing a release that fixes a critical bug (wasn't there something about 5.4 clients being crashed by 5.5 servers?) 19:12 Krock HuguesRoss: it's just that compiling is rather inconvenient 19:13 Krock so a proper release would do them a favour 19:13 sfan5 we can discuss individial commits in the backports branch later, I just whipped that up since someone asked for it 19:13 erle also a proper release would make sure that they are all on the same page 19:13 erle instead of cherry-picking this and that 19:13 HuguesRoss yeah, I meant we can leave it in for the release. May not have worded that well 19:14 Krock erle: patch releases are only cherry-pick based 19:14 Krock what you're talking about is a full release 19:14 Krock s/full/normal/ 19:14 sfan5 ok so in short do I count three people in favor, one neutral for 5.5.1? 19:15 Krock yes, I presume. 19:15 rubenwardy I'm in favour 19:16 Krock Shall I open a list to keep track of the commits to push to backport-5 ? 19:16 erle Krock what i meant is distribution packagers and server maintainers have no need to cherry-pick if there is an official branch 19:16 rubenwardy don't we do that with a pr from backport-5 to stable-5? 19:16 sfan5 I can do that, I already created that branch after all 19:17 Krock rubenwardy: that happened with the 0.4 backport which became stable later on 19:17 Krock currently it looks like backport-5 is a rolling patch release until there's a proper tag 19:17 rubenwardy backport-5 is a dev branch that is merged into stable-5 when a patch release is made 19:18 sfan5 ^ that, yes 19:18 Krock oh, I see. so the commit integrity is not necessary in that case 19:19 Krock i.e. allowed force pushes 19:19 rubenwardy merge commits mean you don't need to force push stable-5 19:19 Krock yes 19:20 sfan5 sounds like that is settled, next point (which I just added): Prioritize things for 5.6? 19:20 sfan5 do we want to do that now? 19:20 sfan5 or maybe: when is the planned release anyway? 19:21 rubenwardy I'd like it sooner than the last one - 11 months 19:21 rubenwardy plenty of time to beat that 19:21 sfan5 July? 19:21 rubenwardy sure 19:21 Krock last release was in january, plus 6 months = July 19:22 Krock seems reasonable 19:22 sfan5 we can always do it earlier if we think all stuff is finished 19:22 rubenwardy for me, the only one I really need in 5.6 is #12217 I would like a few of my other content changes too 19:22 ShadowBot https://github.com/minetest/minetest/issues/12217 -- Prevent loading a world with unresolved dependencies 19:22 Krock updating milestone to first Sunday in July 19:24 Krock tyes, the dependency issues are a long-standing issue and I'm glad you're working on it 19:24 Krock the suggestion is good - deprecate the current behaviour 19:24 sfan5 quickly gathered list: #7629 maybe, #11545 definitely, #10265 probably, #11016 users probably want this, #11465 about time too 19:24 ShadowBot https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker 19:24 ShadowBot https://github.com/minetest/minetest/issues/11545 -- Animated particlespawners by velartrill 19:24 ShadowBot https://github.com/minetest/minetest/issues/10265 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob 19:25 ShadowBot https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by EliasFleckenstein03 19:25 ShadowBot https://github.com/minetest/minetest/issues/11465 -- New physics overrides by Wuzzy2 19:25 sfan5 also #12131 in the "users probably want this" category 19:25 ShadowBot https://github.com/minetest/minetest/issues/12131 -- Add `minetest.settings` to CSM API and allow CSMs to provide `settingtypes.txt` by AFCMS 19:25 sfan5 the issue mentioned by rubenwardy sounds good to me 19:26 sfan5 if I have your opinion on mine then I can add some of them to the milestone too 19:26 rubenwardy all sound good. 19:26 HuguesRoss #10625 is waiting on changes, I've updated the labels accordingly 19:26 ShadowBot https://github.com/minetest/minetest/issues/10625 -- Game minimap textures are ignored by Minetest 19:26 HuguesRoss They're very small though 19:26 HuguesRoss err 19:26 HuguesRoss #10265 19:26 ShadowBot https://github.com/minetest/minetest/issues/10265 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob 19:27 sfan5 sounds likely that we can get to it then 19:27 sfan5 +in time 19:27 erle sfan5 is #11852 in backports-5? given it's a regression from 5.4.1 19:27 HuguesRoss Well, I hope so... it's been sitting in that state for close to a month 19:27 ShadowBot https://github.com/minetest/minetest/issues/11852 -- Parts of slime entity model are not rendered anymore when shaders are turned on (regression from 5.4.1) 19:27 rubenwardy we probably need two categories here - need and want 19:28 sfan5 erle: not now please 19:28 rubenwardy where need is for bug fixes and critical path changes, where missing it will delay development 19:28 rubenwardy well maybe not so strict of a definition 19:28 Krock we could either group them by milestone or tags 19:29 rubenwardy I mean I suppose we could put both in the milestone, and use High Priority / blocker for the need category 19:29 Krock right. that seems reasonable 19:29 sfan5 #7629 probably we need to discuss it again, not sure why it's stalled; but that's for some time later 19:29 ShadowBot https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker 19:29 Krock I just had a look at the update checker, and it seems to be ready for review? 19:29 HuguesRoss #7629 seems like a very good one to get in, while it's not a blocker it'd be good to have update notifications in 19:29 rubenwardy I think that's awaiting review? 19:29 ShadowBot https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker 19:30 rubenwardy oh looks like I was having android issues 19:30 rubenwardy classic 19:31 sfan5 HuguesRoss: do you have any other PRs in mind for 5.6? 19:31 Krock #11545 I believe this is re-inventing the wheel by writing an interpreter which should not be needed in first place 19:31 ShadowBot https://github.com/minetest/minetest/issues/11545 -- Animated particlespawners by velartrill 19:31 Krock hence I wonder whether to add to 5.6.0 19:31 sfan5 you mean CSM could do it? 19:31 HuguesRoss sfan5: None that we haven't discussed 19:32 Krock yes, optimally CSM would execute this in a "sandbox" 19:32 HuguesRoss I'd like to see the formspec events get in, but I wouldn't block a release for it and it'll probably take too long 19:32 Krock to animate the particles from there. that's more generic and allows easy extensions in the future 19:32 sfan5 I agree 19:32 sfan5 but CSM is far away 19:32 sfan5 (unfortunately) 19:32 Krock whereas it completely disregards the PR and is currently not feasible with CSM 19:33 Krock exposing particles should not be too complicated though .. hmm 19:33 erle well, CSM does not have to mean SSCSM though. minetest could have a CSM that has a modchannel (or how it is called) that does it and just come with it builtin. 19:33 erle just like waspsaliva comes with a bunch of CSMs builtin 19:34 Zughy[m] velartrill will probably be pissed off, after all the waiting, if her (?) PR gets delayed 19:34 Krock this does not require entire SSCSM 19:34 erle then use that for particles 19:34 sfan5 Krock: I think it's reasonable to have the feature now rather than later and when CSM is eventually here probably a lot of stuff will be replaced with it 19:35 Krock sfan5: I'd be fine with it, as long the feature is marked as possibly replaced in the future 19:35 erle sfan5 on the other hand, you can never easily get rid of a feature you introduced 19:35 Krock otherwise we'll never be able to replace it fully 19:35 sfan5 well that'd be for 6.0 anyway 19:35 sfan5 wouldn't it? 19:35 Krock right 19:35 erle Krock do you have a particle CSM? 19:35 Krock erle: the functions for that do not yet exist 19:35 HuguesRoss I do also think there's an argument for end-user simplicity sometimes. Having an API to define basic animations in particles will always be less of a hassle than users having to write particles_redo 19:36 HuguesRoss Even if the former exists, it doesn't preclude CSM-based solutions for more advanced users either 19:36 erle Krock in minetest proper, yes. but i remember that for debugging coordinate leaks waspsaliva has at least some particle spawner CSM functions. might not be rendering-related though, i forgot. 19:37 Krock HuguesRoss: it would however cause feature duplication and hence bloated code 19:37 sfan5 I think the argument here is that the functions provided by the PR are already pretty advanced 19:37 erle Zughy[m] if “$person would be pissed if it took longer” was a good argument, a lot more merges would happen haha 19:37 Pexin regarding including a "default" csm in the standard release: this would require enabling csm itself by default, unless multiple csm categories are created ("official" csm vs user-provided) 19:38 erle Pexin what's wrong with enabling it by default, as long as it can only do stuff like show particles etc.? 19:38 erle it would still be restricted 19:38 erle by server flags 19:38 Pexin csm currently is not globally enabled by default I presume for a reason 19:38 Zughy[m] erle: yeah but it's been open almost a year ago and she was very responsive in applying changes, like... c'mon 19:38 Krock Pexin: loading the CSM environment and loading mods within it can be treated separately 19:39 sfan5 I think we're drifting off the topic 19:39 erle but i want the bikeshed color decided in a CSM! 19:40 Krock good, now there's some 5.6.0 goals 19:40 sfan5 next point: https://github.com/minetest/minetest/issues/12251#issuecomment-1115477945 backwards compat hinders refactors, drop compat for old irrmt revisions this time? 19:41 Krock how about the std::vector implementation? isn't the impact reduced now? 19:42 Krock https://github.com/minetest/irrlicht/pull/101 19:42 HuguesRoss Is irrmt packaged separately? Because if not it doesn't seem like a major issue to drop backwards-compat 19:42 sfan5 it is, sort of; this makes development painful when you need to change both in lockstep 19:42 sfan5 Krock: what do you mean? 19:43 sfan5 keeping compatibility with earlier versions is currently a "nice to have" (IMO) feature to simplify development and stuff for users 19:43 erle having talked to debian ppl: irrmt is intended to be packaged by twrightsman within the minetest package 19:44 erle anecdotally speaking, everyone i know already expects them to be updated in lockstep and obv that's never ideal 19:44 erle (for separate components) 19:45 Krock sfan5: does the switch to std::vector (internally only) have an impact on compatibility? if not, is the performance improvement in doing so too negligible ? 19:46 sfan5 there's a small number of incompatible changes required https://github.com/minetest/minetest/pull/12263 19:46 sfan5 I don't know about the performance difference but getting rid of irrlicht's own containers is on the (informal) irrlichtmt roadmap anyway 19:47 sfan5 to make it clear: it's not impossible to #ifdef the stuff so that it stays compatible both ways, just inconvenient 19:47 erle having worked as a software developer, usually having incompat changes at both ends is dealt with by making sure you have proper mocks and unit tests that cover everything imaginable. 19:48 Krock I believe modifying too much of the interface would make backporting work even harder 19:48 Krock so keeping the changes minimal like in the proposed PR seems fine to me, even though it breaks compatibility 19:49 sfan5 so that's a yes for "break compat this time for sake of the (almost) refactor", right? 19:49 HuguesRoss It's a yes on my end 19:50 erle can someone remind me why “make irrlichtmt a git submodule so you always get the right revision” was discarded when proposed? 19:50 Krock yes from my side. It would be even better if there was a good way to detect incompatible versions using macros or whatsoever 19:50 erle after all this lockstep stuff is not that new and the next change will come sooner or later 19:50 erle next incompat change i mean 19:50 sfan5 it's possible to detect it, just a #if IRRLICHT_VERSION_MT_REVISION < 5 #error (blame the user) #endif 19:51 sfan5 s/5/6/ whatever 19:51 sfan5 rubenwardy: opinion? 19:51 Krock so a generic check in a main header would be great to have if that does not already exist 19:51 rubenwardy I'm tied, it'll make things like bisecting annoying 19:51 rubenwardy using a submodule would allow you to pin the irr version better 19:51 rubenwardy but eh 19:52 rubenwardy probably worth getting to a state where irrlicht can be merged sooner than later 19:52 Krock framework changes are a bad situation in general 19:52 sfan5 yes 19:53 sfan5 i'll note down that we're in favor then 19:53 Krock rubenwardy: merged with what? to directly integrate it into the Minetest repo, or as submodule? 19:53 rubenwardy directly into the Minetest repo 19:53 rubenwardy wasn't that the long term goal? 19:53 sfan5 I think so 19:54 HuguesRoss Is there any reason we couldn't do the latter sooner and the former later? 19:55 sfan5 I don't think so 19:55 sfan5 I just don't really want to deal with submodules 19:55 erle a submodule is the easy integration. a subtree would pull the entire irrlicht thing into the main repo via a subtree merge. from my POV you prooooobably don't want a subtree for reasons. 19:56 Krock the irrlichtmt build system is quite different to Minetest's so properly integrating that might take some work 19:56 rubenwardy another option is CMake fetch content 19:56 erle rubenwardy what's that 19:56 sfan5 you let cmake download the repo and build it 19:56 rubenwardy yeah. With caching 19:56 erle distro packagers will hate you for it 19:56 rubenwardy cmake would manage the git clone in lib/ 19:56 erle nothing is allowed to download stuff during a build process 19:57 rubenwardy it can be made so you could also just provide it with the library pre-cloned 19:57 erle or is there a local fallback possible? 19:57 erle ah ok 19:58 rubenwardy This might be just as annoying for dev though, if it updates the irrlicht repo based on version - and isn't backwards compat 19:58 rubenwardy actually, with the current situation you could probably make a bash script which gets the correct irrlicht version 19:58 rubenwardy for dev use whilst bisecting 19:58 erle uh, in what way would that bash script be better than using git submoduleo? 19:58 Krock that sounds like a workaround rather than a proper solution 19:58 rubenwardy it's not, but people don't like submodules 19:59 rubenwardy submodule or merging is the proper solution for keeping stuff in sync 20:01 rubenwardy if Irrlicht was merged into the repo now, it would be 40% of the code. Which is actually less than I expected 20:03 rubenwardy anyway. I think the conclusion is that breaking it is fine, with some concerns over ease-of-use during dev 20:03 erle but those concerns existed before anyway 20:03 rubenwardy yeah 20:03 Krock except that old Irrlicht never changed 20:04 erle you mean they only exist since irrlichtmt and the in-lockstep thing, because irrlicht is a *bit* more careful about breaking compat? 20:05 Krock https://github.com/zaki/irrlicht there was no activity since 2019, so which compat issues could you possibly mean? 20:06 sfan5 irrlicht 1.8 has not changed since ~2013, minus a few bug fix releases 20:06 sfan5 no substantial change = no breaks 20:06 erle oh and i thought it was just some rando on github does not updating their mirror 20:07 sfan5 the mirror is indeed outdated but your point still makes no sense 20:08 rubenwardy https://github.com/minetest/irrlicht/tree/svn-trunk updated upstream mirror 20:08 erle because minetest never used irrlicht trunk but the years old releases? 20:08 rubenwardy will, recently updated 20:08 sfan5 next on the list: "One Approval" PRs and decide on whether to merge, request changes or close. 20:08 sfan5 https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22One+approval%22 link here 20:08 rubenwardy Did I add this point? Is core review really a meeting thing, other than prompting people to do it? 20:09 sfan5 oh it's just a reminder 20:09 sfan5 is there any PR on that list we want to discuss then? 20:10 erle oh, i can say something about the PNG gamma thing here! if gamma correction will never be supported, then minetest should either not load such images or at the very least log a warning so modders are aware of it. 20:10 erle i was under the impression that eventually (e.g. when the rendering is revamped) correct rendering of such textures could be a goal 20:10 rubenwardy is there an issue for gamma correction? 20:11 rubenwardy https://github.com/minetest/minetest/pull/12089#issuecomment-1107927711 20:11 rubenwardy HuguesRoss ^ 20:11 HuguesRoss Yeah probably that 20:11 erle not sure, i just contributed these test nodes because i realized they render wrong. hilariously, gimp gets them even more wrong. 20:12 rubenwardy I'm all for TDD, but adding broken test nodes to devtest for a feature we don't plan to support soon(?) doesn't seem right 20:12 rubenwardy should probably be a .zip in an issue asking for gamma correction 20:12 erle the other alternative is just winging it and accepting that the blending will be wrong and applying the correction on decoding. arguably that's cursed and wrong but it might make the gradient there render correctly? no idea. 20:14 erle anyways if gamma correction is not happening and devs like the “warn on unsupported PNG features” approach, i can start identifying other textures that also render wrong or not at all that need a warning. 20:14 erle (prob just a blacklist of chunks) 20:15 sfan5 I vote for doing nothing 20:16 Krock I don't see the need for any action right now 20:16 rubenwardy wouldn't the action be closing the PR? 20:16 erle yeah, but like, with a comment. 20:16 Krock except that, yes ^ 20:16 HuguesRoss That seems like the next step 20:16 sfan5 well yes: closing and then doing nothing 20:17 erle i think it's a bit weird to have something unsuported and not warn about it, but well, it's not like anyone has complained before me, right? :P 20:17 Krock if textures are not supported, it's an issue for irrlichtmt 20:17 erle sfan5 at least closing with a “gamma is not happening” so future generations know why it was scrapped would be nice 20:17 erle Krock oh i see 20:18 HuguesRoss I think it's a case of: is this edge case actually in use in the wild? If a number of applications outside of MT also don't handle them properly, most likely it's a corner of the spec that no-one actually cares about outside of a couple niche cases 20:18 HuguesRoss I value having easy confirmation of what works and doesn't, but I concur that actually checking or fixing beyond that is not really a good use of dev-time 20:19 Krock I might have a look at the "One approval" PRs upcoming week. Will see. Until next time. 20:19 rubenwardy I've added myself to 2 20:20 erle HuguesRoss yeah, “here is a demo that this thing does not work” was one of my motivations too. i am the type that does TDD but like, leaves failing test cases in for “you might have wondered if this works, it does not”. 20:24 rubenwardy ok next 20:25 sfan5 whats next tho 20:25 rubenwardy roadmap stuff 20:25 rubenwardy well, it's more concept approval for older PRs 20:25 rubenwardy it's probably worth being a bit more lenient than usual 20:25 rubenwardy https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22Roadmap%3A+Needs+approval%22 20:26 rubenwardy eg: #11424 looks useful, but are we keeping support for both GL ES 1 and 2? 20:26 ShadowBot https://github.com/minetest/minetest/issues/11424 -- Allow Selecting Which GLES Version To Link With by TheBrokenRail 20:27 sfan5 in the long run probably not 20:28 sfan5 I think the PR is superseded now because Irrlicht is 20:28 sfan5 ... 20:28 sfan5 actually I think the PR is superseded now because Irrlicht is now responsible for linking to OpenGL libraries 20:28 sfan5 and it already links to the right ones as selected in IrrCompileConfig.h 20:28 sfan5 so this is not even an issue anymore? 20:29 erle how to confirm that? 20:29 sfan5 confirm what 20:29 erle that the submitter can get the right GLES version (1) that way 20:30 erle like, which build command would do it 20:31 sfan5 would do what 20:31 erle link with GLES1 20:32 sfan5 irrlichtmt does that if you select it in IrrCompileConfig.h as I just said 20:32 Zughy[m] as a triager, please let me bring your attention to these "possible close" issues, that have been labelled as such for a long time: https://forum.minetest.net/viewtopic.php?f=7&t=28060 Oldest is from sfan5, 2014. 3 of them have already been closed in these days 20:32 erle ah okay, that's the only option, i see 20:33 erle about #11829 obviously the client should check the input before processing it and error instead of randomly hanging 20:33 ShadowBot https://github.com/minetest/minetest/issues/11829 -- Client hangs on startup if too many texture modifiers are used in a game or mod 20:34 sfan5 Zughy[m]: maybe later, IMO it can be put into the notes for he next meeting 20:34 erle like, just don't try to parse this mess with the shotgun parser if there are too many levels 20:34 sfan5 rubenwardy: which next? 20:34 erle a simple regex or so could replace that hang with a nice uniformly colored “texture missing here” 20:35 rubenwardy #11316 should be an easy concept one 20:35 ShadowBot https://github.com/minetest/minetest/issues/11316 -- make item count background work by Kezii 20:35 sfan5 "should" 20:35 rubenwardy ok borderline controversial 20:36 sfan5 technically making it configurable (from the formspec src) is the right way 20:36 rubenwardy not an accessability setting kind of thing? 20:37 rubenwardy although, the contrast doesn't seem as bad as chat or nametags 20:37 erle how stuff like #11742 can be “unconfirmed” and “possible close” if it is a) easily reproducible b) a server crash … that remains a riddle for me 20:37 ShadowBot https://github.com/minetest/minetest/issues/11742 -- Creating float vector with x outside of -2.14748e+06 < x < 2.14748e+06 crashes server 20:37 HuguesRoss Accessibility setting seems better to me, since formspec solution wouldn't affect the hotbar and would require at least an SSM with a formspec prepend 20:39 sfan5 well I'm fine with either 20:40 sfan5 HuguesRoss: actually, it could be both, like with entity nametags 20:41 HuguesRoss true 20:41 HuguesRoss But in the case of nametags I think that was for gameplay purposes 20:42 sfan5 well doesn't look like a simple decision can fix the PR 20:43 HuguesRoss Personally I don't like the rectangle at all, but I see the value for certain games or users with vision disabilities--it seems to me like the easiest way to get it in is as an accessibility setting, then expose more to modders if anyone actually requests it later 20:43 HuguesRoss My *suspicion* is that people asking for the ability for games to configure it actually just want the option not to have it 20:43 sfan5 probably 20:44 sfan5 resolving the PR that way is fine by me 20:46 sfan5 rubenwardy, Krock? 20:46 rubenwardy <+HuguesRoss> Personally I don't like the rectangle at all, but I see the value for certain games or users with vision disabilities--it seems to me like the easiest way to get it in is as an accessibility setting, then expose more to modders if anyone actually requests it later 20:46 rubenwardy +1 to this 20:46 rubenwardy I'm not sure how useful it is as an accessibility thing though 20:47 rubenwardy has this been requested, or just someone seeing a bug to fix 20:47 rubenwardy I suppose constrast can be low in certain situations 20:49 Zughy[m] As an artist, it's an ugly hack 20:50 Zughy[m] increasing the font size should be nicer to see and also more readable 20:50 Zughy[m] https://github.com/minetest/minetest/pull/11316#issuecomment-855253502 20:51 sfan5 but should these be choices the engine makes? 20:51 rubenwardy that actually makes sense 20:51 HuguesRoss Oh it's 100% an ugly hack. But I also think font size increase won't always give the same clarity as a straight-up bg color will, so we probably still want this 20:52 erle i have a slight contrast vision problem and it is very hard to see such numbers for me, even if larger, with some items. while wool for example. 20:53 Zughy[m] outline? 20:53 erle yes, you can hack it a bit less intrusive by applying a dark outline with a light filling or the other way around. 20:53 erle that way you always have a recognizable glyph 20:54 HuguesRoss For now I've labelled with supported and changes needed. I don't see anyone saying we don't need a way to clarify the text, and this seems like a good starting point to me. If others disagree, feel free to remove them 20:54 HuguesRoss *the labels, not the people 20:55 erle Zughy[m], btw, the super-lazy way to get a text outline is to apply 4 text shadows in different diagonal directions 20:55 Zughy[m] fast mock-up before/after: https://imgur.com/a/pDrUhc8 20:56 rubenwardy I'm getting bored, I suggest not doing all of these PRs now 20:57 Zughy[m] I know the guy who made the PR, he's probably not interested in continuing the work 20:57 Pexin hasnt it been 2 hours? 20:58 HuguesRoss It has been, yes 20:58 sfan5 in my experience meeting effectiveness drops sharply after about one hour 20:58 Zughy[m] ..oh c'mon here it goes again with "let's make X optional" 20:59 sfan5 maybe we can quickly some quick opinions on #10705 20:59 ShadowBot https://github.com/minetest/minetest/issues/10705 -- unset_bone_position by theviper121 20:59 sfan5 since someone just opened an issue requesting this 20:59 rubenwardy makes sense to me 20:59 sfan5 mine: I'm in favor, the PR just needs a bit of work 20:59 rubenwardy not sure I'll review it, but the feature makes sense 21:00 sfan5 s/quickly some quick/quickly get some/ 21:00 rubenwardy sounds supported then 21:00 HuguesRoss > ..oh c'mon here it goes again with "let's make X optional" 21:00 HuguesRoss This is an actual valid use-case for that though, this is exactly what accessibility settings are for 21:00 Pexin release_bone_position ? 21:01 sfan5 okay that sounds like it for the meeting 21:01 HuguesRoss yeah 21:01 sfan5 unless anyone else has something quick 21:02 rubenwardy nothing from me 21:02 sfan5 by the way we should be ready to release 5.5.1 next weekend probably 21:03 rubenwardy makes sense 21:08 Zughy[m] well, this is quick #12152 21:08 ShadowBot https://github.com/minetest/minetest/issues/12152 -- Add doc to list breaking changes for the next major release by Zughy 21:08 rubenwardy Zughy: look at this 21:08 rubenwardy the room: *crickets* *tumbleweed blows past* 21:11 HuguesRoss I think it would be nice to have, since not everyone will browse the release notes 21:12 HuguesRoss I am also too lazy to spend the necessary time to validate that everything is there... but the sooner we add something to this effect the sooner we can ask PRs to update it before merging 21:32 Zughy[m] (put an approval :D) 21:39 sfan5 rubenwardy: topic for next months blog post: MT repo will have passed 10k commits 21:39 rubenwardy good idea 21:39 rubenwardy we need cake 21:42 Pexin cake made of voxels naturally