| 00:00.25 | blast007 | if we were going that route, we'd probably just have the clients talk with the matchmaking service again |
| 00:00.49 | JeffM | If you want to get really fancy, in the league instance the fun match server reinits in replay mode showing a time delay replay of the actual match, so observers are |
| 00:00.58 | JeffM | On another instance |
| 00:01.13 | JeffM | Possibly, forcing the |
| 00:01.20 | blast007 | we need to add parachutes to the tanks, and remove all weapons. then we can hide weapons inside buildings and drop in all the tanks from a military cargo plane. |
| 00:01.35 | JeffM | Forcing them to contact the match server is one way to implement the message |
| 00:01.50 | Delusional | Drop Zone |
| 00:01.54 | JeffM | blast007: like 100 of them? |
| 00:02.03 | blast007 | JeffM: yeah, that sounds about right |
| 00:02.17 | blast007 | and then add, like, a circle of death that they have to be inside of |
| 00:02.20 | JeffM | And one tank is thanos? |
| 00:02.37 | blast007 | guess it would be a circle of not death, except for all the death happening |
| 00:02.42 | JeffM | How do you make a tank dance? |
| 00:03.21 | Delusional | shoot at itâs feet |
| 00:03.36 | JeffM | Boggie bombs |
| 00:04.22 | JeffM | A few messages more and i could actually give you bzflag royale |
| 00:04.38 | JeffM | Allow shot and allow drop |
| 00:04.54 | JeffM | And force observer |
| 00:05.58 | JeffM | With the full dialog system could also make you pick your drop area |
| 00:05.58 | blast007 | you'd have to add janky physics and bad RNG |
| 00:06.15 | blast007 | and we'd probably have to unfix some of our crash fixes we've put in, we're far too stable now |
| 00:06.24 | JeffM | No I would not base it on pbug, fortnight |
| 00:06.32 | JeffM | Much more stable |
| 00:06.50 | JeffM | I guess Iâd need force spawn too |
| 00:07.06 | blast007 | oh, then you'd not need to worry about implementing health or shields because they already have shotguns that will one shot you with full shield/health :P |
| 00:07.15 | JeffM | Exactly |
| 00:07.31 | blast007 | force spawn is already possible |
| 00:07.40 | blast007 | I did that for an april 1 joke back in 2.0 days |
| 00:07.40 | JeffM | Ok |
| 00:08.18 | blast007 | force spawned into autopilot with CTF flags on an FFA server :P |
| 00:08.40 | JeffM | If you wanted a true lay massive map, may need to move to a floating origin system for rendering |
| 00:09.13 | blast007 | tried rabbit chase, but autopilot crashed the client when it tried to find the rabbit/hunter team flag |
| 00:09.19 | JeffM | Floats can loose accuracy the further away from zero you get |
| 00:10.14 | blast007 | just like the Minecraft farlands |
| 00:10.32 | JeffM | Sort of |
| 00:10.41 | JeffM | I believe |
| 00:11.01 | JeffM | That had issues with some max ints too |
| 00:11.08 | JeffM | Cluster ids |
| 00:11.40 | JeffM | Floating origin or moving world |
| 00:11.47 | JeffM | Is pretty easy to implement |
| 00:20.22 | Zehra | I'm probably going to sound a bit rude, but any chance for forced-spawning to be added to the API for 2.5/6? |
| 00:23.35 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:23.35 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:23.35 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:23.38 | JeffM | But it means you need to route up to 200 ports on your firewall |
| 00:23.45 | JeffM | Per server |
| 00:24.25 | blast007 | macsforme: I don't think I proposed that |
| 00:25.22 | blast007 | the two byte code will already handle the spoofing issue |
| 00:25.24 | macsforme | oh :P sorry |
| 00:26.16 | macsforme | JeffM: isn't there already a UDP range at the upper end which can't be filtered by the firewall because it's used for outgoing connections? |
| 00:26.21 | JeffM | It was in my initial proposal, I do understand there are server config issues |
| 00:26.51 | JeffM | macsforme: I donât know that may be researchable |
| 00:27.13 | JeffM | But you would still have to route them on a home connection |
| 00:27.20 | blast007 | macsforme: the firewall concern was for inbound connections to the host |
| 00:27.36 | macsforme | there has to be, unless your firewall also prevents users from connecting out via UDP |
| 00:27.43 | JeffM | Yes the sever has to listen on the randomized port |
| 00:28.08 | blast007 | most firewall configurations only care about inbound connections |
| 00:29.48 | macsforme | I'm thinking of how UDP hold punching through a NAT works, but I'm trying to wrap my mind around the similarities to this scenario |
| 00:33.31 | blast007 | would the NAT device pick it's own random port to use as the source port and use that to track? |
| 00:35.49 | macsforme | not sure I understand the question |
| 00:36.23 | RoscoePColtrane | NAT doesn't change ports |
| 00:37.51 | blast007 | "The vast bulk of Internet traffic uses Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). For these protocols the port numbers are changed so that the combination of IP address and port information on the returned packet can be unambiguously mapped to the corresponding private network destination." https://en.wikipedia.org/wiki/Network_address_translation |
| 00:40.27 | RoscoePColtrane | that is a poor summary |
| 00:41.36 | blast007 | when I'm saying NAT I'm not referring to just mapping one address to another address, but port level stuff too |
| 00:41.55 | RoscoePColtrane | in the RFC, 4.1.2 describes "Network Address Port Translation (NAPT)" which what you are referring to |
| 00:42.49 | macsforme | so I guess the question is, does a typical firewall on our game servers filter incoming UDP packets in the dynamic port range? |
| 00:43.16 | macsforme | which is apparently 49152 - 65535 |
| 00:43.30 | RoscoePColtrane | a decent firewall requires holes for whatever you want to allow in |
| 00:44.00 | blast007 | macsforme: the destination port of a packet from the client would be 5154, not the dynamic port range |
| 00:44.22 | blast007 | the firewall rule would be based on the incoming destination port |
| 00:44.42 | macsforme | I was speaking of the one-port-per-client suggestion |
| 00:45.20 | blast007 | still wouldn't be in that range |
| 00:46.20 | macsforme | wouldn't it have to be, to avoid potential collisions with other services? |
| 00:46.49 | blast007 | I don't think it's worth considering |
| 00:48.13 | blast007 | the reason JeffM was suggesting it was to prevent an attack from sending a bunch of bogus traffic to a server by just looking at the server list |
| 00:48.32 | blast007 | but you can still just flood out a connection without knowing which port to attack |
| 00:48.51 | RoscoePColtrane | between 5050 and 5144 are unassigned |
| 00:48.58 | RoscoePColtrane | that's a pretty big range |
| 00:49.15 | blast007 | RoscoePColtrane: 200 ports needed, per server :) |
| 00:49.31 | RoscoePColtrane | how many servers can host 200 players? |
| 00:49.42 | blast007 | that's what our protocol allows |
| 00:49.45 | RoscoePColtrane | 5306-5999 are unassigned |
| 00:49.51 | RoscoePColtrane | is that enough for you? |
| 00:50.08 | RoscoePColtrane | :) |
| 00:50.19 | blast007 | it doesn't matter, it's not a useful feature |
| 00:51.12 | macsforme | "It would also be good/better to have the server tell the client what UDP port to use, so it could be different or randomly assigned." so are you no longer proposing a random UDP port? |
| 00:51.58 | blast007 | "(From @JeffM2501)" |
| 00:52.40 | RoscoePColtrane | as noted, "arbitrary" is a better choice of words |
| 00:52.51 | macsforme | oh, I missed that part |
| 00:53.06 | blast007 | I transposed JeffM's google doc notes to individual github issues |
| 00:53.20 | RoscoePColtrane | part of the back-and-forth with Tim |
| 01:09.58 | JeffM | macsforme: the port can be random but picked by the server |
| 01:10.27 | JeffM | The client should not tell the server what port to open |
| 01:10.46 | JeffM | And only one side can do the random |
| 01:11.02 | JeffM | Also donât care about the port on the client, itâs not part of the attack profile |
| 01:11.26 | JeffM | Hence sever tells client what rando port to use |
| 01:25.24 | blast007 | JeffM: okay, if we copy Fortnite, we'll have to add matchmaking errors that prevent you from unready'ing and backing out and require a restart of the game |
| 01:52.20 | alezakos | Regarding Github's services, I can offer boal for webhook notifications if needed |
| 01:57.44 | blast007 | alezakos: okay, I'll keep that in mind. It's just unfortunate they're killing off built-in support for IRC, potentially. |
| 02:10.30 | JeffM | macsforme: I offered to write up more details about each item if itâll help people understand the concepts better |
| 02:11.46 | JeffM | Itâs all from my examination of the networking protocol when I was trying out stuff with threads in c# |
| 02:16.27 | allejo | blast, IRC isn't what all the hip young children use nowadays. it's all about slack and hipchat! and skype and msn messenger and AIM |
| 02:16.45 | RoscoePColtrane | dinosaur |
| 13:01.02 | tupone | where are the plugins supposed to be delivered. On gento oI found them directly under /usr/lib64. Is that right? I would suggest /usr/lib64/bzflag |
| 13:02.20 | blast007 | on Debian they end up under /usr/lib/bzflag-server/ |
| 13:03.14 | blast007 | does Gentoo have a separate ebuild for the server, or is it both the client and server as one? |
| 13:03.26 | tupone | only one |
| 13:03.44 | tupone | but then, where bzfs load from? |
| 13:03.58 | blast007 | what do you mean? |
| 13:04.32 | blast007 | where does it load plugins from? |
| 13:04.39 | tupone | I do not know how you specify to bzfs where to load the plugin |
| 13:04.54 | tupone | full path? |
| 13:05.08 | blast007 | it's part of the configure script. we include the install path as a lookup directory for loading plugins. |
| 13:05.31 | blast007 | INSTALL_LIB_DIR |
| 13:06.09 | tupone | ok. I will check and eventually fix the ebuild |
| 13:06.52 | tupone | any news for glew ? |
| 13:07.47 | tupone | s/for/about/ |
| 13:08.27 | blast007 | Debian ends up using something like this (at least for amd64): |
| 13:08.29 | blast007 | ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr ... |
| 13:08.36 | blast007 | ... --datarootdir=/usr/share/games |
| 13:10.56 | tupone | I do not see bzflag-server |
| 13:11.25 | blast007 | in Debian? |
| 13:11.35 | tupone | in the line you wrote |
| 13:12.03 | blast007 | oh |
| 13:12.13 | blast007 | hmm |
| 13:12.15 | blast007 | dunno |
| 13:13.42 | blast007 | so maybe the automatic path finding doesn't work on Debian's binary package :) |
| 13:14.07 | blast007 | seems like they just copy plugins/*/.libs/*.so to usr/lib/bzflag-server |
| 13:14.13 | blast007 | https://salsa.debian.org/games-team/bzflag/blob/master/debian/bzflag-server.install |
| 15:28.35 | macsforme | what is a good way to arrange a triple monitor setup with one 27â 1440p monitor and two 23â 1080p monitors? |
| 15:41.22 | allejo | 23 27 23 |
| 15:51.38 | macsforme | vertical or horizontal? |
| 15:53.20 | macsforme | I thought of 23/27/23 with one of the 23â monitors vertical... I just wonder if that would look funky |
| 15:55.02 | allejo | i prefer everything horizontal, but could have either 23 veritical if I constantly work with long files or something that'd justify a vertical screen |
| 15:58.19 | JeffM | most displays have a different vertical view angle, so rotating them makes them look odd from the side. |
| 15:59.47 | JeffM | https://usercontent.irccloud-cdn.com/file/kd7Ia5Lc/IMG_1986.JPG |
| 16:01.13 | macsforme | these are all IPS displays so I think the viewing angle will be okay... havenât really tried it yet, though |
| 18:05.37 | blast007 | are we wanting to move to OpenGL 2.1 for 2.6? |
| 18:16.58 | JeffM | do the support the same platform set? |
| 18:18.44 | blast007 | meaning Windows/Linux/macOS? |
| 18:18.59 | JeffM | yes, and the versions of those that you want to support |
| 18:19.27 | JeffM | does 2.6 make it so like XP or vista doesn't run, or some old OSX, or one of the bajillion linux distros |
| 18:20.09 | blast007 | I think even XP could use GL 2.1 |
| 18:20.39 | JeffM | but could it also use GL2.6 |
| 18:20.52 | JeffM | if both support the same platform set, go with the highest |
| 18:21.12 | JeffM | if they don't, you pick the highest that supports the platforms you want to be on. |
| 18:22.24 | blast007 | for Windows, it was more about your hardware and drives, no? |
| 18:22.44 | JeffM | possibly |
| 18:23.06 | JeffM | what's the oldest intel onboard that supports 2.6 ? |
| 18:23.12 | blast007 | https://developer.apple.com/opengl/OpenGL-Capabilities-Tables.pdf seems that GL 2.1 is pretty well supported by macOS |
| 18:23.50 | JeffM | do they not support 2.6? |
| 18:24.23 | blast007 | the first gen Intel Core processors support 2.1 on Windows |
| 18:24.24 | JeffM | ahh more pages |
| 18:24.38 | JeffM | do first gen into cores support 2.6? |
| 18:24.44 | blast007 | no |
| 18:24.49 | JeffM | you way behind the times, so you want to try to get as new as you can |
| 18:25.02 | JeffM | what do you loose support for if you go with 2.6? |
| 18:25.08 | JeffM | that's the main question |
| 18:25.19 | blast007 | 2nd gen Core supports 3.1 |
| 18:25.26 | blast007 | https://www.intel.com/content/www/us/en/support/articles/000005524/graphics-drivers.html |
| 18:26.57 | JeffM | so if you want 2.6 you'd lose support for 10 year old CPUs |
| 18:27.06 | blast007 | my Core 2 Duo laptop supports GL 2.0 on Windows, but at least 2.1 under linux |
| 18:27.33 | JeffM | did 2.6 take it to a different shader level? |
| 18:27.49 | blast007 | I don't actually see a 2.6 |
| 18:27.55 | blast007 | goes from 2.1 to 3.0 |
| 18:28.21 | JeffM | 3 was the dropping of the legacy functions IIRC |
| 18:28.25 | JeffM | no more state machine |
| 18:28.37 | blast007 | <@macsforme> I would be in favor of transitioning to GL 2.1 or even 3.2 (which would take more work to transition) |
| 18:28.40 | blast007 | <@macsforme> 2.1 would allow us to do it progressively, while still incorporating some shader stuff alongside our current code |
| 18:28.43 | blast007 | <@macsforme> per-pixel lighting would be a big graphical improvement right off the bat |
| 18:29.10 | JeffM | yes. 2.1 gets you some new stuff, but keeps the legacy functions around, glVertext etc.. |
| 18:29.26 | JeffM | 3.2 gets rid of all that, hence more work |
| 18:29.54 | JeffM | the OpenGL3 spefication marks many things that bzflag does as deprecated |
| 18:30.04 | blast007 | imagine that :) |
| 18:30.23 | JeffM | the 2 line includes them all, but also has the fun shader stuff. |
| 18:31.30 | blast007 | sounds like even with 3 you can still access those older features if you request a full context instead of a forward-compatible context |
| 18:31.47 | JeffM | I belive the driver doens't HAVE To support them |
| 18:31.52 | blast007 | 3.1 removes them |
| 18:31.57 | JeffM | ahh |
| 18:32.07 | JeffM | if you go 3, got 3.2 |
| 18:32.56 | JeffM | GL 3.2 IIRC is like DX10 hardware. |
| 18:33.20 | blast007 | I kinda unclear actually, because now 3.2 says "Compatibility contexts include the previously-removed fixed-function APIs, equivalent to the ARB_compatibility extension released alongside OpenGL 3.1, while core contexts do not." |
| 18:33.39 | JeffM | if you are going to go compatability just do 2.1 |
| 18:34.29 | JeffM | so OSX 10.7 only supports 3.2 core profiles |
| 18:34.34 | JeffM | not compatibilkity |
| 18:35.06 | JeffM | but that means that 3.2 is 10.7 or later |
| 18:35.13 | JeffM | whats the oldest OSX you want to support? |
| 18:35.21 | blast007 | 10.7 is already our oldest |
| 18:36.14 | blast007 | 2.1 is probably a nicer migration step as we can gradually do it |
| 18:36.25 | JeffM | then if you are ok with abandoning some super old intel CPUs, you'll get more milage out of going full 3.2 |
| 18:36.43 | JeffM | if someone is going to redo it all, may as well have them go as high as they can :) |
| 18:36.57 | JeffM | or go engine |
| 18:37.08 | JeffM | if you want incremental, go 2.1 |
| 18:37.17 | blast007 | if we go 2.1, we can gradually get rid of all the legacy stuff, right? |
| 18:38.25 | JeffM | sort of |
| 18:38.40 | JeffM | there will still be some work when you eventualy swap to 3.2 |
| 18:39.03 | JeffM | it's not like you'll eventualy get to codebase that is compatible with 2.1 and 3.2 in one shot |
| 18:39.10 | JeffM | there will still need to be changes. |
| 18:43.13 | blast007 | guess I'll have to get myself a Thinkpad X230 so I'll have OpenGL 4 :P |
| 19:07.49 | JeffM | <PROTECTED> |
| 19:17.16 | tupone | blast007: as for glew .. have you tested it? Are we ready to put on 2.4 ? |
| 19:45.36 | blast007 | JeffM: the X200 I purchased specifically because it has the ability to run libreboot/coreboot if I get to that point |
| 19:49.21 | JeffM | should not 2.4 be in like lockdown mode now? With all new things going into master and pull requests for backports as needed? |
| 19:50.13 | blast007 | I don't think glew does much for us in 2.4 |
| 19:50.31 | blast007 | if we're moving to GL 2.1 for 2.6, it would have much more use there |
| 19:51.09 | tupone | ok. So for 2.6 ? should someone add it ? |
| 19:51.22 | blast007 | (also, the X200 didn't have a touchpad, which I prefer) |
| 19:51.26 | JeffM | I'm also speaking in general, not just for glew. Nobody should even mention a 2.4 backport unless its in master |
| 19:51.38 | blast007 | it's unfortunate that they added a touchpad on later models |
