Time Nick Message 00:07 sfan5 considering issues like 14007 it's no wonder we don't get anything done 00:08 MTDiscord We do get a lot done, it's just that much of what we get done is undoing what we previously got done (including undoing our past undoing of our past undoing) 00:09 sfan5 evidently our userbase likes nothing getting done 00:09 sfan5 because then nothing ever changes 00:09 sfan5 and that makes them happy 00:11 MTDiscord I can't speak for everyone, but adding APIs would probably get a lot less complaining from me than, say, removing settings that I was using. 00:11 erle what Warr1024 says lol 00:11 erle not all change is progress 00:11 MTDiscord (though I know that there are people who WILL complain about adding APIs of course) 00:11 erle some of it is rearranging deck chairs on the titanic 00:13 MTDiscord The idea of simplifying settings is actually generally a good thing ... it's just that it runs into trouble in a FOSS project where you have a large portion of the audience who is used to having "power user" low-level control over everything. But this is why we have "advanced" settings we can bury stuff in, to still present simpler options to "ordinary" users. 00:13 erle well these settings were actually exposed very prominently 00:13 erle until the new settings dialog buried them 00:13 erle so it's no surprise that ppl used them 00:13 erle (and actually knew what they did and cared) 00:14 MTDiscord Eh, I don't even really care about that even. I'm willing to be very flexible on the UX as long as I have the option to at least attempt to tune my rendering (insofar as my video hardware will even let me) via minetest.conf settings. 00:15 MTDiscord I don't assume that there's any intersection between people who had very specific rendering settings they really needed to have, and people who are unwilling to go digging around in Advanced Settings to find that stuff. 00:16 erle i just dislike the kind of interface that uses “advanced” and similar “we had no idea how to better categorize this” (like burger buttons or overflow menus) but … i have no better idea right now and surely it can be improved incrementally, so that's not a big deal overall. 00:17 erle the only way it can go wrong really IMO is the GNOME way, where settings are removed, like future software can do less 00:17 erle that's how you piss off users 00:18 MTDiscord The idea of burying it inside "advanced" actually makes sense from a "rip the bandaid off now" kind of perspective. If it does eventually make sense to reduce the non-at-your-own-risk supported rendering options for MT for future maintainability, it might go easier if we just bury everything now and then gradually restore flexibility once we determine it's worth really supporting certain options. Then you only have users pissed off 00:18 MTDiscord once, instead of continuously every release (at least as far as this feature goes). 00:19 MTDiscord i see erle is making sfan point beautifully 00:19 MTDiscord I mean, I sympathize with sfan5, and would really live to take their side on this, but dammit, I was one of those people who was using that feature 😅 00:19 erle wsor4035 which point though? 00:20 MTDiscord https://irc.minetest.net/minetest-dev/2023-11-18#i_6133341 00:20 MTDiscord you have literally done nothing but complain here about everything brought up 00:20 MTDiscord erle, you do have a tendency to be a "nothing may change until we consider ALL the consequences" extremist. I don't "blame" anyone for this change, and I think it was laudable that they chose to experiment boldly. I think they should just walk it back, but NOT necessarily completely. 00:21 erle wsor4035 i have provided a patch and tested it extensively 00:21 MTDiscord you completely missed the point 00:21 erle and also i am in favor of overhauling those settings 00:21 erle just maybe this time, do some rendering tests or so 00:21 MTDiscord wsor, to be fair, I think I might be missing your point too ... maybe it would help just to be explicit about it. 00:23 erle Warr1024 i don't want to actuall blame anyone, but yeah, there are both some kinds of bugs i never make and some kinds of progress i never make because of my cautious approach. 00:23 MTDiscord erle is complaining about everything, nothing is good enough for them. an extremist as you say. which fits right in with essentially nothing getting done 00:24 erle that's a bit rich, given my loudest complaints about new APIs are that they are not going far *enough* lol 00:25 erle yes, i think in many cases software can be improved without breaking anything if ppl just don't do the first thing that makes sense 00:25 erle stuff like HTML or email or whatever is based on that 00:25 erle i also think experimentation is healthy 00:26 erle but i think ”let's delete everything we don't use and everything that our users use but we don't use” is a medium-term loser strategy in terms of making software useful. 00:26 erle imagine you'd do this to word or excel. whatever feature you choose, if it is niche, maybe only a few percent of users use it. so you *always* have a justification to remove it. 00:27 erle it's only that for each of these features you lose goodwill with a different amount of users 00:27 erle and most of them never explicitly complain (until it gets too much) 00:27 erle like 1% do, at most 00:28 erle i meant different group, not different amount 00:28 erle you can see this with absolutely bizarre decisions like deprecating the schur product – IIRC this was *not* because “multiply” was overloaded but because no one in the dev team used it? 00:29 MTDiscord I think y'all're all overreacting ... I think this change is still salvageable with very minor walk-back. Just sneak in a few "advanced" settings and this is reduced from an "oh no you took a thing away" thing to just an "it's a little inconvenient now but at least I still have options", which is frankly the standard we live with for many things anyway. 00:30 erle (i think overloading “multiply” was a mistake, but having a vector library without a schur product is also one) 00:30 erle warr1024 i literally want to just revert this so it can be dissected after the 5.8.0 release 00:30 erle and i don't see any other option than reverting it, because it was already discussed and broke stuff 00:30 erle so anything more complex before release would be foolish from my POV 00:31 MTDiscord I dunno, I kinda see sfan5's point though, in that if we revert it for 5.8 and "hope" to "do it right" by 5.9, all we're doing is giving ourselves license for more bikeshedding. It should be reasonable to still keep some portion of this so that definite progress is still being made. 00:31 erle i don't see how you *can* actually partially fix it 00:31 erle from my POV the correct solution looks entirely different 00:32 MTDiscord I suppose a revert might be more realistic given the time pressure; this seems unlikely to be the only thing that gets discovered late. 00:33 MTDiscord I don't necessarily WANT a correct solution, though, I just want a series of solutions each incrementally better than the last. Trying to jump ahead in that is the kind of thing that leads to changes we have to revert when we actually get real feedback on them in the first place. 00:33 erle i think the incremental solution here would actually be easy 00:34 erle but it would be something new and could result in more bugs, so … 00:35 erle like [ ] upscale to texture_min_size before filtering [ ] filter for upscaling [ ] filter for downscaling (but the thing is, that is only one option and not necessarily the one that is best) 00:35 MTDiscord I guess that's fair. Would like to see somebody have a PR for it as soon as 5.9-dev is unfrozen, at least. 00:35 MTDiscord I guess it might actually be within my own skillset, at least to do the "advanced settings" thing, I'd just need core dev supprot. 00:35 erle and i think the idea to “fix” it by changing the description of anisotropic setting is absolutely noncredible lol 00:36 erle i actually would like to have more upscaling options that are less fugly, like other pixel games have, for example hq2x 00:36 MTDiscord The "smart" thing to do here seems to be to let people customize their rendering settings entirely, then use this to go find people in the community and have them submit feedback about their observations of the effects of various settings. Then we can find out what these things actually mean now and how that varies across setups... 00:37 erle yeah and read the actual notes for the standards 00:37 MTDiscord there are at least a couple of generations of upscaling filters newer than hqx, some of them quite nice for more complex cases, like xBR and such. I'd like to see those too ... but they're sort of out of scope from just the flags you pass to GL filtering. 00:38 MTDiscord I mean, if you want hqx textures, you CAN just do those yourself with a script and a TP; I've played with it myself (got mixed results due to some corner cases) 00:38 erle obviously, but the mipmap thing from hybriddog shows there is a lot to gain 00:38 erle haha, hq2x and corner cases, i bet it was *literal* corner cases ;) 00:38 MTDiscord Yeah, I guess if we're responsible for mip generation ourselves then there's an intersection there... 00:39 MTDiscord (IIRC my issues with hqx was that it was born in a world where alpha channels weren't part of the problem space) 00:39 erle i see 00:39 erle makes sense actually 00:40 erle tbh i must say i am a bit weirded out by the fact that apparently these filter settings are used by users (as evidenced from screenshots) but none of the devs even noticed the removal apparently. 00:40 erle maybe it would help to actually post the settings the devs use to game 00:40 erle to figure out what is next on the chopping block hehe 00:42 MTDiscord I would like to know what kind of settings are used by people who have decision making power here, yeah, but the actual amount of influence people have is probably hard to quantify. Tbh there are probably a lot of people who wouldn't have even noticed; I probably wouldn't have noticed during most gameplay, it's only in screenshots where the loss of downscale filtering really stands out. 00:42 erle IIRC ppl asserted that downscale filtering still worked though, this is about upscale filtering 00:42 erle not sure though 00:44 MTDiscord That assertion has no power to actually control reality though. If the downscaling were NOT affected then I wouldn't have chimed in to complain about the change. 11:18 sfan5 can you show an example where downscaling is using nearest instead of bilinear (as before)? 17:59 cx384 Hello, a view days ago I made a PR #13992 and was told that I shouldn't use armor_groups for this feature, so before I change the it again I would like to know how the API should look like. 17:59 ShadowBot https://github.com/minetest/minetest/issues/13992 -- Tool specific pointing and blocking pointable type by cx384 18:06 cx384 Is it acceptable what I wrote with different tables for objects and nodes? It would be nice if I could get some confirmation such that I don't have to change it again later. 18:09 cx384 *few 18:50 Desour cx384: answered in PR 19:03 cx384 OK, thank you very much.