| 02:57.33 | *** join/#bzflag horribleprogram (~horriblep@unaffiliated/nightcoder) |
| 05:44.53 | *** join/#bzflag User49 (~User49@unaffiliated/user49) |
| 07:39.24 | *** join/#bzflag FieldSobers (~User49@unaffiliated/user49) |
| 16:46.27 | *** join/#bzflag Agatha_ (~agatha@2601:681:527f:e8f0:992d:8a26:e1c6:b88a) |
| 18:04.59 | *** join/#bzflag Sgeo (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 18:08.25 | *** join/#bzflag Zehra (~Keiki_Han@unaffiliated/zehra) |
| 19:39.54 | BZNotify | bzflag: 03atupone commented on pull request #259 "Buffer udp" (06https://git.io/JUuYQ): > Given that this PR is in two parts, one of which breaks existing ... |
| 20:35.20 | BZNotify | bzflag: 03jwmelto commented on pull request #259 "Buffer udp" by 03atupone (06https://git.io/JUuOM): My point is, the PR is applied to the **code base** (both server an... |
| 20:44.54 | BZNotify | bzflag: 03blast007 commented on pull request #264 " Reset CFLAGS and CXXFLAGS to a previous value to fix the large release builds." (052.4.22 - 06https://git.io/JUuOj): I'll need to take a close look at the configure.ac file. It do see... |
| 20:45.31 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 20:45.31 | *** mode/#bzflag [+v allejo] by ChanServ |
| 20:45.32 | *** join/#bzflag kierra (~quassel@104.243.40.186) |
| 20:55.12 | BZNotify | bzflag: 03macsforme commented on pull request #259 "Buffer udp" by 03atupone (06https://git.io/JUu38): Why is this going into 2.4 at all? The more we add to 2.4, the mor... |
| 21:07.18 | *** join/#bzflag kierra (~quassel@104.243.40.186) |
| 21:07.21 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 21:07.21 | *** mode/#bzflag [+v allejo] by ChanServ |
| 21:13.30 | *** join/#bzflag kierra (~quassel@104.243.40.186) |
| 21:13.33 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 21:13.33 | *** mode/#bzflag [+v allejo] by ChanServ |
| 21:16.33 | *** join/#bzflag kierra (~quassel@104.243.40.186) |
| 21:16.35 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 21:16.35 | *** mode/#bzflag [+v allejo] by ChanServ |
| 21:18.47 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 21:34.59 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 21:35.19 | Zehra | Quick question, under any circumstances, should the "rabbit" be inconsistent in the client(s)? |
| 21:35.41 | Zehra | (nvm, seems wrong display on my end.) |
| 21:35.48 | JeffM[m] | "should" or "can" ? |
| 21:36.01 | JeffM[m] | why is 2.4 not locked from changes? |
| 21:37.13 | JeffM[m] | or actually can you even lock a branch on github? |
| 21:37.43 | Zehra | *can* would be the precise definition. (Was checking in the rabbit selection algorithm.) |
| 21:38.08 | JeffM[m] | yes, there is a message, and a client could not receive it, just like any packetloss case |
| 21:43.16 | *** part/#bzflag kierra (~quassel@104.243.40.186) |
| 21:45.21 | *** join/#bzflag moriah (~quassel@unaffiliated/kierra) |
| 22:19.14 | Zehra | I'm finding something a bit inaccurate with the death event in "flagHeldWhenKilled", since even though it might have been dropped earlier. |
| 22:19.22 | Zehra | It lists it as being held. :/ |
| 22:26.03 | Zehra | I'm sort of expecting that the player has not dropped the flag when killed. |
| 22:26.36 | Zehra | Vs having recently held the flag before death as an addition. |
| 22:27.01 | Zehra | Otherwise I'd register 2/3 additional events. |
| 22:48.55 | *** join/#bzflag PrezKennedy (~PrezKenne@d-216-36-14-123.md.cpe.atlanticbb.net) |