| Time |
Nick |
Message |
| 01:10 |
|
erlehmann joined #minetest |
| 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 |
<Warr1024> 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 |
<Warr1024> Also you have to account for raycast imprecision, plus network latency. |
| 02:46 |
MTDiscord |
<Warr1024> 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 |
| 03:00 |
|
specing_ joined #minetest |
| 03:05 |
|
Verticen_ joined #minetest |
| 03:41 |
|
aldo joined #minetest |
| 03:44 |
|
Boingo joined #minetest |
| 04:17 |
|
Verticen_ joined #minetest |
| 04:59 |
Swift110-mobile |
hey all |
| 05:00 |
|
riff-IRC joined #minetest |
| 05:09 |
|
Flabb joined #minetest |
| 05:10 |
|
ghoti_ joined #minetest |
| 05:11 |
|
bdju joined #minetest |
| 05:11 |
|
m42uko joined #minetest |
| 05:11 |
|
mmuller joined #minetest |
| 05:13 |
|
copygirl joined #minetest |
| 05:14 |
|
illwieckz joined #minetest |
| 05:14 |
|
greeter joined #minetest |
| 05:14 |
|
reductum joined #minetest |
| 05:14 |
|
bwarden joined #minetest |
| 05:15 |
|
epoch joined #minetest |
| 05:15 |
|
sagax joined #minetest |
| 05:46 |
|
erlehmann joined #minetest |
| 06:12 |
|
CWz joined #minetest |
| 07:05 |
|
Kimapr joined #minetest |
| 07:31 |
|
tech_exorcist joined #minetest |
| 07:42 |
|
absurb joined #minetest |
| 08:06 |
|
independent_ joined #minetest |
| 08:08 |
|
independent_ joined #minetest |
| 08:15 |
|
GNUHacker joined #minetest |
| 08:22 |
|
Peppy joined #minetest |
| 08:22 |
|
lhofhansl joined #minetest |
| 08:33 |
|
calcul0n_ joined #minetest |
| 09:24 |
|
bwarden joined #minetest |
| 09:24 |
|
Kimapr joined #minetest |
| 09:43 |
|
Kimapr6 joined #minetest |
| 10:01 |
|
entuland joined #minetest |
| 10:19 |
|
Kimapr joined #minetest |
| 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 |
| 10:34 |
|
Kimapr joined #minetest |
| 10:39 |
|
Kimapr3 joined #minetest |
| 10:54 |
|
independent_ joined #minetest |
| 11:03 |
|
independent_ joined #minetest |
| 11:11 |
|
independent_ joined #minetest |
| 11:13 |
|
Kimapr joined #minetest |
| 11:14 |
|
independent_ joined #minetest |
| 11:21 |
|
Boingo joined #minetest |
| 11:23 |
|
Kimapr joined #minetest |
| 11:32 |
|
independent56 joined #minetest |
| 11:35 |
|
independent_ joined #minetest |
| 11:37 |
|
independent_ joined #minetest |
| 11:40 |
freshreplicant[m |
What is the default water_level setting for v7/Minetest? |
| 11:40 |
MTDiscord |
<ACRONIX> https://discord.gg/nNUq82e5 |
| 11:42 |
|
independent56 joined #minetest |
| 11:42 |
MTDiscord |
<Sublayer plank> uhh |
| 11:42 |
MTDiscord |
<Sublayer plank> that icon's not minetest |
| 11:43 |
MTDiscord |
<ACRONIX> tu et français |
| 11:43 |
MTDiscord |
<ACRONIX> pour quoi tu à quiter |
| 11:50 |
MTDiscord |
<Jonathon> Freshreplicant, look at example.minetest.conf, i think it was one |
| 11:51 |
freshreplicant[m |
<MTDiscord "<Jonathon> Freshreplicant, look "> Thanks, yeah it seems it was 1. I guess a game/mod changed it somehow. |
| 11:59 |
|
Verticen_ joined #minetest |
| 12:04 |
|
DUMdum joined #minetest |
| 12:11 |
|
independent56 joined #minetest |
| 12:14 |
|
independent56 joined #minetest |
| 12:22 |
|
Kimapr4 joined #minetest |
| 12:28 |
|
entuland joined #minetest |
| 12:43 |
|
independent56 joined #minetest |
| 13:05 |
|
independent56 joined #minetest |
| 13:08 |
|
independent56 joined #minetest |
| 14:01 |
|
independent56 joined #minetest |
| 14:32 |
|
calcul0n__ joined #minetest |
| 14:35 |
|
Lunatrius joined #minetest |
| 14:59 |
|
specing_ joined #minetest |
| 15:04 |
|
Hawk777 joined #minetest |
| 15:14 |
|
Fixer joined #minetest |
| 15:42 |
|
Extex joined #minetest |
| 15:45 |
|
Sven_vB joined #minetest |
| 15:49 |
|
independent56 joined #minetest |
| 15:51 |
|
independent56 joined #minetest |
| 15:51 |
|
longerstaff13 joined #minetest |
| 16:00 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> That along with "mods are required to mess with config" |
| 16:08 |
sfan5 |
they are not |
| 16:08 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Those are overridden by user config though, aren't they? |
| 16:10 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> In theory just having nobody actually override this setting would work, but unfortunately theory is not where minetest is actually played. |
| 16:25 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Certainly gamedev is not a perfect world either, but at least it gives us some central figures to scream at |
| 16:26 |
MTDiscord |
<Warr1024> "each server use its own minetest.conf" does not work for SP. |
| 16:27 |
MTDiscord |
<Warr1024> though yes, that is pretty much the de facto standard for MP |
| 16:27 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
|
tech_exorcist joined #minetest |
| 16:29 |
MTDiscord |
<Warr1024> "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 |
<Warr1024> 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 |
<Warr1024> 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:44 |
|
erlehmann joined #minetest |
| 16:47 |
|
Krock joined #minetest |
| 16:50 |
|
Talkless joined #minetest |
| 16:50 |
epoch |
"this game is trying to change the setting to allow TNT. do you want to allow it?" |
| 16:58 |
|
Extex joined #minetest |
| 17:10 |
MTDiscord |
<Warr1024> Do mods and menus use the same methods to access settings? |
| 17:11 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> That also keeps bug-for-bug compatibility which everyone loves :-) |
| 17:11 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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:14 |
|
garywhite joined #minetest |
| 17:14 |
|
garywhite joined #minetest |
| 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 |
<Warr1024> 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:30 |
|
DUMdum joined #minetest |
| 17:31 |
MTDiscord |
<Warr1024> 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 |
| 17:42 |
|
entuland joined #minetest |
| 18:03 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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:05 |
|
delta23 joined #minetest |
| 18:06 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> I suppose I could include a warning message |
| 18:34 |
MTDiscord |
<Warr1024> "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 |
<Warr1024> 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:38 |
|
y5nw joined #minetest |
| 18:42 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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:49 |
|
DUMdum joined #minetest |
| 18:50 |
MTDiscord |
<Warr1024> 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 |
|
y5nw joined #minetest |
| 18:52 |
MTDiscord |
<Warr1024> ...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 |
<Warr1024> 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 |
<Warr1024> Another one I need to control is enable_damage and creative_mode, but Wuzzy already has a PR open for that |
| 18:55 |
MTDiscord |
<Warr1024> 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 |
|
independent56 joined #minetest |
| 18:56 |
MTDiscord |
<Warr1024> 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. |
| 18:59 |
|
valhalla joined #minetest |
| 19:00 |
rubenwardy |
For now, just set the setting from the game |
| 19:03 |
|
independent56 joined #minetest |
| 19:04 |
MTDiscord |
<Warr1024> 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. |
| 19:17 |
|
hecks joined #minetest |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> They are janky, but I'm used to minetest levels of jank so it didn't really bother me :-D |
| 20:44 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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:19 |
|
Verticen_ joined #minetest |
| 21:27 |
|
DUMdum joined #minetest |
| 21:29 |
|
AristotIe joined #minetest |
| 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:38 |
|
Julius joined #minetest |
| 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 |
<wwar> Sokomine, the glitching to walls was fixex long time ago, |
| 21:43 |
MTDiscord |
<wwar> there is something called light damage, when they are in bright places they lose healtj |
| 21:44 |
MTDiscord |
<wwar> Health* |
| 21:45 |
MTDiscord |
<wwar> They fixed that glitching bug by making the hitbox a bit taller |
| 21:56 |
Sokomine |
they're peaceful npc. not sensitive to light |
| 22:00 |
|
Sven_vB joined #minetest |
| 22:02 |
MTDiscord |
<wwar> hm.. maybe a mob attacked them? |
| 22:02 |
MTDiscord |
<wwar> protector rune does not protect against hostile mobs |
| 22:04 |
MTDiscord |
<wwar> Also NPCs never glitched in walls, only small mobs like chicken, parrot or rat |
| 23:05 |
|
specing_ joined #minetest |
| 23:17 |
|
hecks joined #minetest |
| 23:27 |
|
DUMdum joined #minetest |
| 23:49 |
|
hanetzer joined #minetest |
| 23:49 |
|
hanetzer joined #minetest |
| 23:50 |
|
AliasAlreadyTake joined #minetest |
| 23:57 |
|
Julius left #minetest |
| 23:59 |
|
absurb joined #minetest |
