Time |
Nick |
Message |
01:26 |
|
YuGiOhJCJ joined #minetest-dev |
01:55 |
|
m42uko_ joined #minetest-dev |
03:25 |
MTDiscord |
<thresher09> please see the latest comment on #14287, as i would like to hear more about reviewing it and if it may be merged in the future. |
03:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/14287 -- Refactor markdown files by Bituvo |
04:00 |
|
MTDiscord joined #minetest-dev |
05:50 |
|
cranez joined #minetest-dev |
06:04 |
|
MTDiscord joined #minetest-dev |
06:09 |
|
sugarbeet joined #minetest-dev |
08:02 |
|
[MTMatrix]_ joined #minetest-dev |
08:23 |
|
fluxionary joined #minetest-dev |
08:34 |
|
[MTMatrix]_ joined #minetest-dev |
08:34 |
|
MTDiscord joined #minetest-dev |
08:34 |
|
pmp-p joined #minetest-dev |
13:19 |
|
SFENCE joined #minetest-dev |
13:23 |
|
SFENCE joined #minetest-dev |
13:33 |
|
SFENCE joined #minetest-dev |
13:42 |
|
SFENCE joined #minetest-dev |
14:13 |
|
SFENCE joined #minetest-dev |
14:34 |
|
SFENCE joined #minetest-dev |
14:52 |
|
SFENCE joined #minetest-dev |
14:56 |
|
SFENCE joined #minetest-dev |
14:58 |
|
SFENCE joined #minetest-dev |
15:09 |
|
SFENCE joined #minetest-dev |
15:12 |
|
SFENCE joined #minetest-dev |
15:18 |
|
Desour joined #minetest-dev |
15:32 |
|
SFENCE joined #minetest-dev |
15:34 |
|
SFENCE joined #minetest-dev |
15:38 |
|
SFENCE joined #minetest-dev |
15:47 |
|
SFENCE joined #minetest-dev |
15:52 |
|
SFENCE joined #minetest-dev |
15:59 |
|
SpaceManiac joined #minetest-dev |
16:39 |
|
SpaceManiac joined #minetest-dev |
18:04 |
|
fluxionary joined #minetest-dev |
18:48 |
celeron55 |
again, with 5.9.0, someone is complaining about not being able to turn on new effects on old servers |
18:52 |
celeron55 |
i have no idea of an issue about this exists, but i think there needs to be a way for games to define their "base effect set" somehow, in a way where most mod soup games and servers would pick the "fancy" preset and the client would then be able to turn new effects on without the server or game having any idea about them |
18:52 |
MTDiscord |
<luatic> the use_texture_alpha breakage created bigger issues with old servers |
18:54 |
celeron55 |
i'm not saying this is the biggest issue, most definitely not. but players consistently complain about this with every release that has new effects |
18:59 |
MTDiscord |
<warr1024> Allow them to opt in to opting out of effects |
18:59 |
MTDiscord |
<warr1024> so right now effects are a pure per-effect opt-in |
18:59 |
MTDiscord |
<warr1024> but allow them to change the default and then opt out of the ones they don't want |
19:00 |
MTDiscord |
<warr1024> or you could have some kind of list of all effects, and games could then just automatically opt in to them by looking in that list and skipping only the ones they know they don't wnat. |
19:00 |
celeron55 |
my proposal is to have presets that a game can pick, which the client will expand to cover effects the game doesn't even know about, and then provide apis like now for the game to control effects one-by-one which will override the defaults set by the preset |
19:00 |
celeron55 |
currently, the preset that every game is served no matter what is "no effects" |
19:01 |
celeron55 |
currently, the game has to override the "no effects" preset to enable each effect one-by-one, if it wants effects |
19:01 |
celeron55 |
(of course no such concept actually exists in the api or protocol, but this is how i think of it) |
19:03 |
celeron55 |
i think it would sell well, as additionally when starting to develop a new game you could get a head start by just picking a preset and worrying about the details later |
19:04 |
Desour |
maybe put that into a PR or issue |
19:04 |
celeron55 |
well, i won't, unless at least one person agrees with me |
19:04 |
Desour |
it's not the first time this idea was described here |
19:06 |
Desour |
well, I agree that something like this would be good to have. but I don't remember if there was something that speaks against it |
19:07 |
MTDiscord |
<warr1024> I'm not even sure what "presets" would look like. "No effects" and "every effect the user wants to enable" make sense to me, but those are just my opt-in/opt-out suggestions. I don't know what we'd have betwen them that would lead us to need a whole "presets" concept to cover. |
19:10 |
Desour |
could do presets like "coredev A thinks this should be on by default" and "coredev B thinks this should be on by default", or "in a poll, 80% of games were expected to enable feature" :D |
19:11 |
celeron55 |
warr1024: think of graphical styles |
19:12 |
MTDiscord |
<warr1024> Graphical styles are something a game provides to users, not something an engine provides to games. |
19:12 |
MTDiscord |
<warr1024> The problem here is really just that you're accepting complaints about games when you're an engine. |
19:13 |
MTDiscord |
<warr1024> It's the game devs' responsibility to make decisions about what effects should be used and how in each game. I know that when new effects are announced, I decide whether or not to put them in my games, and then update my games to support them. |
19:13 |
MTDiscord |
<warr1024> You could offer as many presets as you want, but only like 2 of them will ever be useful. |
19:14 |
celeron55 |
well, i'm fine with that decision too. but i want to have a decision, so that i don't start thinking of solutions to complaints |
19:15 |
MTDiscord |
<warr1024> It's not even something I really have to decide at all, although I don't mind doing the clerical work. If I'm using some version of the "default" skybox, then a bunch of effects are applicable and it makes sense to opt in to those. If I'm using a custom skybox, they're not applicable and wouldn't make sense to enable. |
19:16 |
MTDiscord |
<warr1024> There might be exceptions to that, but only quite rarely, and in those cases, gamedevs having direct overriding control of options would cover it. |
19:17 |
celeron55 |
warr1024's proposal for my response to complaints sounds something like: "were we're going, you don't want to see any default effects" |
19:17 |
celeron55 |
where* |
19:18 |
MTDiscord |
<warr1024> Presets kind of make sense for something like ffmpeg, where you can predict and calculate the trade-offs of changing certain settings, so there's a sort of natural balance to them, and there isn't a ton of variation in processing performance across systems ... but with graphical stuff, it seems like we run into a lot of times where what's slow for some people has little impact for others. |
19:18 |
celeron55 |
well users are able to disable effects and always will be. it's for that reaon |
19:18 |
celeron55 |
reason* (i can't type) |
19:19 |
MTDiscord |
<warr1024> Well, my first response would be "why are you asking me about this? Ask your game creator" |
19:20 |
celeron55 |
well here's how the complaint was worded this time: "does this mean players will have no way to enable them when playing on outdated servers? i think it is wrong, it should be up to the player to decide how their game look no matter which server they are on" |
19:20 |
MTDiscord |
<warr1024> I mean to be fair having effects be opt-out only (enabled by default if the user wants it) would actually be okay to me, assuming the engine never made any nonsensical decisions, like having sun-based effects like shadows or godrays enabled when using a custom skybox that doesn't have a sun. |
19:21 |
MTDiscord |
<warr1024> If users want to have absolute control over how things look, then we could just give them "no warranty" options. They can force-enable certain things against the desires of the game dev, as long as they are willing to accept the consequences. |
19:22 |
MTDiscord |
<warr1024> In a way, we already have this. The barrier to it is them having to hack the client up. |
19:22 |
MTDiscord |
<warr1024> As a gamedev who doesn't want people posting faked footage of my games to make them look bad, well, that barrier doesn't sound like that bad of a thing, either. |
19:23 |
MTDiscord |
<warr1024> but given that people can already do that with stuff like texture packs, those barriers don't give us much benefit either, so I'm not committed to them. |
19:23 |
celeron55 |
well, i can imagine that would end up with newbies always forcing every setting and then complaining games don't look right. and newbie gamedevs would ask their users to force settings instead of using the apis |
19:24 |
celeron55 |
texture packs go quite a ways against these principles, that's true |
19:24 |
MTDiscord |
<warr1024> haha, that reminds me of the "opaque water" setting |
19:24 |
MTDiscord |
<warr1024> "I have a powerful computer, I'll just enable all the fancy options" ... "wait, why did my water become LESS fancy?" |
19:25 |
celeron55 |
best practice is to make graphics settings that way. you force users to actually understand what they're doing! |
19:25 |
|
SFENCE joined #minetest-dev |
19:26 |
MTDiscord |
<warr1024> So it seems like there are basically like 3 types of presets we could come up with: "disable everything by default and let the gamedev enable individual things", "enable everything by default and let the gamedev disable individual things," and "pick the set of things to enable that make sense, on a case by case basis, based on other config, such as enabling shadows/godrays only if the sun is visible in the skybox, and let the gamedev |
19:26 |
MTDiscord |
explicitly override these in either direction." |
19:27 |
MTDiscord |
<warr1024> Though, I think for some of our fancy effects, the "only if they would make sense" option is actually the maximum we support, we don't have a way to force them on even if they wouldn't. |
19:28 |
MTDiscord |
<warr1024> If we only supported any arbitrary one of those three, then it would probably be okay for gamedevs who are actually staying on top of game maintenance. For stuff like absentee server owners, one may make more sense than the others, or maybe there's meaning in a choice? But maybe we'd have to ask gamedevs to find out... |
19:30 |
celeron55 |
wild idea: when joining old servers, the client could ask: "this is an old server. would you like to turn on the effects the server doesn't know about?" |
19:30 |
celeron55 |
it would probably be more often bad than good |
19:30 |
celeron55 |
but, it would definitely be funny, and it would push server owners to update |
19:30 |
MTDiscord |
<warr1024> That would only really work well if you can tell based on something like protocol version |
19:30 |
MTDiscord |
<warr1024> For situations where e.g. they're updating the engine but not the mod code, it wouldn't help as much. |
19:31 |
MTDiscord |
<warr1024> tbh, shaming server owners for running outdated stuff ... would get you some backlash, but probably not from me :-) |
19:31 |
celeron55 |
:--) |
19:31 |
Desour |
I thought this is about the defaults of the game settings, not the client settings |
19:32 |
celeron55 |
my proposal is about many things |
19:32 |
sfan5 |
I think hecks would have an opinion on if the client should offer to throw the gamedevs artistic vision out of the window if engine versions mismatch |
19:33 |
sfan5 |
and it would be: absolutely fucking not |
19:33 |
MTDiscord |
<warr1024> which would be ironic, because the devs who care about their artistic vision are also the ones responsible enough not to just leave stuff to defaults |
19:34 |
celeron55 |
sfan5: that's why i started with thinking the game should call an api to essentially enable the client to do that |
19:35 |
celeron55 |
well here's my second take on the same thing: there doesn't seem to be that many complaints about it, so we can forget about it if we want to |
19:36 |
|
SFENCE joined #minetest-dev |
19:38 |
|
SFENCE joined #minetest-dev |
19:53 |
[MTMatrix]_ |
<Zughy> Yeah, game devs are in charge of the style, I agree with hecks here. If I don't want shadows in my game, players won't have shadows no matter what |
19:56 |
rubenwardy |
the majority of games don't care, and there's no way for them to state as such |
19:57 |
rubenwardy |
there's certainly a UX problem where we have checkboxes in the settings which don't appear do anything |
19:58 |
MTDiscord |
<warr1024> Throw that one on the pile of settings-related UX problems 😅 |
19:59 |
[MTMatrix]_ |
<Zughy> You know a default we can change? Connected glass currently false |
19:59 |
MTDiscord |
<warr1024> Having settings be more per-game or per-world would certainly make it easier to only show users settings that actually make sense for the thing they care about configuring at the moment. |
20:00 |
MTDiscord |
<warr1024> Yeah, I'd change the connected glass default. In fact, I already did, by getting rid of the _optional in the drawtypes in my games. |
20:00 |
rubenwardy |
lol, talk about breaking the graphics of games |
20:00 |
rubenwardy |
yeah games that want connected glass should just drop the _optional |
22:31 |
|
YuGiOhJCJ joined #minetest-dev |
22:33 |
|
panwolfram joined #minetest-dev |
22:35 |
|
TheCoffeMaker joined #minetest-dev |
22:39 |
|
TheCoffeMaker joined #minetest-dev |
22:46 |
|
pgimeno joined #minetest-dev |
23:05 |
|
Eragon joined #minetest-dev |
23:34 |
|
vampirefrog joined #minetest-dev |