| Juest | tupone: why? :D | 00:53 |
|---|---|---|
| Juest | wait, blast007, is the unknown flag bug resolved? i dont see a issue open for it | 00:57 |
| Juest | damnit | 00:59 |
| Juest | i just realized you can make issues that are attached to milestones | 00:59 |
| Juest | this issue isn't triaged: https://github.com/BZFlag-Dev/bzflag/issues/336 | 01:00 |
| blast007 | nope, not resolved | 01:15 |
| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 02:00 | |
| Juest | triaged != resolved | 02:16 |
| Juest | oh nevermind | 02:16 |
| Juest | you were answering a different question | 02:17 |
| Juest | lol | 02:17 |
| Juest | anyways, how its going? | 02:17 |
| Zehra | Something I'd like to see perhaps in the next minor release, would be the ability to spawn team flags from teams not present. | 02:26 |
| Zehra | No issues would be present, as it is a server modification, not a client modification, nor does it provide any clients an advantage over another. | 02:28 |
| blast007 | "teams not present" meaning no players joined on that team, or no team base for that team? | 02:30 |
| Zehra | ^no players joined on that team. | 02:31 |
| Zehra | I'm imaging it as an option, such as feeding -mp a negative number to trigger it. Prevents players from joining the team, but spawns team flags from that team. | 02:32 |
| Zehra | I've been thinking that this would be the key to enhancing/creating multiple game modes. | 02:33 |
| Zehra | Steal the Bacon, HTF, Tank Racing, "One flag CTF"...etc become very viable and don't retain their gotchas of before. (No need for a bot to spawn a flag either.) | 02:35 |
| Zehra | Self caps are annoying in HTF: CaptureSwitch has delay issues in practice. We can't trigger caps except under specific conditions. We also can't trigger custom sounds either.. (Resolves issues in a single setting.) | 02:38 |
| blast007 | can an SSP join a team, and does that trigger that team's flag to spawn? | 02:39 |
| Zehra | I haven't worked too far with SSP's... I can't recall exactly where I got with SSP's and team flags... | 02:42 |
| Zehra | I believe it began to look sub-optimal, as likely some form of needing to reset the flag after some delay was needed for the team flag to spawn. | 02:43 |
| Zehra | I did a cheap bypass of the API to get a team flag to spawn... but proved to reset the flag upon any join/leave and lacked persistence. | 02:44 |
| Zehra | https://pastebin.com/hxAFCe6F - flag spawn bypass | 02:48 |
| Zehra | Which seems to get closer to a more elegant solution. (I'm not sure if SSP's are reported as actual players or if they get idle kicked.) | 02:49 |
| Zehra | 3 team CTF becomes more viable to a large extent, don't have players go for a few different team flags, they can focus on one. | 02:54 |
| Zehra | Advantages of a server setting: No bots, no plug-ins to load, no API to bypass, no reducing max player counts, less effort to code compare to SSP's (I think). | 02:55 |
| Zehra | Disadvantages: New setting may be confusing, may make code base bloated, may be entirely unneeded, similar functionality can be duplicated with plug-ins or bots. | 02:56 |
| Zehra | Normally I'd simply skip and just use a workable API bypass, but what prevents me from making it viable, is the flag information is too limited... a.k.a. I don't have information on where a flag would land. | 02:59 |
| Zehra | If I did, it's check where x flag would land, if a player joins or leaves, spawn x flag at landing location. (I can add a delay on allow grab if needed.) | 03:00 |
| Zehra | In short: Lag and server settings make "CaptureSwitch" unreliable. Additionally 2+ teams for one flag CTF don't work. Only makes real sense on no shooting maps. (HTF doesn't really work in that case.) | 03:04 |
| Zehra | (Testing bots now.) | 03:13 |
| Zehra | Bot joins, doesn't cause team flag to spawn, flag reset causes it to spawn. | 03:15 |
| *** FastLizard4 is back | 03:27 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 03:44 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 05:19 | |
| *** FastLizard4 is now away: AWAY from keyboard | 06:17 | |
| *** FastLizard4 is back | 07:27 | |
| *** FastLizard4 is now away: AWAY from keyboard | 08:26 | |
| *** Cobra_Fast is now away: offline | 08:32 | |
| *** Cobra_Fast is back | 08:32 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 08:48 | |
| *** SpringTank is now away: No clients connected to this core right now. | 09:03 | |
| *** SpringTank is back | 09:03 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 09:45 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:30 | |
| *** nitroxis <nitroxis!~n@nxs.re> has quit IRC () | 14:47 | |
| *** nitroxis <nitroxis!~n@nxs.re> has joined #bzflag | 14:57 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 15:30 | |
| *** FastLizard4 is back | 16:51 | |
| *** Cobra_Fast is now away: offline | 16:55 | |
| *** Cobra_Fast is back | 16:55 | |
| *** FastLizard4 is now away: AWAY from keyboard | 17:10 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Read error: Connection reset by peer) | 17:24 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 17:27 | |
| *** L4m3r <L4m3r!~L4m3r@user/L4m3r> has quit IRC (Ping timeout: 246 seconds) | 17:34 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 18:00 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Read error: Connection reset by peer) | 18:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 18:04 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 19:26 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 19:28 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 19:31 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 20:26 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 20:44 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 20:47 | |
| TimRiker | we send the token on every request, right? this is not the password, just a "session" token. OIDC or OAuth2 do the same, passing a signed JWT which may or may not contain user info. It's a session instance, and the user info can be looked up on the userinfo endpoint. | 20:59 |
| *** FastLizard4 is back | 21:22 | |
| *** FastLizard4 is now away: AWAY from keyboard | 21:27 | |
| blast007 | yeah, I'm not sure what they meant by that exactly. We *do* currently send the username/password to the server list every time you request the server list, though. | 22:08 |
| blast007 | I want to change how in-game auth works, but I don't think OIDC/OAuth2 can work there, so it would be a separate thing | 22:09 |
| blast007 | For in-game, I want there to be a login process that generates some sort of session, and then save that session info locally instead of the user's plain text password. | 22:10 |
| TimRiker | yes. the only tokens we create are one-time-use, so we need to keep getting more. A digitally signed token could have a longer lifetime, but a server operator could still capture that token and re-use it on another server. If the tokens are server specific (ie: name-port based) then we could have the server track multiple issued tokens and expire them after some time. | 23:20 |
| TimRiker | the one-time-use overhead is small, and it was simple to build and track. As long as the list server connection is trusted, it works ok. | 23:21 |
| blast007 | I'd still have one-time use tokens that would be requested by the client using the session info. | 23:21 |
| blast007 | Unless there's a better way of doing it. | 23:22 |
| blast007 | for the game auth, the main thing I'm trying to solve is storing the plain-text password | 23:22 |
| TimRiker | if it's one time use, then it needs to be requested for each join. I guess we don't need to request one for the list, but providing the user/pass on server list handles adding private server, ie: group/team servers. | 23:23 |
| blast007 | yeah, requesting the list could just use the session info | 23:23 |
| TimRiker | oauth2/oidc would work, but it would need a redirect. ie: client contacts example.bzflag.org:5154 and if they don't have a valid token for THIS server, gets redirected to the oidc/outh2 server with a game server provided secret. They get a game server token using their auth-server token and bounce back to the game server. They could then cache that game-token to allow re-connect to game server without re-validating handshake. | 23:26 |
| TimRiker | user still needs to type in user/pass someplace. either the game does that itself, or we redirect to a web login and get a session cookie that way. | 23:27 |
| TimRiker | however with that change, game config could cache a token and only require login when the token expires. The user would presumably be able to hit the website and expire a session from there given they have the user/pass. The config would not have a user/pass, but it would still be a re-usable credential. | 23:30 |
| blast007 | yeah, that was my thought too. an account page where you could invalidate sessions. | 23:33 |
| TimRiker | in short, there's nothing stopping the game from using oauth2/oidc, but existing providers want a web browser to parse their custom login/mfa process. The game would need to launch a browser to do that, become a browser to handle the custom html, or we build/customize our own and need to do our own mfa/federation/etc. | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!