Time Nick Message 03:18 euphoria Hello there 07:23 VanessaE anyone here good with advtrains? 07:25 specing with code or use? 07:25 VanessaE use 07:31 VanessaE a few of us on my Traintable server were playing around, and started a descending tunnel, starting at +2.5m and going down at a rate of 1 in 3 meters, the longest slopes advtrains has. but if you place a wagon on the tracks at the top of the slope and accelerate forward, it stops at the slope, it won't descend. 07:31 VanessaE https://imgur.com/wL5G3Q4.png 07:32 VanessaE the displays inside the wagon, if I read it right, indicate that it thinks the track ends at the slope 07:41 specing Maybe ask on LINUXFORKS? 07:42 VanessaE oh, and if I place the wagon ON the slope, it sees there's another 65m of track, and it'll go down just fine. 07:42 VanessaE linuxforks? not familiar with that 07:43 VanessaE I guess you mean https://bugs.linux-forks.de/advtrains/ 07:43 VanessaE I was just gonna ask on the forum thread 07:50 specing yeah the train autism server 08:25 MTDiscord I'd like to ask in here also: Why is someone in the forum allowed to create a thread with very bold claims that could be super damaging to a particular MT server WITHOUT having even a tiny bit of evidence?? 08:28 MTDiscord So far all they do is trying to sell their own point of view as facts and I as the server owner have to watch how that happens....this doesn't feel right 08:33 celeron55 so from now on every thread has to go through you before it can be posted? 08:33 celeron55 come on, link the thread and explain 08:35 \ no that would be too logical 08:35 \ we have to fight vague claims with more vague claims 08:45 MTDiscord https://forum.minetest.net/viewtopic.php?f=3&t=26895 08:52 celeron55 that the 08:54 \ lol that thread is quite a read 08:55 MTDiscord I told you the subject is damaging 08:56 celeron55 this makes no sense to me, i'm moving it to trash 08:56 celeron55 if another moderator finds it worth being public them move it back 09:00 celeron55 i think if someone wants to create a thread like that, it absolutely has to have evidence in the first post 09:03 celeron55 that already could have been worth defamation charges towards the OP 09:03 celeron55 frankly 09:04 MTDiscord Thanks and I agree....I'm absolutely not trying to protect any criminals on my server...but I will only act after I see actual evidence for such claims. And insulting me ingame and in the forum to be a pedo protector just because I don't ban someone who may or may not be a child lover will of course result in temp bans 09:04 celeron55 not worth it if they weren't in the same country as yourself or they are a kid though 09:06 celeron55 well i have no reason to believe you, but i have even less reason to believe that forum thread, lol 09:07 celeron55 it's the internet after all 09:07 MTDiscord L-Dog is no kid btw, he's an adult...this could explain why he tries to be so overprotective 09:09 MTDiscord But what shocked me the most is that other completely unrelated people came into that thread somehow just believing him and even posting police report sites...that's a bit much 09:11 celeron55 my estimate is 50% of people are idiots 09:12 celeron55 i also believe the police know that so i wouldn't worry too much about those reports 09:13 MTDiscord He also posted directly in the thread of my server as well by the way...not sure if I should report those posts too 09:16 celeron55 well i searched "child" and "girl" from his posts and no other thread popped up 09:18 MTDiscord Nah I think what he posted in the server thread so far isn't as critical as the contents in that other thread...should he decide to repeat the same stuff in my server thread though then I will report the posts 09:19 MTDiscord Unless his posts include some evidence finally 10:47 erlehmann my estimate is 50% of people are idiots 10:48 erlehmann low-balling it here right? :D 10:48 erlehmann i also believe the police know that so i wouldn't worry too much about those reports 10:50 erlehmann i haven't read the thread (and don't intend to), but for anything involving police, my first advice is: get a lawyer 10:50 erlehmann also don't talk to the police beyond identification and asking for access to your lawyer 11:01 erlehmann IhrFussel also it is a good idea to have offsite backups (i.e. where you can't easily get to and others won't find it) in case some fun-hater wants to take the server down or harass you. 12:18 independent56 hello! i will be more active over these 10 days, because someone i sat next to in school tested positive, and i have to "self-isolate". what fun! 14:09 independent56 /join #cachet 14:09 independent56 fuck 14:10 rubenwardy no swearsies, this is a christian minecraft server 14:47 independent56 XD 14:48 MTDiscord "This server is christian, but none of the players or admins are. We're honestly not sure how it ended up that way." 14:53 MTDiscord "... or how its supposed to end." 16:23 entuland does the content DB automatically pull new releases from GitHub? 16:23 MTDiscord yes, if you've set it up to use tags 16:25 entuland you mean if I set my entry in the content DB to use tags? I am logged in and I can't see any setting for that 16:25 entuland ah wait, I was looking in the wrong place 16:27 entuland uhm... I have the VCS Repository URL set up, seems like at least one release got pulled automatically, I'll give it some time and see if it will pull today's one automatically 16:29 rubenwardy entuland: https://content.minetest.net/help/update_config/ 16:29 rubenwardy You can set ContentDB to make a release for every commit or every tag 16:29 rubenwardy there's also an API or webhooks 16:30 MinetestBot 02[git] 04Wuzzy2 -> 03minetest/minetest: Fix some typos in builtin (#11370) 13b28523b https://git.io/JnPXb (152021-06-21T16:30:29Z) 16:31 entuland aye, wasn't set up properly 16:32 entuland probably I only updated the content DB manually and I forgot about it 16:53 GNUHacker servers admins have a serious problem, the modified clients 16:57 specing ohno 17:49 specing GNUHacker: Why is that a problem? 17:50 rubenwardy cheat clients, I'd guess 17:54 specing GNUHacker: what kind of cheats are a problem? 17:55 specing Minetest (other than rubenwardy's CTF server) isn't really a competitive game in the traditional sense 17:55 rubenwardy there are quite a few PvP servers though 17:55 Pexin many people treat mt as a 'platform' to customize a game experience per-server 17:56 Pexin also there are multiple types of competition, not necessarily combat 17:56 MTDiscord I've had a couple of cheat clients connect to my server but mostly they just got frustrated and left when they discovered that nobody was impressed. 17:56 MinetestBot 02[git] 04Wuzzy2 -> 03minetest/minetest: Update builtin locale (#11371) 137fdbf3f https://git.io/JnPAj (152021-06-21T17:55:55Z) 17:56 MinetestBot 02[git] 04neoh4x0r -> 03minetest/minetest: Strip carriage returns from lines in settingtypes.txt (#11338) 139d2e7fc https://git.io/JnPxv (152021-06-21T17:55:48Z) 17:56 MinetestBot 02[git] 04bensuperpc -> 03minetest/minetest: Update Dockerfile and improve build speed (#11313) 134b9a51f https://git.io/JnPxf (152021-06-21T17:55:38Z) 17:57 GNUHacker specing: cheat clients :/ 17:57 specing Pexin: and so the only people cheated out of that experience are the cheaters themselves? 17:57 specing GNUHacker: be more specific, please 17:59 Pexin having said that, I hate hate #9315 or at the least use a more lenient priv than debug.. -_- 17:59 ShadowBot https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2 18:00 rubenwardy `basic_debug` is used to show things like position and such 18:00 rubenwardy `debug` is wireframe 18:00 rubenwardy PR desc is outdated 18:00 Pexin hm 18:01 MTDiscord Heh, it now means "require A debug priv, not THE debug priv" 18:01 Pexin on our server we "compete" by building better stuff, and having easy access to coords becomes kinda important 18:01 MTDiscord If you want players to have access to coords then grant them that access 18:02 MTDiscord It will be nice though to make cheats an "opt-in" only feature though. 18:02 MTDiscord at least, the built-in cheats, even if we can't prevent hacked clients. 18:02 rubenwardy Pexin: then grant basic_debug 18:03 MTDiscord tbf we'll have to get this merged first and then folks will need to update and THEN grant the priv. Unless someone either modifies the database directly or registers the priv preemptively with a mod. I don't think you can grant a priv that's not registered. 18:14 sfan5 wait isn't that technically a breaking change 18:15 rubenwardy I don't think that debug info should count as part of the "API" used to determine breaking changes 18:15 rubenwardy but it could be mitigated by making it a default priv perhaps 18:15 rubenwardy although, that only applies to new accounts 18:16 MTDiscord https://xkcd.com/1172/ 18:16 sfan5 this is also bad because it will hide debug info on older servers with no way for server owners to grant it 18:16 rubenwardy then can register the priv themselves though? In a mod 18:16 MTDiscord what do you mean "now way?"? 18:17 MTDiscord They should be able to grant it once the change is in 18:17 rubenwardy Well, one way around this would be to make it a hud flag 18:17 MTDiscord they'd only need the mod if they want to grant it preemptively so they don't forget at upgrade time 18:17 rubenwardy you can then use on_grant etc to tie it into a priv 18:17 MTDiscord I think the HUD flag idea was explored but didn't get this far. 18:17 rubenwardy but this would be inconsistent 18:19 sfan5 @Warr1024 but how do you grant it on a 5.4 server? 18:19 sfan5 like ruben said you can only insert another mod 18:19 MTDiscord The priv would only be needed on 5.5+ (or 5.6 if it doesn't make freeze I guess) so why would I need to grant it on 5.4? 18:19 rubenwardy the hud flag could be on by default 18:19 sfan5 because you have people using 5.5 clients? 18:20 MTDiscord Oh, 5.4 clients I assume wouldn't honor the setting and would just unconditionally show the debug info 18:20 sfan5 that is the reverse of the problem I'm trying to explain 18:20 MTDiscord Oh, 5.5 clients on a 5.4 server? 18:20 rubenwardy correct 18:21 MTDiscord Sure, a mod would work. Or it could be registered with builtin in a 5.4.2 or something. 18:21 rubenwardy 5.4.2 wouldn't help as that's still a new release 18:21 MTDiscord really it seems like a '/grant -f' option might make sense to allow server owners to grant unregistered privs in anticipation of them being registered later anyway. 18:22 MTDiscord So what is your proposed alternative? 18:22 rubenwardy A hud flag like enable minimap makes sense, it would be on by default which would fix support with 5.4 servers 18:23 MTDiscord Dont hud flags make more sense in the context of modding APIs anyway? 18:23 rubenwardy yeah definiteyl 18:23 MTDiscord What would that flag be though? "Require priv for debugging info" or "disable debugging info" and do the priv check server-side? 18:23 rubenwardy no 18:23 rubenwardy like enable minimap, it would disable the basic debug info 18:23 rubenwardy the flag doesn't know about the priv 18:23 rubenwardy The priv in builtin can use on_grant/revoke/join to set the hud flag. Mods can override the priv by unregistering it 18:23 rubenwardy or just setting in joinplayer after builtin 18:23 MTDiscord Okay, well, you'd have to look back at the previous PR and the discussion on the original issue to see why that idea was rejected when it was explored. 18:24 MTDiscord If whatever was concluded is wrong or no longer applicable then I guess we'll have to revive that line of inquiry 18:24 rubenwardy > “Why not using HUD flags?”. HUD flags are controlled by mods. This implies that mods can screw around with the debug info at will. All it takes is one poorly-coded mod to strip away the extended debug info from the admin, which is not fun to track down. Privileges, by comparison, are much more reliable and predictable and there are no ugly surprises. 18:24 sfan5 that's pretty weak argument 18:24 rubenwardy yeah I agree 18:24 MTDiscord At this rate though I'll have retired before we figure out how to actually get anything merged. 18:24 sfan5 0.3.1 had no Lua mods so logically mods can't mess anythin up 18:24 sfan5 QED 18:25 MTDiscord Was "mods can control" this really the reason to reject that? 18:25 sfan5 ¯\_(ツ)_/¯ 18:25 MTDiscord I thought having mods/games/servers able to control debug features was the whole point of this thing 18:26 sfan5 doing :set_hud_flags({minimap = false}) doesn't touch all other flags, does it? 18:26 MTDiscord Is this Warr? ? 18:26 MTDiscord https://cdn.discordapp.com/attachments/749727888659447960/856600943214985216/0vva3sr4pnq61.png 18:26 MTDiscord haha 18:26 MTDiscord Lol, nice 18:26 MTDiscord I seriously doubt that story because there's never JUST ONE bug. 18:27 rubenwardy Wuzzy ^ 18:28 MTDiscord I think the mod-controlled flag thing makes sense to me and would suit me fine. I would like NodeCore to be able to disable by default the debug info, but allow server owners and singleplayers and such to be able to override that should they choose. I am also fine with people creating mods that override it. I just want the DEFAULT experience when playing the game to be what it should be. 18:28 Pexin what it should be? 18:28 MTDiscord I have instructions in the "new player guide" to set certain settings or do or don't do certain things, and that makes for a bad experience. I'd rather the game just do what it's supposed to do by default, so that players realize clearly that they're changing something when they play a different way. 18:28 Wuzzy Why was I summoned? 18:29 rubenwardy we're discussing #9315 18:29 ShadowBot https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2 18:29 sfan5 the reason for not making the basic debug thing a HUD flag was considered insufficient 18:30 MTDiscord Where was that comment about the HUD flag thing from anyway? 18:30 rubenwardy PR OP 18:30 Wuzzy so can i consider my PR to be rejected? 18:31 sfan5 no? 18:31 MTDiscord one issue and 2 PRs, each with a massive thread... wow, that's a lot to dig back through. 18:32 rubenwardy this is very much our fault for dropping the ball on this 18:32 ZftxqBQjXIqw Li83raChAT aIN't new fr33nod3, y0u'r3 mislED 18:32 MTDiscord It looks like I actually advocated it to be a HUD flag that defaults to on (I think minimap and zoom are like that?), with the ability for a game/mod to turn it off, and then a priv to force it back on... 18:32 rubenwardy I see the basic_priv working like this when a hud flag is added: https://gist.github.com/rubenwardy/a64eeb55b1f4ae8d7d8e630e5a00c2cc 18:32 rubenwardy *basic_debug 18:32 rubenwardy if you still want the basic_debug priv 18:33 sfan5 having a priv would be useful to avoid having to install a mod to make it work 18:33 rubenwardy yeah 18:33 Wuzzy uhhhh are we STILL arguing the HUD flag thing? nooooooooooooooo, i thought this was settled. :( so frustrating 18:33 sfan5 but for compatibility and internal reasons it has to be a hud flag 18:33 rubenwardy a mod can then do minetest.registered_privileges["basic_debug"] = nil to unregister the priv, and control the hud flag without conflict 18:34 MTDiscord Yeah, I think it was settled for you that a HUD flag wasn't what you wanted but I don't think other people accepted the issues you had with it, Wuzzy... 18:34 rubenwardy well, or just only set it to true - then basic_debug would be used for admins to have it regardless 18:34 sfan5 by the way on_grant and on_revoke are broken 18:34 rubenwardy they get called twice but should work 18:35 Wuzzy i really really do NOT want a hud flag. its debug for crying out loud, not a gameplay thing 18:35 sfan5 they don't do what you need if multiple privs are revoked or granted at the same time 18:35 rubenwardy I can't see any issues about on_grant 18:35 MTDiscord Well, it is a gameplay thing as it currently stands 18:35 sfan5 Wuzzy: the debug information absolutely relates to gameplay or else we wouldn't have this whole issue and showing coord would be fine 18:35 MTDiscord We get that you don't want a HUD flag but I don't think you've made your case why it needs not be. 18:36 sfan5 rubenwardy: okay actually it should work for this 18:36 sfan5 but let me illustrate why it's broken 18:36 Wuzzy yes. NOW it relates to gameplay. ripping out the gameplay out of the debug screen (by default) is the whole point of this issue, so that it is gameplay-free in the future without privs 18:37 MTDiscord You mean you want to change the default behavior to opt-in. 18:37 MTDiscord I could get behind that too, tbh, but we still need to make sure there's a smooth migration path or there will be a lot of noise about this change... 18:38 MTDiscord but I don't see a way to smoothly change the default external behavior without doing it across 2 releases 18:38 Wuzzy If you need ANY mods to make debug screen work, that's a terrible TERRIBLE way to go forward. any bad mod and you can't access the debug screen anymore. this is absolute madness. debug should never work like this 18:38 MTDiscord and IIRC this thing missed at least 2 releases already... 18:38 Wuzzy oh that's nothing 18:38 MTDiscord I think what's being suggested here is that it should require a mod or game to make the decision to remove existing info from the F5 screen, and then they can use privs to restore it for selected playres. 18:38 Wuzzy we have PRs far older than that 18:39 sfan5 "any bad mod and you can't access the debug screen anymore" and? 18:39 sfan5 mods can break just about everything 18:39 sfan5 why is this and exception? 18:39 sfan5 an* 18:40 rubenwardy HUD flags can be on by default, and you can have the priv in built-in anyway 18:40 Wuzzy are you serious? its the debug screen. that's the ONE thing that should work reliably in minetest. debugging mods would be the absolute nightmare if you cant even rely on the debug screen anymore 18:40 MTDiscord Not trusting mods with privileged system access, network connections, etc. as per mod security is one thing, but not trusting them with gameplay-affecting decisions is entirely another. 18:41 MTDiscord The debugging screen already doesn't work if you introduce a crash-on-startup bug into a mod. 18:41 Wuzzy mods should have zero say in how the debug screen looks imo. if we let mods start to mess with the debug screen, this is going to make things extremely painful for modding/game making. 18:41 Wuzzy also, games should just use hud_add if they want coordinates back 18:41 MTDiscord If you introduce a "makes the debug screen not work anymore" bug into a mod then yeah, you'd want to remove that same as you would an instant crash. 18:41 MTDiscord I think we are missing the clarification on what exactly is "debug" and what is not? 18:41 sfan5 we don't seem to be talking about the same thing 18:41 Wuzzy this is a type of bug that should not even be possible 18:42 sfan5 if "mods should have zero say on the debug screen" then Minetest already has this feature 18:42 Wuzzy yes 18:42 Wuzzy but you want to convince me to change that. WHY? 18:42 MTDiscord So if you were against this feature then what was your motivation for making a PR for it anyway? 18:42 sfan5 no you don't understand 18:42 sfan5 the coordinates are always displayed in the debug screen and mods have no say in that 18:43 sfan5 and you are saying "yes" to that 18:43 Wuzzy because its true 18:43 MTDiscord I don't see how a priv prevents mods from controlling debug info with the PR the way it is anyway. You are talking about using a privilege to prevent mods from messing with it as if mods can't just grant/revoke privs. 18:43 sfan5 uh uhm 18:43 sfan5 are you aware that mods can revoke privileges? 18:43 Wuzzy i want to remove coords and seed from debug screen unless you got priv. so games can decide whether theyy want to expose coords on their own (with hud_add, etc) 18:44 MTDiscord Yes, that's the whole point here 18:44 sfan5 but games don't decide privileges either 18:44 sfan5 server admins do 18:44 MTDiscord Are you trying to create some kind of differentiation between games and mods? 18:44 Wuzzy mods/games revoking privs is rather rare tho 18:44 MTDiscord Why am I getting the feeling that this thing has been open for so long that Wuzzy can't even remember why he got involved in the first place :-) 18:45 sfan5 having a "bad mod" that hides debug info is just as rare 18:45 Wuzzy this doesnt justify hud flag 18:45 MTDiscord No, mods that hide debug info are far more rare than mods that affect privs :-) 18:45 sfan5 correct 18:45 sfan5 there are other arguments that justify the hud flag 18:45 Wuzzy but priv is so much simpler for admin 18:45 MTDiscord Mods that affect privs for something other than privs' sake usually do so because they want to control something that is only controllable via privs 18:46 Wuzzy with hudflags admin is FORCED to install mod 18:46 MTDiscord Without HUD flags admin is FORCED to install mod if they want the defaults the other way 18:46 sfan5 having a priv would be useful to avoid having to install a mod to make it work 18:46 sfan5 but for compatibility and internal reasons it has to be a hud flag 18:46 MTDiscord we either force them to use a mod to remove stuff from F5 or force them to use one to re-add it back. 18:46 Wuzzy what compability and internal reasons?? 18:46 MTDiscord While I agree that the latter is cleaner in the long run, I don't think people are willing to go through that pain. 18:47 MTDiscord Quite a few mods manage privs in order to control fly/fast/noclip and more in realtime...I do that for example to make 'fair zones' on the map where I don't want my players to have certain privs else it would be unfair/too easy 18:47 Wuzzy forcing me to install a mod just so i can see coords in debug is absolute madness. this is unacceptable 18:47 MTDiscord Wat 18:47 MTDiscord that's what we were just saying 18:48 sfan5 if you have a 5.4 client connect to a 5.5 server the debug info will be hidden unless the server admin installs a mod to add the privilege (that doesn't exist yet in 5.4) 18:48 MTDiscord If we use the HUD flag then we have a way to default coords to on so that the system continues to behave the way it did before by default and there are no surprises. 18:48 MTDiscord If we rely on a priv being granted then that means that anyone upgrading will have to grant that priv to anyone they DON'T want to have a sudden change in behavior 18:49 MTDiscord shouldn't a 5.4 client work fine? 18:49 MTDiscord that's not an insurmountable problem but it's very error-prone and many server owners will probably miss the announcement. 18:49 MTDiscord since they would ignore the extraneous privs 18:49 Wuzzy sfan5: sounds like you just gave an argument against hudflags 18:49 sfan5 uh no? 18:49 sfan5 hudflags can default to enabled no issue 18:49 MTDiscord We do need to also consider the case of 5.5 clients on 5.4 servers and 5.4 clients on 5.5 servers, insofar as that there's anything we can do for them at all. 18:49 sfan5 privileges that do not exist cannot default to on 18:49 Wuzzy wait, what? 18:49 rubenwardy sfan5 meant 5.5 client on a 5.4 server 18:49 sfan5 oh yea 18:49 MTDiscord if the server has the fix but the client does not, the client will still show debug 18:49 sfan5 sorry 18:49 Wuzzy how? 18:50 Wuzzy since when do clients have to know about "legal privileges"? 18:50 MTDiscord They can't 18:50 Wuzzy dont clients just get a list of strings or whatever? 18:50 rubenwardy 5.4 doesn't have the privilege, so the 5.5 client will never be able to show the basic_debug 18:50 rubenwardy unless you install a mod to add the privilege 18:50 MTDiscord you could use a protocol version check 18:50 sfan5 how would a client differentiate "the server knows this priv and I don't have it" and "the server doesn't know this priv"? 18:50 rubenwardy HUD flags can default to true, client-side, fixing this 18:50 Wuzzy wait. do you want to maintain 5.4<--->5.5 compability? 18:51 MTDiscord To use a protocol version check we'd have to start actually being a little consistent about bumping the protocol version when there's a change to the MEANING of data over the wire, not just the format. 18:51 MTDiscord yeah, otherwise this would be 6.0 18:51 Wuzzy darn it!!! 18:51 Wuzzy This is why we can't have nice things. 18:51 MTDiscord Unfortunately we will already have 5.5-dev clients connecting to 5.4 servers. 18:51 MTDiscord eeh we got shadows 18:51 sfan5 dev is irrelevant here 18:51 rubenwardy A protocol version check to not expect basic_debug would work 18:51 MTDiscord We CAN have nice things, it's just gonna take a little work. 18:51 MTDiscord Oh dont worry, there are plenty more reasons why we cant have nice things 18:51 MTDiscord those are a nice thing 18:52 MTDiscord I personally am in favor of bumping the protocol version if that's an option :-) 18:52 sfan5 @Warr1024 protocol version is consistently bumped when compatible changes to the packets cannot be made reasonably 18:52 Krock are we talking about taking away helpful debug information from the clients? 18:52 Wuzzy so. since the only reasonable solution (privs) breaks compability apparently, this means my PR has to be delayed till 6.0 then ... :((((((((((( 18:52 rubenwardy also, dev discussion in #minetest. Classic 18:52 MTDiscord it gets bumped way to rarely as it is, making it very hard to know whether you can rely on certain features on the client from the server-side. 18:52 sfan5 why bring this up though? protocol version does not need to be bumped 18:52 sfan5 Wuzzy: it is perfectly possible to create a compatible solution with hud flags that ALSO does not force you to install a mod to get the info back 18:53 Krock it only needs to be bumped if you want to force clients to update by locking old ones out 18:53 MTDiscord Bumping proto version would be a way to allow 5.5 clients to know that a server is 5.4 and wouldn't know about basic_debug. 18:53 Wuzzy here is what i want: 18:53 Wuzzy 1) unprivileged players dont get free coordinates 18:53 MTDiscord sfan5: I also have a separate reason to want to see proto version bumped more: we don't have other version tracking that a server can use to tell what features a client supports. 18:53 Wuzzy 2) privileged players CAN get free coordinates on the debug screen 18:54 MTDiscord what we're saying is that for compatibility reasons stuff should default to true, which it won't with privs 18:54 MTDiscord For example, we might have minetest.features flag or something for "entity attachment supported" but it doesn't tell me which of the like 3 or 4 generations of attempts to fix it are actually in use on the client-side, and I may only want to actually use it if I know that not only will the client support it, but that it will actually work and not be buggy as hell. 18:54 Wuzzy sfan5: so basically i can throw my entire PR away and have to start from scratch. great ... 18:55 sfan5 the features flag is server-side anyway 18:55 rubenwardy well, the protocol check could be a simple alternative 18:55 rubenwardy it depends on whether you think that control should lie with server owners or games 18:55 MTDiscord All I want is (1) my game to be able to disable coordinates by default, (2) owners to be able to override this if it makes sense for them, and (3) the damn thing to actually stand a chance of getting merged, whatever other needs need to be appeased to allow that. 18:56 MTDiscord sfan5: might be a separate issue in my case, I'm USUALLY more interested in knowing client feature support from the server side than the other way around. 18:56 Krock never trust the client tho 18:57 MTDiscord I've already proposed that the protocol version be bumped at least once per release just to ensure that we can reasonably differentiate between whole releases, which was seemingly accepted, and then ignored for one release, and then now is thrown back into dispute. 18:57 rubenwardy the client doesn't really have any motivation to lie, except for downgrade attacks 18:57 Krock ^ right 18:57 MTDiscord The purpose of interrogating the client is to find out what the client would want to offer it the best experience. If it wants to lie to me then there are easier ways for it to degrade its own experience. 18:59 Wuzzy So how WOULD the apparent HUD flag work, then? 18:59 Krock > offer it the best experience | hiding information in the client does not seem like better experience 18:59 MTDiscord Also, "never trust the client" is a little ironic to be thrown about in the context of a game engine that trusts the client with all player movement and has very limited ability to validate it... :-D 19:00 MTDiscord Hiding information in the client is ABSOLUTELY the experience improvement I want to make. 19:00 Krock right. that was not thought through well 19:00 Wuzzy Krock: the MAIN point here is about stop giving coords FOR FREE to all players by default 19:00 MTDiscord I really get tired of players asking me about some internal object names that confuse them and then I have to inform them that they just accidentally cheated and now they've been spoilered. 19:00 MTDiscord Letting the client control information just contributes to Minetest's identity crisis of "to engine or not to engine" 19:01 sfan5 rubenwardy: https://0x0.st/-9wR.txt do you see the issue? 19:01 MTDiscord Minetest is like something that wants to be a game creation engine but can't actually make the transition from creation to created. I can make a game in MT but players are always treated as if they're devs who are supposed to be debugging the game. 19:02 rubenwardy sfan5: as in, incorrect get_player_privs due to call order? 19:02 sfan5 correct 19:02 sfan5 there is no consistent privs view 19:02 sfan5 this has caused me major pain when writing something that is automatically enabled when you have both fly + fast 19:03 MTDiscord oh, you mean the hooks fire at nonsensical times? 19:03 MTDiscord Sadly I'm sort of used to minetest.after(0, function() ... end)ing so many things... 19:03 sfan5 Wuzzy: you'd have a hud flag that shows the coords, it defaults to on; you also register a priv (just like now) that syncs with the hud flag by default *but* mods/games can unregister 19:03 Krock Wuzzy: as long the information is still shown by default it's okay for me. I don't see much point in hiding it, but if modders want that, then it should be added as a HUD flag true/false 19:04 * Pexin huggles Krock 19:04 rubenwardy #11372 19:04 ShadowBot https://github.com/minetest/minetest/issues/11372 -- Inconsistent get_player_privs in on_grant/on_revoke callback 19:05 sfan5 s/unregister$/unregister this/ 19:06 Wuzzy i dont get it. hud fflag AND privs? sounds complicated and probably overkill 19:07 Wuzzy wait. so you want the default debug screen to have coords still, but with games having the option to remove the coords from debug screen? 19:07 Krock is there any priv that currently modifies the UI? 19:07 Wuzzy yes 19:07 Wuzzy debug 19:07 sfan5 yes, the default behavior should not change 19:07 Krock ah right, wireframe. 19:07 Wuzzy but when a game disables the coords, this means admin can't see coords as well!! ? 19:08 Krock HUD flags are player-specific, and so are privs 19:08 MTDiscord Games are just going to have to be responsible enough to allow admins to admin. 19:08 Wuzzy wait.... 19:08 sfan5 if the game does that for all players that's an issue with the game 19:08 Wuzzy do you mean the priv can be used to overwrite the game's decision?? 19:08 MTDiscord If you are trying to run a game on your server and the game dev is fighting against you doing your job then frankly you should probably just not use that game :-) 19:09 MTDiscord Priv overriding the hud flag would also be just fine to me. 19:09 Wuzzy argghh this MTDiscord user is so irritaing to read in my chatlog :/ 19:09 specing hiding coordinates is just wacky 19:09 Wuzzy i wish i had a tool to pretty-print that 19:09 sfan5 the idea was that games can unregister the privilege so that's pretty much identical 19:09 specing imagine the amount of bug reports opened by people reporting that F5 no longer shows coordinates 19:09 Wuzzy specing: ........... sigh. here we go again ... 19:10 sfan5 does your IRC client not support scripts? 19:10 MTDiscord I think the game should be responsible for honoring the priv, or at least providing its own mechanism, but if you want a more powerful override, that's fine to me... 19:10 Hawk777 Does the 5.4/5.5-mismatch privileges problem actually matter all that much? If the privilege option were used, only a 5.5 client connecting to a 5.4 server would unexpectedly lose access to debug info (but not any other combination), *and* if the server admin cared enough then it is *possible* to work around it (by installing a mod that allows the new privilege to be granted in the older version). 19:10 specing sfan5: modified clients are not allowed. You are supposed to enjoy MTDiscord being annoying as intended 19:11 MTDiscord Just be glad it's not as much of a mess as the MT -> IRC -> Discord -> MT bridge I've had to deal with elsewhere. 19:11 Krock Hawk777: from what I can see is it about somehow dealing with old clients as soon the feature is merged 19:11 Wuzzy yeah i probably need a script to pretty-print MTDiscord's msgs 19:12 MTDiscord Blame IRC for not having API to display it any other way 19:12 MTDiscord At least on the Discord side you guys look like regular users because Discord lets us do that 19:12 Hawk777 What’s the problem with old clients on new servers? They would (maybe) see an extra privilege, not care about it, and still show debug info. No change in behaviour. 19:12 rubenwardy new clients on old servers 19:13 sfan5 I wouldn't call renaming the bridge bot on every message "discord lets us do that" 19:13 rubenwardy This problem could be simply fixed using protocol versions though 19:13 MTDiscord We dont rename the bridge bot 19:13 rubenwardy it uses webhooks to create users with custom names 19:13 rubenwardy no renaming 19:13 Hawk777 Yes, that was my point. New clients on old servers would lose access to debug info (*NOT* completely break, just that one single feature), *and* if the server admin cared enough then they could re-enable it by adding a mod that knows about the new privilege. 19:13 MTDiscord and custom avatars 19:13 Hawk777 It just doesn’t seem like a huge impact. 19:13 rubenwardy yeah and again has a simple fix 19:14 rubenwardy I think it comes down to whether you think this should be a server-owner determined thing, or more game controlled 19:14 rubenwardy and whether you want it by default or not 19:14 sfan5 https://0x0.st/-9wC.png doesn't look like no renaming to me 19:14 MTDiscord Webhooks display with a bot tag 19:15 sfan5 the name 19:15 MTDiscord I don't think "controlled" is the right way of thinking about it. The server owner controls everything, including the game, because if they don't like something the game is doing then they can just take a hammer to it. We should mostly be trying to make it so they don't feel like they have to though. 19:15 Wuzzy rubenwardy: is it possible for the client to catch priv changes? thats kind of important for the bugfix ... 19:15 sfan5 I am hovering over "Hawk​777" 19:15 MTDiscord The preview also changes 19:15 sfan5 and it says sfan5 19:15 MTDiscord If the bot was renamed, the Hawk777 in chat would change too 19:15 rubenwardy Wuzzy: the client must be told about priv changes, because it knows about privs to enable eg fly 19:15 MTDiscord Just because a server owner MIGHT want to configure something explicitly doesn't mean that a game or mod should NOT have the ability to set a default for when the server owner doesn't want to override. 19:15 sfan5 I can only conclude that discord is broken then 19:15 Wuzzy great 19:15 MTDiscord I absolutely want to be able to set the default behavior for F5 debug info as a GAME publisher. 19:15 MTDiscord You know what, no commet 19:16 MTDiscord comment* 19:16 MTDiscord I can splel 19:16 Wuzzy I am so frustated by the dact that Discord basically took over the world of chat ? 19:16 Wuzzy why do the proprietary assholes always win???! the world is not fair! 19:16 MTDiscord It's not a take-over, it's just an expanded audience. IRC is still around, Matrix is still fine, and I'm on all of them to some extent or other. 19:17 MTDiscord Anyway, now I know there are at least 3 hidden core devs lurking on Discord ;p 19:18 MTDiscord If we just settle on "F5 coords should be server-controlled" then I as a game publisher don't have any way to advise server owners that they should turn off coords by default other than having to contact each server owner and tell them how to setup their config. 19:18 MTDiscord With SP it's even worse then because each individual player is a "server owner" of their own. 19:19 Wuzzy let me summarize the plan ... 19:19 Wuzzy 1) default behavior is the same as before 19:19 Wuzzy 2) hud flag to disable gameplay info from debug such as coords 19:20 Wuzzy 3) priv to overwrite the hud flag and get the full debug screen anyway (for admins, etc.) 19:20 Wuzzy is this correct? 19:20 rubenwardy that's correct if the hud flag approach is decided on 19:20 MTDiscord by "overwrite" you mean "override" as in "ignore the flag if they have the priv" or do you literally mean "overwrite" as in "having the priv changes the flag value"? 19:20 rubenwardy an alternative is to just add a protocol version check to fix 5.5 clients on 5.4 servers 19:21 rubenwardy Warr1024: latter 19:21 rubenwardy there really needs be a consensus soon though 19:21 Wuzzy rubenwardy: i hope i can figure out how to "catch" the hudflag change in the client then ... to fix ur bug 19:21 MTDiscord Okay, just wanted to clarify. Thinking about it more, that point doesn't really affect my response; if it works and passes review and testing then I would support it. 19:21 Pexin meek question: what are arguments against protocol check? 19:22 Wuzzy none 19:22 rubenwardy loss of game control, harder to make it enabled by default 19:22 MTDiscord I think the argument against protocol check is one about purity of the terminology, i.e. that they only want to bump the protocol version when there's an actual change to the protocol. 19:22 rubenwardy which are two things people disagree on 19:23 Pexin does it make it harder to enable by default? 19:23 rubenwardy you can add the priv to default_privs, but that only effects new players 19:23 Pexin ah 19:24 rubenwardy there's no way to add a priv to all existing users currently without making it irrevokable 19:24 MTDiscord MT does not have a way to differentiate between privs a player doesn't have because they're not supposed to, vs. privs they don't have because that priv didn't exist before. It would not be impossible to add that ability, but I doubt it would be worth the mess. 19:24 Wuzzy rubenwardy: ??? 19:24 rubenwardy Although, the hud flag approach probably has the same problem 19:25 Wuzzy rubenwardy: thats only true if you give it by default 19:25 rubenwardy as the priv messes it up and has the exact same behaviour 19:25 MTDiscord The HUD flag at least allows us to avoid the irrevocability issue though 19:25 Wuzzy if you dont give a priv by default it is revokable 19:25 rubenwardy yes, but you can't give it to all existing users without a migration, which we don't currently have any means for 19:25 rubenwardy or perhaps you could write a mod and store a flag in player meta 19:25 rubenwardy which would be a mod way of enabling by default 19:26 sfan5 could also invert the meaning of the priv 19:26 MTDiscord The HUD flag allows us to have (1) something that can be freely enabled/revoked, (2) something that can be on by default, and (3) something that's sensible from an API perspective, i.e. not having "unprivileges" as privileges. 19:26 MTDiscord inverting the meaning of the priv makes /grant all work funny. 19:26 sfan5 would still leave the issue of games not being supposed to control privs on their own 19:26 rubenwardy that breaks the priv system though - a priv should only add an ability, not take it away 19:26 sfan5 (it'd be a sign of inflexibility) 19:26 sfan5 rubenwardy: creative takes away the ability to play in survival mode ;) 19:27 rubenwardy I also hate the creative priv, it never should have been added 19:27 MTDiscord haha, well, "fly" priv takes away the ability to be unable to fly ... but the fact that "/grantme all" would actually take away abilities would be a mess to deal with. 19:27 rubenwardy a gamemode priv and `/gamemode creative` or `/creative` doesn't have that issue 19:27 sfan5 games are free to unregister the creative priv I think 19:28 MTDiscord "creative" in its entirety seems like something that should be entirely game-driven, not in builtin or engine at all. I've had to rip out some creative-mode stuff in NodeCore. 19:28 MTDiscord The priv system is sort of messed up to begin with ... privs should really only be connected to API features that enable/disable features. Like fast should be a physics flag or something that the priv controls. That way game and admin control is unified. 19:28 MTDiscord It's fine though; I'm much less worried by something that requires a workaround than something that can't be worked around. 19:28 MTDiscord Have 2 accounts, use 1 for craetive/admin stuff and the other for survival?.. 19:29 MTDiscord Once upon a time MT was a game. Now, it aspires to be an engine ... but there's still a lot of "game" stuff left in that would have to get migrated over, and there's always a question of where to stop. 19:30 MTDiscord It probably seemed obvious at some point in the past that "creative mode" should be a sub-game-mode that exists within each game ... but probably now that's less obviously true. 19:30 rubenwardy with a HUD flag, you can make it so that the priv enables it but it's redundant unless a mod disables it, perhaps 19:30 MTDiscord Enabling something that's already enabled doesn't sound like a problem to me :-) 19:31 rubenwardy But there's still the question of whether it needs to be enabled by default, I think it's fairly useful by average users to have positions available for debugging 19:33 MTDiscord It's all fine as an academic debate I guess but unless we come up with and agree to a better plan, I'll continue to back the one Wuzzy outlined above. Even if it's not theoretically perfect, if we can start being able to make this sort of change now, then we should also start being able to correct things later if it turns out we could have done them better. 19:33 MTDiscord We've got enough different kinds of flags with overlapping functionality and subtlety of meaning that we could bikeshed this indefinitely if we wanted to. I'd rather see the feature see the light of day, enable some interesting challenging gameplay where it's used, and see how it behaves out in the field. 19:34 MTDiscord If people are going to file MT issues about "why are debug coordinates missing" because a game decides to disable them then you'd already be seeing plenty of "why can't I chop down a tree" bug reports from NodeCore anyway. 19:35 rubenwardy This feels like a big mess, which probably indicates that the design is wrong 19:36 MTDiscord Youve just described Minetest as a whole 19:36 MTDiscord More like software as a whole 19:37 MTDiscord Isnt it possible to hide the debug info from nodecore only? 19:37 Pexin kinda feels like part of the issue is there are different expectations of how responsible and attentive individual game admins are 19:37 MTDiscord If I wanted to get the design right first, I wouldn't have ever gotten around to writing a single line of code for NodeCore and there'd be nobody playing it today. 19:38 MTDiscord wwar: hiding the debug info in nodecore only is sort of what I want, but it wouldn't make sense to just add an "if game == 'nodecore'" test or anything. 19:38 MTDiscord I mean there should be a way to do this that's at least a little sane. 19:38 MTDiscord I see 19:39 MTDiscord But i think adding that even tho it makes less sense is better than people in nodecore being able to use it 19:39 MTDiscord Also if we start doing game-specific checks in the engine then (1) we introduce circular dependencies to the ecosystem at large, and (2) it'll get messy FAST. 19:39 celeron55 tl;dr about the debug coordinate thing? 19:40 MTDiscord I played some nodecore few days ago and noticed that debug info will do some..cheaty stuff 19:40 MTDiscord Wuzzy's plan will work fine for NodeCore, it sounds like it will work fine for games and servers that don't want to change anything, and I see on reason it shouldn't work for any other games that want to handle this differently either way. 19:41 Wuzzy celeron55: 19:41 Wuzzy let me summarize the plan ... 19:41 Wuzzy 1) default behavior is the same as before 19:41 Wuzzy 2) hud flag to disable gameplay info from debug such as coords 19:41 Wuzzy * logger56 has quit (Remote host closed the connection) 19:41 Wuzzy 3) priv to overwrite the hud flag and get the full debug screen anyway (for admins, etc.) 19:41 MTDiscord yeah, noticed that one, was wondering why didnt you already do it (and got the answer) 19:41 sfan5 games should have the ability to hide coordinates (and some other stuff) from debug info; the default behaviour should not change and server admins should have it easy to dis-/enable it without a mod 19:42 sfan5 proposed solution being what Wuzzy pasted 19:42 rubenwardy celeron55: the PR adds a privilege to show the position etc in the F5 debug info. The problem with this is: 1) 5.5 clients on 5.4 servers won't be able to enable the position 2) it's disabled by default 3) games don't have any/much control 19:42 MTDiscord Even if the game engine doesn't provide an override for the coordinate disabling, I would provide it at the game level anyway (and I would expect other games to do so as well) because server operators are part of my game's audience as well. 19:43 celeron55 how many games are there that rely on debug coordinates being available to anyone? 19:43 MTDiscord None, I hope 19:43 Pexin define "rely" 19:43 sfan5 but you wouldn't want to take them away by default would you? 19:43 celeron55 servers are not a problem, their owners can add the priv, but some games aren't maintained and users don't know how to edit them 19:43 celeron55 yes, i would want to take it away by default 19:43 rubenwardy there are two proposed alternatives: 19:43 rubenwardy A) Change to a hud flag, there would still be a priv to enable the flag. This is complicated 19:43 rubenwardy B) Keep a priv, use protocol version to fix 5.5 clients on 5.4. This would still take the info away by default and has no game controls, but there are workarounds 19:44 MTDiscord The concerns I think are (1) 5.5 clients on 5.4 servers would lose coords immediately until server operators either upgraded or hacked around the issue, and (2) a general "least surprise" violation. 19:44 sfan5 to be clear I don't have an issue taking it away by default if that's what we want to decide 19:44 sfan5 it just needs to be looked at 19:44 celeron55 and i like the privilege approach, the hud flag seems nonsensical 19:44 rubenwardy yeah, the priv approach is simpler 19:44 MTDiscord I'm good with taking it away by default 19:44 MTDiscord Why exactly do we care about audience reaction? It's a game update, things are supposed to change. 19:44 Wuzzy my initial solution was about taking it away by default but it was basically murded by the core devs in cold blood 19:44 rubenwardy In which case, we can release an official mod to enable it on 5.4 and by default 19:44 celeron55 it's the server owner's decision to grant the privilege if the server is used for debugging purposes 19:44 sfan5 what makes it different from the minimap though? that's not a hud flag 19:45 rubenwardy The minimap is a hud flag? 19:45 sfan5 not a priv* 19:45 rubenwardy ah 19:45 Krock on/off minimap is a hud flag, but there's also an API for it 19:45 MTDiscord (And again, HUD flags make more sense in the context of modding-- and games should have control over what gets displayed) 19:45 celeron55 if a game wants to show coordinates, god damnit just draw the coordinates 19:45 MTDiscord :-D 19:45 celeron55 using the debug info is abuse of the engine 19:45 celeron55 stop abusing my engine 19:45 rubenwardy I think the difference is that the minimap is 100% a gameplay feature, whereas the debug info is a debug feature that negatively impacts gameplay 19:46 sfan5 that's okay for a justification 19:46 celeron55 if coordinates drawn by a mod is too laggy or something, then add a hud item that shows the coordinates in real time that the game can add on the screen 19:47 celeron55 s/add/implement/ 19:47 MTDiscord Haha, yeah actually that makes sense. Dont split info from debug at all, just make the priv for it. Games can revoke it and display stuff manually. 19:47 rubenwardy well, sometimes it takes celeron55 a few minutes to resolve a debate that's been going on for an hour 19:47 MTDiscord I think we just sort of assumed that nobody would be okay with a change that radical. 19:47 rubenwardy yeah 19:47 MTDiscord Is it that radical of a change? 19:47 celeron55 i think someone already suggested this, whoever it was maybe listen to him next time 19:47 celeron55 he's faster than me 19:47 MTDiscord Having a benevolent dictator around has some real perks. 19:48 Wuzzy using the debug info is abuse of the engine <<<< I have trying to say that for YEARS but nobody wanted to listen ? 19:48 MTDiscord Hey benevolent dictator, can we have an explicitly defined direction for the engine to base changes off of? :] 19:48 rubenwardy Would you prefer using a protocol version check to enable the debug info on 5.5 clients with 5.4 servers, or requiring a mod for outdated servers? I prefer the former 19:49 rubenwardy The protocol version check would disable the need for a priv if the server is too old to have it 19:49 celeron55 i don't see a problem in using the protocol version for that 19:49 celeron55 it shouldn't cause any issues, right? 19:49 sfan5 I thought the answer to that too would be "it's okay if it disappears" 19:50 MTDiscord The only thing worse than a problem we can't solve because we can't find a solution is one we can't solve because we've got too many solutions, each of which could work just fine... 19:50 celeron55 well people appreciate the compatibility and we never know how long certains versions end up being used 19:50 celeron55 it pays to be careful 19:50 celeron55 certain* 19:50 sfan5 quick reminder that ubuntu and debian have still not packaged 5.4.x 19:51 Pexin I spoke with someone today who mentioned he needs 5.1.1 client for his game. obviously due to outdated mods. 19:51 MTDiscord I'm on Debian and you should be thankful that they've bothered to do 5.x.x at all. 19:51 MTDiscord sfan5: Stable or backports/testing? 19:51 sfan5 in any form 19:51 sfan5 testing/unstable whatever 19:51 MTDiscord Ouch 19:52 Pexin re ubuntu: don't they use snap for that? 19:52 MTDiscord Usually Debian's rolling repos are fairly up to date, with the exception that they prefer LTS releases for some stuff 19:52 rubenwardy also PPA for Ubuntu 19:53 MTDiscord Are there official Appimages yet? 19:53 MTDiscord Flatpak's MT was last I checked pretty recent, which was how I was running it on Debian for that period between my build scripts breaking due to the irrlicht fork and my finally getting them fixed. 19:53 MinetestBot 02[git] 04NeroBurner -> 03minetest/minetest: Move build/android directory to root of project (#11283) 13a7143c2 https://git.io/JnX3j (152021-06-21T19:51:42Z) 19:53 MTDiscord I don't remember whether it was 5.4.0 or 5.4.1 22:16 Swift110-mobile_ hey all 22:50 MTDiscord When was the "show block bounds" feature added? 22:50 MTDiscord like as in first release it did or will appear in... 22:51 MTDiscord 5.5-dev 22:51 MTDiscord @Warr1024 https://github.com/minetest/minetest/pull/11172 22:53 MTDiscord Okay, good, I was worried that it had been in there forever and I was just a dunce for never noticing. 22:54 MTDiscord by minetest terms is flew under the radar drama and action wise