| Time |
Nick |
Message |
| 00:41 |
|
ShadowBot joined #minetest-dev |
| 00:45 |
|
ShadowBot joined #minetest-dev |
| 01:09 |
|
ShadowBot joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:12 |
|
TheCoffeMaker joined #minetest-dev |
| 05:14 |
|
TheCoffeMaker joined #minetest-dev |
| 05:17 |
|
TheCoffeMaker joined #minetest-dev |
| 06:03 |
|
Mantar joined #minetest-dev |
| 06:47 |
MTDiscord |
<lemente> @grorp what if a game could pick between opt in and opt out? That way game creators who don't want their game visually modified can opt out. And the others can opt in (which would be the default). And it could probably be adapted later to opt in to various available styles/presets. |
| 07:24 |
|
TheCoffeMaker joined #minetest-dev |
| 07:35 |
|
TheCoffeMaker joined #minetest-dev |
| 07:43 |
|
TheCoffeMaker joined #minetest-dev |
| 07:47 |
|
TheCoffeMaker joined #minetest-dev |
| 07:49 |
|
TheCoffeMaker joined #minetest-dev |
| 08:21 |
|
TheCoffeMaker joined #minetest-dev |
| 08:22 |
|
TheCoffeMaker joined #minetest-dev |
| 08:41 |
|
TheCoffeMaker_ joined #minetest-dev |
| 09:00 |
|
TheCoffeMaker joined #minetest-dev |
| 09:03 |
|
TheCoffeMaker joined #minetest-dev |
| 09:08 |
|
TheCoffeMaker joined #minetest-dev |
| 09:36 |
|
TheCoffeMaker joined #minetest-dev |
| 09:39 |
|
TheCoffeMaker joined #minetest-dev |
| 09:54 |
|
TheCoffeMaker joined #minetest-dev |
| 10:24 |
|
TheCoffeMaker joined #minetest-dev |
| 10:43 |
|
TheCoffeMaker joined #minetest-dev |
| 10:50 |
|
TheCoffeMaker joined #minetest-dev |
| 11:07 |
|
TheCoffeMaker joined #minetest-dev |
| 11:09 |
|
TheCoffeMaker joined #minetest-dev |
| 11:15 |
|
TheCoffeMaker joined #minetest-dev |
| 11:50 |
|
TheCoffeMaker joined #minetest-dev |
| 12:04 |
MTDiscord |
<warr1024> how would you choose whether to opt in or opt out? Would you opt in to opting in, or would you opt in to opting out? |
| 12:05 |
|
Fenrir24 joined #minetest-dev |
| 12:05 |
MTDiscord |
<warr1024> You can't choose your defaults, because defaults are what happens when you don't choose. |
| 12:05 |
|
Fenrir24 left #minetest-dev |
| 12:10 |
|
Fenrir24 joined #minetest-dev |
| 12:50 |
|
chimupurei joined #minetest-dev |
| 12:54 |
|
TheCoffeMaker joined #minetest-dev |
| 13:05 |
|
Lupercus joined #minetest-dev |
| 13:23 |
|
Lupercus joined #minetest-dev |
| 13:32 |
[MTMatrix] |
<grorp> lemente: interesting idea, though there's probably not much of a difference between having "realistic"/"cartoonish" or true/false |
| 13:33 |
[MTMatrix] |
<grorp> warr1024: you could also call them "presets" |
| 13:39 |
[MTMatrix] |
<grorp> maybe like this: enable and set reasonable values for all effects by default. add a "disable all effects by default instead" switch so that disabling everything is easy and you can get rid of future effects as well. of course, still allow manually changing effect settings. |
| 13:45 |
[MTMatrix] |
<grorp> another thing: the bloom effect is currently not server-controlled. bloom is something which many people seem to consider annoying, so it being client-controlled isn't bad. however, it could be (ab?)used for some stuff in games: portal transitions, drugs, ... |
| 14:14 |
MTDiscord |
<herowl> Negative saturation is drugs :juanchi_face: |
| 14:24 |
|
Fenrir24 joined #minetest-dev |
| 15:34 |
MTDiscord |
<warr1024> Probably the simplest way to handle opt-in/out would be to have games publish a target version separate from maximum version (the latter being used as a filter on CDB). If your target version is a version before shadows were introduced, then shadows are disabled to maintain compat. If you bump the version to one where shadows are available, you're implicitly opting in to user-controlled shadows unless you also use the API methods |
| 15:34 |
MTDiscord |
for limiting it. Apply that to other new features as possible. |
| 15:35 |
MTDiscord |
<warr1024> (Shadows are still kind of a good example of this because they're so game-specific, and have strong risk of looking ridiculous when used with e.g. any custom skybox). |
| 15:36 |
MTDiscord |
<warr1024> With a "target API version" sort of thing, you can switch to an opt-out approach instead of opt-in (games get new features automatically when they update without having to add a bunch of API calls) but maintain compat for games that aren't releasing new versions every new MT version. |
| 15:36 |
MTDiscord |
<warr1024> (target version also doesn't affect minimum version; you can target 5.9 while still maintaining support for 5.7 by just checking the right proto version, feature flags, or presence of methods) |
| 15:39 |
|
Lupercus joined #minetest-dev |
| 16:43 |
|
chimupurei left #minetest-dev |
| 16:53 |
|
Lupercus joined #minetest-dev |
| 18:12 |
|
Warr1024 joined #minetest-dev |
| 18:12 |
MTDiscord |
<grorp> @warr1024 this would remove the "effects work on old, not-yet-updated games / old servers" and "game authors don't have to do something each Minetest release" benefits though |
| 18:13 |
MTDiscord |
<warr1024> Right, it would also remove the "effects work on old, not-yet-updated games" risk though. |
| 18:14 |
MTDiscord |
<grorp> yeah, but that risk would also be removed if there was an option for games to say "disable all (future) effects if I don't say otherwise" |
| 18:15 |
MTDiscord |
<warr1024> We'd have to add an option that says "I'm aware of the existence of a 'disable all future effects' option but chose not to enable it" then, because there are past games already out there that were never asked whether they wanted to allow future effects or not, and their silence does not imply consent. |
| 18:16 |
MTDiscord |
<warr1024> So we could have an opt-out but you'd still have to opt in to it. |
| 18:16 |
MTDiscord |
<warr1024> I suppose that would work fine for me though. |
| 18:17 |
MTDiscord |
<grorp> what. this is getting out of hand. |
| 18:18 |
sfan5 |
given the drama previous supposed "graphical improvements" caused I would be very vary of adding new opt-out features |
| 18:19 |
sfan5 |
it would also be more appropriate to Minetest claiming to be a game engine when new features are opt-in and server-controlled |
| 18:20 |
MTDiscord |
<warr1024> Yeah, as a game developer I'm not happy when the engine makes game design changes without my consent. |
| 18:22 |
MTDiscord |
<warr1024> There are some things I tolerate, like the inability to control fonts or HUD/GUI sizes, as an accessibility necessity, and given that not all gamedevs are working in good faith to ensure accessibility (some actually make anti-accessibility features, like the ones designed to prevent mobile users from accessing servers) but there's no accessibility benefit to enabling shadows or bloom or something. |
| 18:25 |
MTDiscord |
<grorp> I suppose the problem comes down to whether you treat Minetest as an engine or a game. If you say Minetest is a game, you should control the visual effects. If you say Minetest is an engine, games should control the visual effects. |
| 18:26 |
MTDiscord |
<grorp> and they should have the ability to give control to the user somehow, if they don't care |
| 18:26 |
MTDiscord |
<warr1024> If I wanted to treat minetest like a game, then I would run one of the old versions from back when it WAS a game. |
| 18:26 |
MTDiscord |
<warr1024> My use-case though is playing games on it, and I don't really play games on games. |
| 18:27 |
MTDiscord |
<grorp> I'm not saying you should lol |
| 18:27 |
MTDiscord |
<warr1024> Minetest is not fully an "engine" yet, it still has a lot of "game" legacy in it, but we've been working pretty hard these past few years to correct that. It wouldn't make sense to move backwards now. |
| 18:29 |
MTDiscord |
<warr1024> I really don't mind if the user has the ability to customize anything they want (after all, they can hack the games if they need to) but while we should make it easy to do on purpose, we should make it hard to do by accident. Right now, a user making a setting change, like enabling shadows for one game, "leaks" that setting to all other games too, so disabling shadows entirely is the only option gamedevs have for when shadows don't |
| 18:29 |
MTDiscord |
make sense and would actually detract from the game. |
| 18:30 |
MTDiscord |
<warr1024> If it were possible to enable settings situationally, so that users don't accidentally enable settings without meaning to, then allowing users final say would become a lot more viable without being detrimental to gamedev. |
| 18:31 |
MTDiscord |
<warr1024> time_speed is an egregious example of this. There's a lot of bad advice out there to "set time_speed back to the default of 72 if a game sets it to 0", which is what causes games to have to CONTINUE to set it to 0, because players should be REMOVING the time_speed setting in their conf to return it to the default, because the default is game-specific. |
| 18:32 |
MTDiscord |
<warr1024> I suppose, to sum it up, a lot of the difficulty we have designing an API for games to control visual effects would be a LOT less urgent if we could fix settings scope 🤔 |
| 18:32 |
MTDiscord |
<grorp> How did I end up being told "Minetest is still a lot of game, but we're trying to make it an engine" when I worked on exactly that, for example by implementing the migration stuff for debundling MTG. I don't understand. |
| 18:33 |
MTDiscord |
<warr1024> > comes down to whether you treat Minetest as an engine or a game |
| 18:35 |
[MTMatrix] |
<Zughy> Minetest will never be an engine, Minetest is a game creation platform; like Roblox, but without all the pile of crap on ethics |
| 18:36 |
MTDiscord |
<herowl> Depends on how you define an engine I guess. |
| 18:37 |
[MTMatrix] |
<Zughy> I don't, dictionaries and encyclopedias do |
| 18:37 |
MTDiscord |
<herowl> Engine doesn't have to be a general-purpose haveitall |
| 18:37 |
MTDiscord |
<warr1024> A game creation platform is definitely leaning more toward the engine side of the game/engine divide than the game side. As long as we are going to look at "engine vs game" as a single dimension that we're trying to move along, perpendicular components don't matter so much. |
| 18:39 |
MTDiscord |
<warr1024> Yes, pointing out that it's not really quite either of those things makes the argument about which it is go away, but that's not necessarily good; it's actually a meaningful discussion to have even if it's imprecise. |
| 19:05 |
|
[MTMatrix] joined #minetest-dev |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 22:50 |
|
Fenrir24 joined #minetest-dev |
| 23:16 |
|
Fenrir24 left #minetest-dev |
