| 00:22.13 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:22.13 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 00:22.13 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:10.57 | macsforme | when I was working on the premake project, I did a hard look over the config.h for each platform, common.h, and some of the platform-specific files like win32.h... there seemed to be a lot of legacy workarounds for missing compiler features and such, and a substantial number of the macros in those files aren't even referenced in our source code |
| 01:12.31 | macsforme | is it possible that compilers have been standardized enough by now that we could prune some of that stuff out? |
| 01:19.52 | macsforme | I had eliminated the config.h on all platforms and whittled the logic down to this (without actually checking if we could eliminate any of these macros): https://github.com/macsforme/bzflag/blob/e5f6d086fa44d1006d1f18cce233bfcf163128da/premake5.lua#L337-L508 |
| 01:26.55 | macsforme | I wonder if we fully adopted C++11 whether we would get most or all of those compiler features guaranteed |
| 01:30.48 | blast007 | standardizing on C++11 and SDL2 could probably aid towards a lot of cleanups |
| 03:20.32 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-pzbomppekkfbcfdz) |
| 03:20.32 | BZnotify | [13api.bzflag.org] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vxbXv |
| 03:20.32 | BZnotify | 13api.bzflag.org/06master 1485b0655 15Scott Wichser: Add the ability to search for users by name. |
| 03:20.32 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-pzbomppekkfbcfdz) |
| 03:21.57 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-stpekgjvsqywvbvw) |
| 03:33.20 | JeffM | Yeah most of the macros could be replaced with things in std |
| 06:44.38 | RoscoePColtrane | what is the new api project? |
| 06:45.16 | RoscoePColtrane | and why C++11 when C++17 is (almost) out? How about at least C++14? |
| 06:47.10 | RoscoePColtrane | even VS2017 does very well with C++14 |
| 06:47.32 | RoscoePColtrane | make that VS2015 |
| 06:48.08 | RoscoePColtrane | the only issue I've noted (also with gcc 7.3) is <filesystem> isn't quite there ... still in <experimental/filesystem> |
| 07:02.15 | allejo | in a nut shell, the API is gonna be an attempt to redesign our global services and slowly move away from relying on phpBB |
| 10:17.13 | blast007 | RoscoePColtrane: we don't want to require everyone to be running bleeding edge software to build the game |
| 10:18.23 | blast007 | the current LTS of Ubuntu, for instance, only has GCC 5.3 |
| 10:19.59 | blast007 | (and that LTS is supported by Ubuntu until April 2021) |
| 10:20.34 | blast007 | their upcoming LTS will have GCC 7.3 |
| 10:23.00 | blast007 | though looks like GCC 5 might supporte C++14 |
| 12:07.43 | blast007 | support* |
| 14:23.19 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 15:10.17 | JeffM | allejo/blast007 you should probably call it a Services API, so people don't think it's a Server API ;) |
| 15:10.23 | JeffM | too many APIs |
| 15:10.33 | JeffM | or... maybe not enough! |
| 15:42.52 | blast007 | JeffM: that was what I was originally going to call it, but I thought "Services" was too close to "Server" and would cause confusion :) |
| 15:43.12 | JeffM | could call the server API the BZFS_API |
| 15:43.18 | JeffM | since that's what all the functions start with |
| 15:43.38 | blast007 | we do |
| 15:43.40 | blast007 | https://www.bzflag.org/documentation/developer/bzfs_api/ |
| 15:44.10 | JeffM | is the new API just for listing or also authentication? and are they the same API? |
| 15:44.25 | blast007 | "This will provide a private and public RESTful API to interact with various BZFlag data. Initially it will allow the manipulation of organizations, groups, and hosting keys." |
| 15:44.39 | JeffM | ahh user groups API |
| 15:45.40 | blast007 | we're working on a new organization/group manager that will use this API |
| 15:45.54 | JeffM | makes sense |
| 15:46.21 | blast007 | weblogin authentication I'm not sure on yet. might be part of the API, might not be. |
| 15:46.40 | blast007 | the API will probably make use of OAuth2 for authentication/authorization |
| 15:46.59 | blast007 | the weblogin will probably use OpenID Connect, which is built on top of OAuth2 |
| 15:48.56 | blast007 | and then as far as in-game login, we'll see. might still be a token system, but instead restricting a token to a specific server instead of a specific client IP |
| 15:49.02 | blast007 | (for 2.6) |
| 15:49.47 | blast007 | no idea if an OAuth2/OpenID Connect flow can work for something like game servers |
| 15:50.55 | blast007 | I had started added the OAuth2 server to the API itself, but maybe that should be it's own thing |
| 15:51.49 | blast007 | seems like both ways may be valid. https://www.oauth.com/oauth2-servers/the-resource-server/ "The resource server is the OAuth 2.0 term for your API server. ... Smaller deployments typically have only one resource server, and is often built as part of the same code base or same deployment as the authorization server." |
| 15:54.33 | *** mode/#bzflag [+o blast007] by ChanServ |
| 15:54.37 | *** mode/#bzflag [-b *!*Zehra@unaffiliated/zehra] by blast007 |
| 15:54.40 | *** mode/#bzflag [-o blast007] by blast007 |
| 16:05.04 | blast007 | sounds like we could potentially use a 'password grant' for authentication in the game client |
| 16:07.57 | blast007 | it would be no less secure than what we do now. the main concerns around that method is mostly regarding 3rd party apps being able to steal a password. |
| 16:52.43 | allejo | let's make our own hashing algorithm! |
| 16:52.50 | allejo | that way, no one else will know! |
| 16:53.24 | allejo | JeffM: I don't think the problem is with our naming of APIs. it's just that they're not powerful enough ;) |
| 16:53.46 | JeffM | why you quote idots? |
| 17:23.47 | blast007 | our APIs don't need more power. |
| 17:23.51 | blast007 | They need courage. |
| 17:24.13 | blast007 | Coruage and lots and lots of blockchain. |
| 17:26.42 | allejo | our API's power is...MAXIMUMER |
| 17:51.10 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 20:27.09 | *** join/#bzflag nitroxis (n@nxs.re) |
| 21:04.22 | *** join/#bzflag dngor (abuse@c-75-74-84-149.hsd1.fl.comcast.net) |
| 21:04.23 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 21:32.37 | *** join/#bzflag The_Noah (6163fde4@gateway/web/freenode/ip.97.99.253.228) |
| 21:34.13 | The_Noah | So for a past few days I've had really high lag and jitter. I got over 900ms jitter at one point. Any ideas what might be causing it? I've never had issues like this before.... |
| 21:35.24 | blast007 | is that over wifi? |
| 21:39.53 | *** join/#bzflag The_Noah_ (6163fde4@gateway/web/freenode/ip.97.99.253.228) |
| 21:40.03 | The_Noah_ | No, its not over WiFi. |
| 22:15.44 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 22:19.25 | *** part/#bzflag The_Noah_ (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 23:42.13 | the_map | well... his connection here might be a clue... |