| Time |
Nick |
Message |
| 00:23 |
|
mckayshirou joined #minetest |
| 02:25 |
|
queria joined #minetest |
| 02:31 |
|
queria^clone joined #minetest |
| 03:02 |
|
kamdard_ joined #minetest |
| 03:18 |
|
euphoria joined #minetest |
| 03:18 |
euphoria |
Hello there |
| 03:34 |
|
mckayshirou left #minetest |
| 04:02 |
|
MTDiscord1 joined #minetest |
| 04:03 |
|
Alias2 joined #minetest |
| 04:03 |
|
rubywarden joined #minetest |
| 04:04 |
|
Supersonic joined #minetest |
| 04:09 |
|
specing joined #minetest |
| 04:27 |
|
wsor4035 joined #minetest |
| 05:03 |
|
Hawk777 joined #minetest |
| 05:14 |
|
ChanServ joined #minetest |
| 05:35 |
|
Gustavo6046 joined #minetest |
| 05:45 |
|
TomTom joined #minetest |
| 06:15 |
|
Gustavo6046 joined #minetest |
| 06:54 |
|
independent56 joined #minetest |
| 06:56 |
|
independent56 joined #minetest |
| 07:06 |
|
Flabb joined #minetest |
| 07:10 |
|
CWz joined #minetest |
| 07:23 |
VanessaE |
anyone here good with advtrains? |
| 07:25 |
specing |
with code or use? |
| 07:25 |
VanessaE |
use |
| 07:26 |
|
iamweasel joined #minetest |
| 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:49 |
|
asterismo joined #minetest |
| 07:49 |
|
asterismo joined #minetest |
| 07:50 |
specing |
yeah the train autism server |
| 08:01 |
|
specing_ joined #minetest |
| 08:25 |
MTDiscord |
<IhrFussel> 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 |
<IhrFussel> 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 |
<IhrFussel> https://forum.minetest.net/viewtopic.php?f=3&t=26895 |
| 08:51 |
|
SwissalpS joined #minetest |
| 08:52 |
celeron55 |
that the |
| 08:54 |
\ |
lol that thread is quite a read |
| 08:55 |
MTDiscord |
<IhrFussel> 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 |
<IhrFussel> 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 |
<IhrFussel> L-Dog is no kid btw, he's an adult...this could explain why he tries to be so overprotective |
| 09:09 |
MTDiscord |
<IhrFussel> 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:11 |
|
calcul0n__ joined #minetest |
| 09:12 |
celeron55 |
i also believe the police know that so i wouldn't worry too much about those reports |
| 09:13 |
MTDiscord |
<IhrFussel> 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 |
<IhrFussel> 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 |
<IhrFussel> Unless his posts include some evidence finally |
| 09:24 |
|
hecks joined #minetest |
| 09:44 |
|
jluc joined #minetest |
| 09:49 |
|
delta23 joined #minetest |
| 10:07 |
|
Cork joined #minetest |
| 10:19 |
|
entuland joined #minetest |
| 10:29 |
|
erlehmann joined #minetest |
| 10:37 |
|
WhiteHorse joined #minetest |
| 10:47 |
erlehmann |
<celeron55> my estimate is 50% of people are idiots |
| 10:48 |
erlehmann |
low-balling it here right? :D |
| 10:48 |
erlehmann |
<celeron55> 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. |
| 11:03 |
|
Fixer joined #minetest |
| 11:03 |
|
Kimapr joined #minetest |
| 11:15 |
|
est31 joined #minetest |
| 11:29 |
|
Ingar joined #minetest |
| 11:33 |
|
cation joined #minetest |
| 11:44 |
|
calcul0n_ joined #minetest |
| 12:10 |
|
Wuzzy joined #minetest |
| 12:18 |
|
independent56 joined #minetest |
| 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! |
| 12:21 |
|
Noisytoot joined #minetest |
| 12:31 |
|
Alias joined #minetest |
| 13:30 |
|
olliy joined #minetest |
| 14:02 |
|
kamdard_ joined #minetest |
| 14:09 |
independent56 |
/join #cachet |
| 14:09 |
independent56 |
fuck |
| 14:09 |
|
Cork joined #minetest |
| 14:10 |
rubenwardy |
no swearsies, this is a christian minecraft server |
| 14:47 |
independent56 |
XD |
| 14:48 |
MTDiscord |
<Warr1024> "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 |
<wwar> "... or how its supposed to end." |
| 14:55 |
|
GNUHacker joined #minetest |
| 15:09 |
|
Hawk777 joined #minetest |
| 15:23 |
|
appguru joined #minetest |
| 15:53 |
|
bingfengzs joined #minetest |
| 15:58 |
|
Talkless joined #minetest |
| 16:04 |
|
bingfengzs_ joined #minetest |
| 16:23 |
entuland |
does the content DB automatically pull new releases from GitHub? |
| 16:23 |
MTDiscord |
<gpcf> 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 |
[git] Wuzzy2 -> minetest/minetest: Fix some typos in builtin (#11370) b28523b https://git.io/JnPXb (2021-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:34 |
|
Gustavo6046 joined #minetest |
| 16:36 |
|
lhofhansl joined #minetest |
| 16:53 |
GNUHacker |
servers admins have a serious problem, the modified clients |
| 16:57 |
specing |
ohno |
| 17:03 |
|
kamdard joined #minetest |
| 17:12 |
|
valhalla joined #minetest |
| 17:13 |
|
independent56 joined #minetest |
| 17:14 |
|
y5nw joined #minetest |
| 17:22 |
|
queria joined #minetest |
| 17:42 |
|
logger56 joined #minetest |
| 17:47 |
|
specing joined #minetest |
| 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 |
<Warr1024> 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 |
[git] Wuzzy2 -> minetest/minetest: Update builtin locale (#11371) 7fdbf3f https://git.io/JnPAj (2021-06-21T17:55:55Z) |
| 17:56 |
MinetestBot |
[git] neoh4x0r -> minetest/minetest: Strip carriage returns from lines in settingtypes.txt (#11338) 9d2e7fc https://git.io/JnPxv (2021-06-21T17:55:48Z) |
| 17:56 |
MinetestBot |
[git] bensuperpc -> minetest/minetest: Update Dockerfile and improve build speed (#11313) 4b9a51f https://git.io/JnPxf (2021-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 |
<Warr1024> 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 |
<Warr1024> If you want players to have access to coords then grant them that access |
| 18:02 |
MTDiscord |
<Warr1024> It will be nice though to make cheats an "opt-in" only feature though. |
| 18:02 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> what do you mean "now way?"? |
| 18:17 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Oh, 5.5 clients on a 5.4 server? |
| 18:20 |
rubenwardy |
correct |
| 18:21 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> Dont hud flags make more sense in the context of modding APIs anyway? |
| 18:23 |
rubenwardy |
yeah definiteyl |
| 18:23 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Was "mods can control" this really the reason to reject that? |
| 18:25 |
sfan5 |
¯\_(ツ)_/¯ |
| 18:25 |
MTDiscord |
<Warr1024> 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 |
<GreenXenith> Is this Warr? ? |
| 18:26 |
MTDiscord |
<GreenXenith> https://cdn.discordapp.com/attachments/749727888659447960/856600943214985216/0vva3sr4pnq61.png |
| 18:26 |
MTDiscord |
<Warr1024> haha |
| 18:26 |
MTDiscord |
<exe_virus> Lol, nice |
| 18:26 |
MTDiscord |
<Warr1024> I seriously doubt that story because there's never JUST ONE bug. |
| 18:27 |
rubenwardy |
Wuzzy ^ |
| 18:28 |
MTDiscord |
<Warr1024> 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 |
|
Jordach joined #minetest |
| 18:28 |
Pexin |
what it should be? |
| 18:28 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> Where was that comment about the HUD flag thing from anyway? |
| 18:30 |
rubenwardy |
PR OP |
| 18:30 |
|
independent56 joined #minetest |
| 18:30 |
Wuzzy |
so can i consider my PR to be rejected? |
| 18:31 |
sfan5 |
no? |
| 18:31 |
|
Gustavo6046 joined #minetest |
| 18:31 |
MTDiscord |
<Warr1024> 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 joined #minetest |
| 18:32 |
ZftxqBQjXIqw |
Li83raChAT aIN't new fr33nod3, y0u'r3 mislED |
| 18:32 |
|
independent56 joined #minetest |
| 18:32 |
MTDiscord |
<Warr1024> 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 |
|
independent56 joined #minetest |
| 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 |
|
Noisytoot joined #minetest |
| 18:34 |
MTDiscord |
<Warr1024> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
|
absurb joined #minetest |
| 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 |
<Warr1024> You mean you want to change the default behavior to opt-in. |
| 18:37 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> and IIRC this thing missed at least 2 releases already... |
| 18:38 |
Wuzzy |
oh that's nothing |
| 18:38 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<Warr1024> Without HUD flags admin is FORCED to install mod if they want the defaults the other way |
| 18:46 |
sfan5 |
<sfan5> having a priv would be useful to avoid having to install a mod to make it work |
| 18:46 |
sfan5 |
<sfan5> but for compatibility and internal reasons it has to be a hud flag |
| 18:46 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<IhrFussel> 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 |
<Warr1024> Wat |
| 18:47 |
MTDiscord |
<Warr1024> that's what we were just saying |
| 18:47 |
|
independent56 joined #minetest |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<appguru> shouldn't a 5.4 client work fine? |
| 18:49 |
MTDiscord |
<Warr1024> that's not an insurmountable problem but it's very error-prone and many server owners will probably miss the announcement. |
| 18:49 |
MTDiscord |
<appguru> 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 |
<Warr1024> 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 |
<appguru> 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 |
<Warr1024> 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 |
<appguru> 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 |
<Warr1024> 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 |
<appguru> 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 |
<Warr1024> Unfortunately we will already have 5.5-dev clients connecting to 5.4 servers. |
| 18:51 |
MTDiscord |
<appguru> 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 |
<Warr1024> We CAN have nice things, it's just gonna take a little work. |
| 18:51 |
MTDiscord |
<GreenXenith> Oh dont worry, there are plenty more reasons why we cant have nice things |
| 18:51 |
MTDiscord |
<appguru> those are a nice thing |
| 18:52 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<appguru> what we're saying is that for compatibility reasons stuff should default to true, which it won't with privs |
| 18:54 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> oh, you mean the hooks fire at nonsensical times? |
| 19:03 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> Blame IRC for not having API to display it any other way |
| 19:12 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> Webhooks display with a bot tag |
| 19:15 |
sfan5 |
the name |
| 19:15 |
MTDiscord |
<Warr1024> 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 "Hawk777" |
| 19:15 |
MTDiscord |
<GreenXenith> The preview also changes |
| 19:15 |
sfan5 |
and it says sfan5 |
| 19:15 |
MTDiscord |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> I absolutely want to be able to set the default behavior for F5 debug info as a GAME publisher. |
| 19:15 |
MTDiscord |
<GreenXenith> You know what, no commet |
| 19:16 |
MTDiscord |
<GreenXenith> comment* |
| 19:16 |
MTDiscord |
<GreenXenith> 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 |
<Warr1024> 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 |
<GreenXenith> Anyway, now I know there are at least 3 hidden core devs lurking on Discord ;p |
| 19:18 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
|
logger56 joined #minetest |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> "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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<wwar> Have 2 accounts, use 1 for craetive/admin stuff and the other for survival?.. |
| 19:29 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> Youve just described Minetest as a whole |
| 19:36 |
MTDiscord |
<Warr1024> More like software as a whole |
| 19:37 |
MTDiscord |
<wwar> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> I mean there should be a way to do this that's at least a little sane. |
| 19:38 |
MTDiscord |
<wwar> I see |
| 19:39 |
MTDiscord |
<wwar> 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 |
<Warr1024> 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 |
<wwar> I played some nodecore few days ago and noticed that debug info will do some..cheaty stuff |
| 19:40 |
|
Gustavo6046_ joined #minetest |
| 19:40 |
MTDiscord |
<Warr1024> 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 |
<Wuzzy> let me summarize the plan ... |
| 19:41 |
Wuzzy |
<Wuzzy> 1) default behavior is the same as before |
| 19:41 |
Wuzzy |
<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 |
<Wuzzy> 3) priv to overwrite the hud flag and get the full debug screen anyway (for admins, etc.) |
| 19:41 |
MTDiscord |
<wwar> 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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> I'm good with taking it away by default |
| 19:44 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> (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 |
<Warr1024> :-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 |
<GreenXenith> 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 |
<Warr1024> I think we just sort of assumed that nobody would be okay with a change that radical. |
| 19:47 |
rubenwardy |
yeah |
| 19:47 |
MTDiscord |
<GreenXenith> 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 |
<Warr1024> Having a benevolent dictator around has some real perks. |
| 19:48 |
Wuzzy |
<celeron55> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> I'm on Debian and you should be thankful that they've bothered to do 5.x.x at all. |
| 19:51 |
|
Santiago39_3 joined #minetest |
| 19:51 |
MTDiscord |
<Benrob0329> sfan5: Stable or backports/testing? |
| 19:51 |
sfan5 |
in any form |
| 19:51 |
sfan5 |
testing/unstable whatever |
| 19:51 |
MTDiscord |
<Benrob0329> Ouch |
| 19:52 |
Pexin |
re ubuntu: don't they use snap for that? |
| 19:52 |
MTDiscord |
<Benrob0329> 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 |
<Benrob0329> Are there official Appimages yet? |
| 19:53 |
MTDiscord |
<Warr1024> 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 |
[git] NeroBurner -> minetest/minetest: Move build/android directory to root of project (#11283) a7143c2 https://git.io/JnX3j (2021-06-21T19:51:42Z) |
| 19:53 |
MTDiscord |
<Warr1024> I don't remember whether it was 5.4.0 or 5.4.1 |
| 20:26 |
|
queria joined #minetest |
| 20:38 |
|
iamweasel joined #minetest |
| 20:47 |
|
Gustavo6046_ joined #minetest |
| 20:47 |
|
Gustavo6046_ joined #minetest |
| 20:52 |
|
Gustavo6046 joined #minetest |
| 20:57 |
|
SwissalpS joined #minetest |
| 21:03 |
|
Gustavo6046 joined #minetest |
| 21:07 |
|
logger56 joined #minetest |
| 21:20 |
|
independent56 joined #minetest |
| 21:57 |
|
YuGiOhJCJ joined #minetest |
| 22:16 |
Swift110-mobile_ |
hey all |
| 22:50 |
MTDiscord |
<Warr1024> When was the "show block bounds" feature added? |
| 22:50 |
MTDiscord |
<Warr1024> like as in first release it did or will appear in... |
| 22:51 |
MTDiscord |
<Jonathon> 5.5-dev |
| 22:51 |
MTDiscord |
<Jonathon> @Warr1024 https://github.com/minetest/minetest/pull/11172 |
| 22:53 |
MTDiscord |
<Warr1024> Okay, good, I was worried that it had been in there forever and I was just a dunce for never noticing. |
| 22:54 |
MTDiscord |
<Jonathon> by minetest terms is flew under the radar drama and action wise |
| 23:04 |
|
Alias2 joined #minetest |
| 23:11 |
|
calcul0n joined #minetest |
