Time Nick Message 02:42 Extex Ok so I want to be able to test if a player can see an entity, but have it support fov changes, any idea how I would go about doing so? 02:44 MTDiscord There's no good way. You sort of have to assume some worst case. If it's within like 30 degrees they almost surely can see it, but you can't be sure they don't up to 180 degrees. 02:45 MTDiscord Also you have to account for raycast imprecision, plus network latency. 02:46 MTDiscord I've had a weeping angels mod suggested to me on at least 2 separate occasions so I've had to consider this... 02:48 Xanabella Dev-Test has one Example for every entitiy, if you see it it should go and for Multiplayer ... Host Server and ask somebody to join and look 02:51 Pexin just use 180 02:52 Pexin use 140, only a deranged lunatic would use that high 04:59 Swift110-mobile hey all 10:31 Calinou Minetest specifies FOV as a vertical FOV in minetest.conf, but horizontal FOV depends on your monitor's aspect ratio 10:32 Calinou if you want to play it safe, you can use the default horizontal FOV for a 21:9 monitor: 119 degrees 10:32 Calinou (https://themetalmuncher.github.io/fov-calc/) 10:33 Calinou there's no way to know a client's monitor aspect ratio from the Lua API, so you can't guess their horizontal FOV that way either 10:33 Calinou Minetest supports any aspect ratio, but I doubt anyone is playing it with a monitor wider than 21:9 11:40 freshreplicant[m What is the default water_level setting for v7/Minetest? 11:40 MTDiscord https://discord.gg/nNUq82e5 11:42 MTDiscord uhh 11:42 MTDiscord that icon's not minetest 11:43 MTDiscord tu et français 11:43 MTDiscord pour quoi tu à quiter 11:50 MTDiscord Freshreplicant, look at example.minetest.conf, i think it was one 11:51 freshreplicant[m Freshreplicant, look "> Thanks, yeah it seems it was 1. I guess a game/mod changed it somehow. 16:00 MTDiscord IIRC there are games that change it, and the engine is supposed to handle this properly but doesn't. e.g. https://content.minetest.net/threads/639/ 16:00 sfan5 that has been fixed already 16:01 sfan5 it was a regression that wasn't in 5.3 16:02 MTDiscord Interesting. Does minetest.settings:set() also take effect only for the current world then, or does that one also still leak settings into minetest.conf? 16:04 sfan5 no, it's global 16:04 MTDiscord Right, but does it leak values back into minetest.conf and thus pollute settings cross-world? 16:05 sfan5 by "global" I mean "into minetest.conf" 16:05 MTDiscord Okay, is there already an existing bug report for that? 16:06 sfan5 there will be none because it's not a bug 16:06 MTDiscord Okay so how do I file a "design flaw" report then :-/ 16:07 sfan5 is "mods can mess up the users config" the flaw? 16:07 sfan5 because mods do not lack a way to set mapgen settings per-world properly 16:07 MTDiscord That along with "mods are required to mess with config" 16:08 sfan5 they are not 16:08 MTDiscord Last time I checked, mapgen_settings only affect mapgen, so settings that are not related to mapgen need to be set via minetest.settings:set 16:08 sfan5 sure 16:08 MTDiscord Is it actually meaningful to set, say, time_speed as a mapgen setting, and will that only apply to the given world then? 16:09 sfan5 nope doesn't work 16:09 sfan5 but putting it in the games' minetest.conf does 16:09 MTDiscord Those are overridden by user config though, aren't they? 16:10 MTDiscord and games also can't prevent the engine from interpreting those directly, so they need to be set correctly in settings. 16:10 sfan5 if the user wants to break the game why prevent him from doing so? 16:11 MTDiscord Because as a game publisher I am responsible for providing the user with the correct experience under all reasonable circumstances, and because Minetest fosters a culture of adding salt to your food before tasting it. 16:13 sfan5 but is that a reasonable circumstance? most people won't even look at what time_speed is 16:14 MTDiscord hence why they will get config from somebody else and set it to 72 naively. Somehow that has crept into my OWN settings on multiple occasions, probably due to mods that have no other way to change time speed. 16:16 MTDiscord In any event I as a modder/gamedev need the ability to make settings values that have no meaning other than breaking the game not set to values that break the game, and I should not have to be fighting against the engine while it's trying to provide users with every possible footgun and bypassing the game design stage entirely. 16:16 MTDiscord There is a problem specifically for how time_speed is used and how it's configurable, and then there is a separate issue with the entire flawed idea of "user freedom" applying to Minetest's users' users but not the users themselves. 16:17 MTDiscord At least presumably the latter has been acknowledged to some extent, but I guess I'll need an issue for the former at least. 16:19 MTDiscord There are probably a few ways it could be handled properly. Maybe allow all settings to be overridden by mod per-world. Maybe don't have the engine directly interpret any settings for world behavior directly, but go though the mods. Maybe sprinkle multipliers or adjustments or something for each setting value. I'm not sure. 16:21 sfan5 I'd say you don't really need this if mods were behaving and not setting time_speed without the users consent (I consider that a bug) 16:21 sfan5 second, if this is done someone will need to define which settings are too important to be set by the user 16:23 MTDiscord I just searched through Discord and found 3 examples of people messing with time_speed already. I also have no power over what other mods do, but am responsible for defending MY own game from their bad behavior, and so if we can't get every mod to behave (or be maintained) and there's no way to protect other mods from externalities or force those to be internalized by the perpetrators, we're just setting up a "tragedy of the commons" 16:23 MTDiscord scenario. 16:23 MTDiscord In theory just having nobody actually override this setting would work, but unfortunately theory is not where minetest is actually played. 16:25 MTDiscord If we keep everything within the settings subsystem then the most straightforward way I can think of it would be to just have a "forced_settings" in game.conf which is (1) never interpreted from user settings, and (2) causes other settings to be never interpreted from user settings. 16:25 MTDiscord I don't know how to separate client vs. server settings out from that, but possibly it doesn't need to be done, because handing gamedevs a footgun is a different proposition from handing players a footgun: we can expect gamedevs to at least be informed to some extent. 16:26 sfan5 the land of expection is not where gamedev happens either 16:26 sofar the best solution I've come up with is to have each server use it's own minetest.conf 16:26 MTDiscord Certainly gamedev is not a perfect world either, but at least it gives us some central figures to scream at 16:26 MTDiscord "each server use its own minetest.conf" does not work for SP. 16:27 MTDiscord though yes, that is pretty much the de facto standard for MP 16:27 MTDiscord It's SP where cross-world leakage is really painful though 16:27 sfan5 I remember crafter trying to add a security exception for one of its mods so it could download skins, of course the engine ignores these but it serves as an example 16:27 MTDiscord The problem with the theory of giving players control over all the settings is that you can't get informed consent from people who actively resist becoming informed... 16:28 MTDiscord Yes, I would rather gamedevs get in trouble for trying to do things with settings that break gameplay, than make the players have to suffer the consequences while gamedevs are effectively powerless to do anything about it. 16:29 MTDiscord "Sorry, I am forced by the game engine to hold you responsible for that" 16:31 sfan5 you can also error out at load time if settings are not what you expect 16:31 sfan5 but I guess that is also "holding the players responsible" 16:31 MTDiscord As far as just having nobody actually mess with time_speed, that doesn't actually work in practice either, because you can only set it to a constant in minetest.conf, you can't vary it at runtime, like you can with settings:set. Maybe the cleanest thing to do would be to provide a runtime-only adjustment specifically for this setting, possibly for certain other specific settings... 16:33 MTDiscord Yeah, the problem is that for a lot of gamedevs, new completely-naive players are an important target population and we can't hold them responsible for anything at all. The new content installation system helps a lot, but we also can't be sure they didn't get bad or outdated advice elsewhere, so anything we can do to help is important... 16:34 sfan5 warning users about their broken configurations hopefully helps in some cases 16:34 rubenwardy I support adding per-world minetest.conf, and then making minetest.settings:set only write to there 16:36 sfan5 we already have an issue for that 16:36 sfan5 but it's not clear to me how client settings will be separated from that 16:36 sfan5 you don't want to got to the key change menu only to find that you only changed the keys in this world 16:36 sfan5 go* 16:50 epoch "this game is trying to change the setting to allow TNT. do you want to allow it?" 17:10 MTDiscord Do mods and menus use the same methods to access settings? 17:11 MTDiscord Maybe the simplest way to separate them out is to just have a minetest.world_setttings:set() thing for setting world-specific settings, and keep builtin and MTE accessing the global stuff. 17:11 MTDiscord That also keeps bug-for-bug compatibility which everyone loves :-) 17:11 MTDiscord world_settings:set() or settings:set_world() or whatever, as long as I have a method I can call instead of naively scrambling settings. 17:12 MTDiscord This would give me a way to be a good citizen to other SP worlds, BUT also defend myself against other SP worlds that are not being good citizens, so it would solve at least some problems. 17:25 rubenwardy There's no need for that 17:25 rubenwardy minetest.settings should just write to world settings 17:26 rubenwardy The menu API is different 17:28 MTDiscord If that's the case then it works for me. Got an issue number I can look at, or at least the right search term to find it? :-) 17:31 MTDiscord I found #6966, is that the one? 17:31 ShadowBot https://github.com/minetest/minetest/issues/6966 -- World-specific settings 17:33 rubenwardy Title looks right 18:03 MTDiscord Hmm, okay, so assuming that 6966 is not going to get resolved for a while, what's my best strat for actually addressing the time_speed issue? For all worlds running my game, I want the setting to be 0. 18:03 MTDiscord It seems like I would set it in minetest.conf for the game, not set it in mod code, and then have to (1) work around it being non-zero, probably by repeatedly calling set_timeofday() in a timer, and (2) warn somebody somehow. 18:04 MTDiscord For (1) that will cause some extra network traffic and won't actually achieve the correct effect (it will be juddery) but it might be a close enough approximation...? 18:05 MTDiscord For (2) though figuring out who to inform, and how, might be tricky. Possibly just anybody with the "server" priv? Maybe just as a colored-text chat message? A popup error upon entering would be bad enough to be considered "game-breaking". 18:06 MTDiscord Given that it's just a chat message I'd have to consider that a "warning" so whatever mitigation I use I would have to assume may need to run indefinitely. Even being informed of the issue a server owner can't necessarily restart the server at just any time. 18:12 sfan5 /set -n time_speed 0 18:13 Hawk777 If it’s a server, isn’t it likely that either (1) they set this before first startup, in which case they will likely connect right away to check things out, see it right away, and be able to restart right away because nobody else has joined yet; or (2) they just changed this in an existing world as part of some kind of experiment, in which case they’re probably well equipped to change it back right away when the experiment fa 18:13 Hawk777 And if it’s singleplayer, the player can probably restart any time, especially right after they first start the game. 18:14 MTDiscord re: "/set -n" yeah, that's what I was doing before, but now I'm trying to be a good citizen. The correct thing for them to do is to completely unset the setting, not set it to the setting that's right for this world but wrong for the other. 18:14 sfan5 the server admin can fix it without restarting the world is what I'm saying 18:14 sfan5 and then fix it correctly during downtime later 18:15 MTDiscord As for the "if it's a server" thing, I don't want to go too far down the path of having a different flow for each use-case, and I don't want to get too deep into how non-naive server operators would operate their servers. The whole point of a warning is for users who don't already know... 18:16 Hawk777 My logic led to the same conclusion at the end of both paths, though: it should be OK to just yell at them that they broke it and not implement a nasty workaround to keep things limping along until they fix it. And as sfan5 mentioned it can be fixed without even restarting. 18:16 MTDiscord Eh, I could give them a stopgap solution I guess, but I'm going to have a small attention budget to work with so I don't know if I'll be able to get too far into hybrid short/long term solutions. 18:18 MTDiscord If I'm gonna not solve the problem properly then I'd rather go with the workaround and no warning than the warning and no workaround. 18:19 MTDiscord I already have a non-proper solution that solves it soundly after all: I can just set time_speed to 0 myself and make this "someone else's problem" but in an engine-ward direction rather than a user-ward one, i.e. hold the people who have the power to solve it responsible instead of the user. 18:27 Hawk777 Hm, but workaround without warning means the player will get a suboptimal experience (the workaround instead of the proper solution) forever because they don’t *know* they have anything to fix. Warning without workaround, they fix it, everything is perfect. 18:28 MTDiscord So what it sounds like I'm left with is: (1) set time_speed to 0 in the game's minetest.conf; if the user hasn't set it explicitly, then that will Just Work, and (2) if time_speed at runtime is non-zero then that means the player has messed with it, so I can just change it back to 0 automatically only in that case, which fits with the general "user gets what they deserve for messing with settings" philosophy then. 18:33 sfan5 I suggest (1) because you're going to do that either way and check at runtime and yell at the user if it's not zero 18:33 MTDiscord I suppose I could include a warning message 18:34 MTDiscord "The game was unable to configure itself properly, you have to fix it" is pretty shitty advertising for the game, and for minetest overall. 18:35 sfan5 it should sound more like "your settings break this game, fix them or enjoy it broken" 18:35 MTDiscord Having game devs forced to make users responsible for configuration is going to conflict with rubenwardy's goals for the featured packages in CDB, at least. 18:36 sfan5 haven't read those yet 18:37 celeron55_ i think a game should be able to override a setting like time_speed if it wants to. it's clearly a similar thing as something like creative mode, i.e. applicable to some games and some not 18:42 MTDiscord Yeah, the problem is just figuring out how we should mix games that need to set time_speed with those that want to leave the user in control, because right now setting it at the game level overrides it for the user, which pollutes settings affecting all other games that assume it's the user's choice. 18:42 MTDiscord Fixing 6966 would resolve it, but unless somebody who actually understands the relevant bits gets a fire lit under their ass somehow, I still need to figure out how I should limp along in the meantime. 18:43 MTDiscord On the other hand, how well I limp along might also have an impact on the ability to light or sustain said ass-fires so I don't want to completely sweep this under the rug, but at the same time the user shouldn't be the one who has pressure put on them because of it. 18:44 MTDiscord er, s/user/player/, to clarify, since we're talking in an enginey context where gamedevs are really the frontline consumers. 18:44 celeron55_ maybe it should be a world setting 18:45 MTDiscord Yeah, I think that's where #6966 was going with it. Just not a lot of traction on that right now... 18:45 ShadowBot https://github.com/minetest/minetest/issues/6966 -- World-specific settings 18:48 MTDiscord Hmm, looking at rubenwardy's comment in there, it doesn't look like that would work well either, unless the game were to look for a world/minetest.conf, parse those settings, merge its own into there, and then write it back. 18:50 MTDiscord The bottom-line use-case is: as a game dev, I need to be able to control certain setting values (currently mainly time_speed) to prevent them from being modified by users or other games/mods when the only other values they can be set to merely degrade or break the game. 18:52 MTDiscord ...or I need to be able to control by some other means the engine behaviors that are currently only controllable via those settings. 18:53 sfan5 perhaps that'd be a better approach 18:53 sfan5 because on a whim I can't think of any other server settings that games need to control 18:54 MTDiscord Yeah, decoupling it from settings was one thing I suggested at some point. Instead of minetest using the time_speed setting we could just have minetest.set_time_speed(num) or something and have builtin do the job of pulling it from settings by default, but then after that, persisting it as a setting vs. adjusting it at runtime could be independent. 18:55 MTDiscord Another one I need to control is enable_damage and creative_mode, but Wuzzy already has a PR open for that 18:55 MTDiscord I also need to be able to control movement_liquid_sink, but that should really be a player physics override to begin with. 18:56 MTDiscord And the last one is display_gamma, but I need to be able to adjust it but can't take total control. I want to be able to apply a baseline adjustment to boost mid/low tones, but the player still needs to be able to adjust to compensate for display-specific needs. 19:00 rubenwardy For now, just set the setting from the game 19:04 MTDiscord Yeah, for now I'm setting most of these in the per-game default config, since they're also generally not messed-with. time_speed is a bit more of a pathological case though. 20:14 erlehmann > The bottom-line use-case is: as a game dev, I need to be able to control certain setting values (currently mainly time_speed) to prevent them from being modified by users 20:15 erlehmann does this have anything to do with cheating or not? 20:15 erlehmann prob mostly aesthetic things ig 20:26 MTDiscord Aesthetics does play a big part. We like when people try the game, aren't instantly turned off by the visuals, and actually stick around to see the real value in it. We don't need RTX whatever, but at least making sure there aren't e.g. weird visual artifacts would help a lot. 20:27 MTDiscord In my case, I think if the shadow shader could be force-disabled from the server-side it would probably mitigate this enough for me, actually. 20:27 MTDiscord I have no complaint about how the shadows work or look, they just aren't applicable in my game because I don't have a traditional skybox with light coming from a single direciton. 20:35 erlehmann > We don't need RTX whatever 20:35 erlehmann yeah we don't 20:35 erlehmann rtx is a griefer 20:35 erlehmann Warr1024 aren't the new shadows so buggy that they do not even make it default? 20:44 MTDiscord They are janky, but I'm used to minetest levels of jank so it didn't really bother me :-D 20:44 MTDiscord I mean there are limitations, like geometry that's not loaded can't cast a shadow, and there's not an awful lot a shader dev can do about that in reasonable time. 20:48 MTDiscord As a general principle I think we try not to make things default for their first release unless we have reason to believe that they are better for all players, offer no clear drawbacks, and only acceptable risks. Shadows ARE expensive on the GPU though, so users on high-end rigs can turn them on, but other users may not want sudden unexpected framerate drops... 21:30 Sokomine anyone any idea what makes mobs (mobs_redo ones) loose health? 21:32 AristotIe I always assumed it was because they glitched into walls and took suffocation damage, but I don't actually know if that's correct 21:32 Sokomine aah. yes, i remember what it was...randomly set hp at start 21:33 AristotIe oh 21:39 Julius would it be possible to enable the news rss feed on the forum? 21:40 Julius https://forum.minetest.net/app.php/feed/news 21:40 Julius https://forum.minetest.net/feed.php?mode=news 21:40 Julius I mean 21:40 Julius normally that works on phpbb forums 21:41 Julius I would like to add it to our feed aggregator: https://planet.freegamedev.net 21:42 Julius if I just use the feed for the news forum directly I also get a feed entry for every comment 21:43 Sokomine ooh! a bug 21:43 Sokomine er. not here... 21:43 MTDiscord Sokomine, the glitching to walls was fixex long time ago, 21:43 MTDiscord there is something called light damage, when they are in bright places they lose healtj 21:44 MTDiscord Health* 21:45 MTDiscord They fixed that glitching bug by making the hitbox a bit taller 21:56 Sokomine they're peaceful npc. not sensitive to light 22:02 MTDiscord hm.. maybe a mob attacked them? 22:02 MTDiscord protector rune does not protect against hostile mobs 22:04 MTDiscord Also NPCs never glitched in walls, only small mobs like chicken, parrot or rat