| Time |
Nick |
Message |
| 00:07 |
sfan5 |
considering issues like 14007 it's no wonder we don't get anything done |
| 00:08 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> (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 |
<warr1024> 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 |
<warr1024> 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 |
|
Sokomine joined #minetest-dev |
| 00:15 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<wsor4035> i see erle is making sfan point beautifully |
| 00:19 |
MTDiscord |
<warr1024> 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 |
<wsor4035> https://irc.minetest.net/minetest-dev/2023-11-18#i_6133341 |
| 00:20 |
MTDiscord |
<wsor4035> you have literally done nothing but complain here about everything brought up |
| 00:20 |
MTDiscord |
<warr1024> 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 |
<wsor4035> 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 |
<warr1024> 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 |
<wsor4035> 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 |
|
ShadowBot joined #minetest-dev |
| 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> Yeah, I guess if we're responsible for mip generation ourselves then there's an intersection there... |
| 00:39 |
MTDiscord |
<warr1024> (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 |
<warr1024> 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 |
<warr1024> 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. |
| 00:57 |
|
ShadowBot joined #minetest-dev |
| 01:25 |
|
ShadowBot joined #minetest-dev |
| 01:55 |
|
ShadowBot joined #minetest-dev |
| 02:37 |
|
ShadowBot joined #minetest-dev |
| 03:49 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:19 |
|
YuGiOhJCJ2 joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:00 |
|
calcul0n joined #minetest-dev |
| 07:10 |
|
calcul0n_ joined #minetest-dev |
| 07:36 |
|
BuckarooBanzai1 joined #minetest-dev |
| 07:37 |
|
SpaceMan1ac joined #minetest-dev |
| 07:37 |
|
Noisytoot joined #minetest-dev |
| 07:37 |
|
panwolfram_ joined #minetest-dev |
| 07:40 |
|
TeXMaster joined #minetest-dev |
| 10:46 |
|
vampirefrog joined #minetest-dev |
| 10:48 |
|
appguru joined #minetest-dev |
| 11:18 |
sfan5 |
can you show an example where downscaling is using nearest instead of bilinear (as before)? |
| 11:30 |
|
YuGiOhJCJ2 joined #minetest-dev |
| 12:04 |
|
YuGiOhJCJ2 joined #minetest-dev |
| 12:06 |
|
fluxionary joined #minetest-dev |
| 13:10 |
|
MTDiscord joined #minetest-dev |
| 14:33 |
|
hifi joined #minetest-dev |
| 16:18 |
|
Desour joined #minetest-dev |
| 17:33 |
|
cx384 joined #minetest-dev |
| 17:56 |
|
Desour joined #minetest-dev |
| 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:26 |
|
Desour joined #minetest-dev |
| 18:50 |
Desour |
cx384: answered in PR |
| 19:03 |
cx384 |
OK, thank you very much. |
| 20:17 |
|
appguru joined #minetest-dev |
| 21:04 |
|
imi joined #minetest-dev |
| 22:49 |
|
imi joined #minetest-dev |
| 22:53 |
|
imi joined #minetest-dev |
| 23:24 |
|
Sokomine joined #minetest-dev |
| 23:35 |
|
panwolfram joined #minetest-dev |
