| 02:29.44 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 02:47.17 | *** join/#bzflag thrakattak (cz3141@gateway/shell/devio.us/x-cfnktwvnkjbvyktp) |
| 02:52.31 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 03:25.55 | *** join/#bzflag Snake12534 (~Snake1253@99-92-211-46.lightspeed.sntcca.sbcglobal.net) |
| 03:49.20 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 03:51.59 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:54.01 | *** join/#bzflag JeffM (~JeffM@cpe-23-241-222-73.socal.res.rr.com) |
| 05:44.19 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 05:44.20 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 06:01.04 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 07:10.11 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 07:20.19 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 07:20.19 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 07:20.19 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 07:30.33 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 14:02.42 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 15:19.43 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:19.44 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 16:18.21 | *** join/#bzflag JeffM (~JeffM@12.167.61.62) |
| 16:22.33 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 16:22.33 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 16:34.01 | JeffM | hey blast007 do the forums provide any stats? like posts per day and total posts and stuff? |
| 17:00.28 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 17:01.22 | BulletCatcher | Currently, bzfs drops any new connection where the client does not send BZFLAG within 2.5 seconds. |
| 17:01.26 | BulletCatcher | However, there seems to be no time limit for joining fully after the client's BZFLAG string. |
| 17:01.29 | BulletCatcher | I have a change that adds such a timeout. |
| 17:01.31 | BulletCatcher | Does 5 seconds seem adequate? |
| 17:02.21 | BulletCatcher | My new check is in doStuffOnPlayer(), which is called every 3 seconds. |
| 17:07.35 | blast007 | BulletCatcher: I have a change for that which I was testing as well |
| 17:07.43 | BulletCatcher | :-) |
| 17:08.17 | blast007 | and mine as well was in doStuffOnPlayer ;) |
| 17:08.28 | BulletCatcher | Mine compares the current time with playerData.gameTimeNext . |
| 17:09.13 | BulletCatcher | ... when playerData._LSAState == GameKeeper::Player::start |
| 17:09.46 | blast007 | I was using the 'time' value inside of the NetHandler class |
| 17:10.17 | BulletCatcher | Two paths, one destination. |
| 17:11.18 | blast007 | I wasn't entirely sure of the workings of the LSAState variable, so I had a PlayerInfo:hasEntered() that just returns hasDoneEntering |
| 17:11.48 | BulletCatcher | if (playerData._LSAState == GameKeeper::Player::start && (TimeKeeper::getCurrent() - playerData.gameTimeNext) > 5.0f) { kick } |
| 17:12.04 | BulletCatcher | My change is that simple. |
| 17:12.35 | BulletCatcher | I have done local testing, but not on a public server. |
| 17:23.10 | blast007 | using gameTimeNext may be a bit more fragile than using the 'time' value from NetHandler |
| 17:23.32 | blast007 | the one from NetHandler is the 'accepted time' and doesn't get changed in any code |
| 17:24.32 | JeffM | timekeeper on the server should be consistent |
| 17:24.38 | JeffM | it's not sycned with anything |
| 17:25.28 | BulletCatcher | I was concerned about the fragility of gameTimeNext, too. |
| 17:25.28 | blast007 | JeffM: not talking about syncing. just talking about future code changes that could affect the reliability of using 'gameTimeNext' as an indicator for when a half-joined client sent the BZFLAG\r\n\r\n header |
| 17:25.50 | JeffM | oh yeah that part, yeah don't do that |
| 17:26.13 | JeffM | any time data stored in the player record that we use for DR can get sycned |
| 17:26.21 | blast007 | I had added this to NetHandler.h: TimeKeeper getTimeAccepted( void ) const { return time;} |
| 17:26.24 | JeffM | don't we have a connection time? |
| 17:26.30 | JeffM | that works |
| 17:27.16 | JeffM | you may also want to do the same thing for non player connections |
| 17:27.24 | JeffM | so keeping the time in the nethandler is better |
| 17:27.38 | blast007 | then within the if (playerData.netHandler) {...} section for checking hostbans, I had this: |
| 17:27.41 | blast007 | if (!playerData.player.hasEntered() && TimeKeeper::getCurrent().getSeconds() > playerData.netHandler->getTimeAccepted().getSeconds() + 2.0f) { |
| 17:27.44 | blast007 | <PROTECTED> |
| 17:27.47 | blast007 | } |
| 17:28.02 | JeffM | what if I send half an http request? |
| 17:28.04 | blast007 | (well, I had 15.0f actually.. had lowered it for testing) |
| 17:28.12 | blast007 | that I'll have to check as well |
| 17:28.16 | JeffM | 5s is probalby fine |
| 17:28.23 | blast007 | probably |
| 17:28.30 | JeffM | it should not take someone that long to send the join |
| 17:28.46 | JeffM | the only thing that could take time is the reverse dns |
| 17:28.49 | blast007 | world get sent *after* MsgEnter is received by the server, right? |
| 17:28.50 | JeffM | and the auth hit |
| 17:29.15 | JeffM | yeah the world is sent after auth is finished |
| 17:29.18 | JeffM | IIRC |
| 17:29.36 | blast007 | that was one of the main things I wanted to verify/test yet |
| 17:31.54 | BulletCatcher | blast007: (TimeKeeper::getCurrent() - playerData.netHandler->getTimeAccepted() > 5.0) avoids the need for getSeconds() and keeps the code a bit cleaner. |
| 17:32.35 | BulletCatcher | Your change is probably better overall than mine. |
| 17:37.03 | BulletCatcher | The next step after implementing this timeout is to limit the number of non-entered players per IP address. |
| 17:53.47 | blast007 | BulletCatcher: that's difficult when handling -solo bots |
| 17:54.02 | blast007 | maybe we can just remove them? ;) |
| 17:55.20 | BulletCatcher | Don't they use the same TCP connection as the main player? |
| 17:55.27 | blast007 | yeah |
| 17:55.35 | blast007 | but individual slot IDs |
| 17:56.36 | BulletCatcher | We ought to be able to deal with that. |
| 17:57.13 | blast007 | this was a partially working attempt by a_met: https://sourceforge.net/p/bzflag/patches/508/ |
| 17:57.17 | blast007 | didn't handle bots though |
| 17:59.36 | blast007 | Is it worth us handling that in bzfs instead of just doing it as a firewall rule? iptables can both limit the number of concurrent TCP sessions and also limit how many new TCP sessions can be created |
| 18:00.50 | blast007 | the latter of which would probably work best with the other change (killing off half-joined connections) as you could then block traffic from the attacker for a set period of time |
| 18:01.14 | BulletCatcher | My Solaris server doesn't have iptables, but that should work for virtually everyone else. |
| 18:01.53 | BulletCatcher | There may be one public MacOS server, too. |
| 18:02.35 | blast007 | does ipfw have something similar? |
| 18:03.46 | BulletCatcher | Solaris ipf can block, allow, and do NAT, but not much else. |
| 18:04.10 | blast007 | hrm, okay |
| 18:05.16 | BulletCatcher | I plan to move BRL to Linux, but don't have a schedule for that. |
| 18:18.39 | JeffM | so the last solaris server trundles into the sunset? |
| 18:20.11 | BulletCatcher | It isn't dead yet... |
| 18:20.50 | blast007 | and I've got a Sun Ultra 10 that I could probably revive now that I have a soldering iron :P |
| 18:27.43 | JeffM | a guy at school asked me if Sun machines were super popular for doing web hosting |
| 18:29.37 | blast007 | heh |
| 18:30.28 | JeffM | I told him to learn about virtualization if he wants to get into IT at the enterprise level |
| 18:32.21 | blast007 | virtualization, where a licensing "brief" for software can be 15 pages long ;) |
| 18:33.29 | *** join/#bzflag sharkey (~cz3141@unaffiliated/sharkey) |
| 18:39.00 | *** part/#bzflag sharkey (~cz3141@unaffiliated/sharkey) |
| 18:48.25 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 19:00.16 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 19:44.07 | *** join/#bzflag alpha1-2 (~nb_j@181.110.9.70) |
| 19:46.28 | alpha1-2 | I found a bug in the BZ client. It seems the same one reported here: http://sourceforge.net/p/bzflag/bugs/488/ . But it is "closed-out-of-date" and it tells you've to go to IRC if you're still experiencing problems. |
| 19:46.29 | alpha1-2 | I understand that the issue occurs when there is 1 or more lines that exceed the width of the console screen. Then, when you do an up/down scroll, the client counts wrongly, giving to that LONG LINE the value of 1 instead of the REAL value. It has to consider/calculate the width value BEFORE the scrolling. |
| 19:46.31 | alpha1-2 | The issue appears in either Full Screen or Windowed modes. |
| 19:58.47 | alpha1-2 | When I refer to up/down scrolling, I mean using PgUp/PgDown keys/functions. BZ client version: 2.4.0.20120705-STABLE-linux-gnu-SDL (0221). |
| 20:09.41 | JeffM | do you have a fix for it? |
| 20:10.59 | alpha1-2 | no |
| 20:17.46 | cods | Hi. Is it possible to make some object one way passable? (Jump through a box above you, and land on it, for example.) |
| 20:20.31 | cods | ok, doesn't seem possible according to the bzw page. I thought something like that was discussed some years ago. |
| 20:25.42 | alpha1-2 | JeffM: should I make a new report for it? |
| 20:26.02 | JeffM | alpha1-2, on github, sure |
| 20:26.22 | JeffM | cods, there are some tricks to doing it with meshes but it's iffy |
| 20:27.06 | cods | JeffM: ah right.. I'm guessing it. By using face with inverted direction |
| 20:27.20 | alpha1-2 | ok, I will have a look |
| 20:27.21 | JeffM | well a single face |
| 20:27.38 | JeffM | the side with proper windings and normals will be a blocking face |
| 20:27.47 | JeffM | and the backside will be passable |
| 20:27.52 | JeffM | and invisible |
| 20:28.34 | cods | looks fine to me :p (as long as it doesn't cause client crash.) |
| 20:42.12 | JeffM | no it should not cause a crash |
| 21:48.47 | *** join/#bzflag kierra (quassel@2600:3c03::f03c:91ff:fe93:2c7d) |
| 21:48.47 | *** join/#bzflag kierra (quassel@unaffiliated/kierra) |
| 21:48.49 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 22:07.12 | blast007 | JeffM: "Facebook acquires Oculus VR" well crap... ;) |
| 22:11.16 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 22:12.33 | JeffM | blast007, yeah my thoughts exactly |
| 22:12.40 | JeffM | I kinda want to cancel my order |
| 22:13.02 | JeffM | but that means John Carmak works for Facebook now, and that is messed up |
| 22:13.09 | blast007 | yeah..... |
| 22:13.27 | JeffM | hopefuly they let them run by themselves |
| 22:13.37 | JeffM | and just use them to add value to the stock |
| 22:14.43 | blast007 | "To install drivers for the Oculus Rift, please log into Facebook. Not a member? Sign up for free!" |
| 22:14.50 | blast007 | </nightmare> |
| 22:15.08 | JeffM | My realistic guess is that it would not get to that point |
| 22:15.42 | JeffM | they probalby know facebook as a platform is doomed and want to get in on something else to keep them going |
| 22:16.41 | blast007 | heh... "To make matters worse, people who get this news while wearing an Oculus Rift headset can't even do a proper facepalm." |
| 22:17.07 | blast007 | maybe it's an early April 1 joke? |
| 22:17.15 | JeffM | probably not |
| 22:17.18 | blast007 | yeah ;) |
| 22:19.35 | JeffM | They do need some things to diversify. They want to be content providers |
| 22:19.46 | JeffM | they just need to not screw it up as a company |
| 22:50.52 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:05.01 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 23:05.01 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 23:58.29 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |