| 00:05.58 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 00:14.59 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 00:15.34 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 00:36.21 | *** join/#bzflag xaver__ (~xaver@pD9ED5E26.dip.t-dialin.net) |
| 00:39.07 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 00:42.49 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:42.49 | *** mode/#bzflag [+v spldart] by ChanServ |
| 01:05.32 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 01:21.13 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 01:23.08 | *** join/#bzflag allejo (~allejo@pool-173-51-205-154.lsanca.fios.verizon.net) |
| 01:48.27 | *** join/#bzflag JeffM1 (~Jeff@adsl-75-50-184-13.dsl.lsan03.sbcglobal.net) |
| 01:51.58 | *** join/#bzflag allejo (~allejo@pool-173-51-205-154.lsanca.fios.verizon.net) |
| 02:16.20 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 02:21.37 | *** join/#bzflag Albino_ (~62d91f2d@gateway/web/freenode/x-locppsgccqavcfpx) |
| 02:42.55 | *** join/#bzflag TD-Linux (~wheeeeeee@about/essy/indecisive/TD-Linux) |
| 02:50.16 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 02:56.49 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 03:02.33 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 03:14.56 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 03:22.48 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 03:40.12 | *** join/#bzflag mrapple (~mrapple@bzflag/player/MrAppleComputer) |
| 03:52.18 | *** join/#bzflag Think_Differentl (~js@bzflag/player/ThinkDifferent) |
| 04:31.23 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 04:49.22 | *** join/#bzflag FyRe_STaRTeR (fyre@adsl-64-217-16-108.dsl.okcyok.swbell.net) |
| 04:56.32 | *** part/#bzflag FyRe_STaRTeR (fyre@adsl-64-217-16-108.dsl.okcyok.swbell.net) |
| 04:58.46 | *** join/#bzflag Legoguy (~Legoguy@S0106001ee54ac005.ed.shawcable.net) |
| 05:12.42 | *** join/#bzflag think_tank (~45aba331@gateway/web/freenode/x-fvmfyilcjjjbgbfy) |
| 05:13.53 | think_tank | is it worth asking what the problem is or has that horse already been beaten to death |
| 05:14.29 | blast007 | random hosts from China keep hitting the brlcad.org site |
| 06:26.05 | *** join/#bzflag Marzipan- (~Marzipan@p5B227898.dip.t-dialin.net) |
| 06:27.31 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:13.49 | *** join/#bzflag Upsetter (~Ups@89.246.172.128) |
| 07:36.09 | *** join/#bzflag Swigg_ (~Default@pool-74-97-222-150.grnvsc.dsl-w.verizon.net) |
| 07:42.51 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:00.45 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:09.11 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:17.58 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:31.27 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:44.13 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 08:58.02 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 09:05.32 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 09:11.12 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 09:36.48 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 09:46.17 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 09:52.54 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 10:08.46 | *** join/#bzflag Dontkillme (~chatzilla@frnk-590de0da.pool.mediaWays.net) |
| 10:26.10 | *** join/#bzflag xaver (~xaver@pD9ED5E26.dip.t-dialin.net) |
| 12:32.59 | brad | fyi: mysql down |
| 12:38.11 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 12:38.42 | randomparticle | global is a bit unwell |
| 12:39.14 | *** join/#bzflag menotume (~menotume@bzflag/contributor/menotume) |
| 12:39.14 | *** mode/#bzflag [+v menotume] by ChanServ |
| 12:40.27 | menotume | global down, mysql error :( |
| 12:41.01 | menotume | brlcad awake, or should i hack at it? :P |
| 12:41.09 | randomparticle | is that a coding bug? |
| 12:42.03 | brad | menotume: care for a pm? |
| 12:42.39 | randomparticle | shouldn't you wait until gordon has finished? |
| 12:42.46 | menotume | what is gordon doing ? |
| 12:42.52 | randomparticle | he's being pm |
| 12:42.55 | menotume | i'm not doing anything yet, just looking |
| 12:43.05 | randomparticle | but possibly won't be much longer |
| 12:43.17 | brad | >.< |
| 12:43.21 | brad | that was terrible snick |
| 12:43.31 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 12:43.33 | menotume | being pm ? |
| 12:43.36 | randomparticle | sorry. i can't resist the feeble efforts |
| 12:44.16 | kierra | you should talk at my place ;) |
| 12:45.16 | menotume | global fixed :P |
| 12:45.38 | kierra | :P |
| 12:52.52 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 12:55.36 | *** join/#bzflag randomparticle (~randompar@cpc2-wilm1-0-0-cust142.bagu.cable.ntl.com) |
| 12:55.36 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 13:31.13 | *** part/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 14:20.43 | blast007 | brlcad: could those PDF files be moved to a different web server...? |
| 14:21.15 | blast007 | fighting a losing battle here trying to block all of the hosts that are hitting them. |
| 14:23.44 | *** join/#bzflag bier (~bier@pD954F858.dip.t-dialin.net) |
| 14:24.24 | *** join/#bzflag bier|tp (~bier@pD954F858.dip.t-dialin.net) |
| 14:42.04 | *** join/#bzflag mrapple (~mrapple@c-69-180-173-220.hsd1.mn.comcast.net) |
| 14:42.04 | *** join/#bzflag mrapple (~mrapple@bzflag/player/MrAppleComputer) |
| 14:59.02 | *** join/#bzflag Dontkillme (~chatzilla@frnk-590de0da.pool.mediaWays.net) |
| 15:11.38 | *** join/#bzflag bryjen (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 15:11.38 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 15:35.54 | *** join/#bzflag temporalD (~ATD@bzflag/serverop/TemporalDistraction) |
| 16:00.46 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:16.43 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:23.25 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:24.39 | BulletCatcher | blast007, brlcad: an Apache module for limiting connections per IP address is at http://dominia.org/djao/limitipconn2.html |
| 16:32.18 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:39.56 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:52.17 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 16:57.17 | *** join/#bzflag JeffM2501 (~JeffM@bzflag/projectadmin/JeffM) |
| 16:57.17 | *** mode/#bzflag [+o JeffM2501] by ChanServ |
| 16:59.16 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 17:07.16 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 17:11.22 | *** join/#bzflag jcp (~jw@bzflag/contributor/javawizard2539) |
| 17:19.29 | CIA-32 | BZFlag: 03macsforme * r20994 10/branches/v2_0branch/bzflag/src/bzfs/CmdLineOptions.cxx: Incorrect player count errors (for -mp) should be outputted to stderr, not stdout. |
| 17:21.58 | CIA-32 | BZFlag: 03macsforme * r20995 10/trunk/bzflag/src/bzfs/CmdLineOptions.cxx: Incorrect player count errors (for -mp) should be outputted to stderr, not stdout. |
| 17:24.18 | JeffM2501 | Constitution, that work on windows? |
| 17:25.04 | Constitution | that's how the same file handles other errors... I have no idea about windows |
| 17:25.10 | JeffM2501 | ok |
| 17:25.21 | JeffM2501 | it may work since it's a CLI app |
| 17:25.32 | JeffM2501 | in the main client stderr dosn't output anything |
| 17:25.57 | Constitution | yeah it's used widely like that throughout the file |
| 17:26.23 | JeffM2501 | k |
| 17:26.27 | JeffM2501 | then all is well |
| 17:27.13 | JeffM2501 | well as well as can be for bzflag :) |
| 17:27.54 | Constitution | it came to light because bzfs was failing to start, and was not reporting the error since stdout is redirected to a log file |
| 17:29.01 | Constitution | and I just cat stderr to the startup web page (web admin interface) if bzfs fails to start... so anyway, less confusion now |
| 17:30.30 | Constitution | now that bzflag is good and well, as well as it can be, how is P2501? :) |
| 17:31.05 | JeffM2501 | heh "good and well" |
| 17:31.15 | JeffM2501 | I need to do the movement code |
| 17:31.19 | JeffM2501 | but I am stuck on it a little |
| 17:31.23 | JeffM2501 | so I may skip it |
| 17:32.15 | JeffM2501 | and just move on to shot and weapon transport |
| 17:34.21 | JeffM2501 | I'm sure I won't be able to finish it if I have to do it all on my own |
| 17:36.15 | Constitution | sounds like it's time to form "Jeffery Myers Gaming Innovations Ltd." and start recruiting |
| 17:36.32 | JeffM2501 | heh |
| 17:36.44 | JeffM2501 | recruting needs money :) |
| 17:37.16 | Constitution | sad how that is |
| 17:37.25 | JeffM2501 | people gotta eat |
| 17:37.27 | *** join/#bzflag me1 (~ausom@bzflag/player/Me1) |
| 17:37.29 | JeffM2501 | and sadly food is not free |
| 17:37.41 | JeffM2501 | change that and the world would be a very different place |
| 17:38.04 | Constitution | is not sure he would want to know what the world would be like then |
| 17:38.21 | JeffM2501 | hopefully it'd be a lot better |
| 17:38.31 | cygal | windows writes to stderr.txt, no? |
| 17:38.40 | JeffM2501 | in the client yeah |
| 17:39.02 | JeffM2501 | had to add that since apps that start with a winmain don't bring up a console window |
| 17:40.38 | JeffM2501 | you are more then welcome to grap the code for p2501 Constitution it's all in svn repos |
| 17:41.00 | Constitution | ok |
| 17:41.05 | Constitution | I have looked at it |
| 17:41.13 | JeffM2501 | and I think I found out why it didn't work well on the mac and linux |
| 17:41.19 | JeffM2501 | I forgot a file that they need :) |
| 17:45.55 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 17:52.39 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 17:59.30 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 18:07.19 | BulletCatcher | I have been looking at the trunk lag/jitter numbers problem. |
| 18:07.20 | BulletCatcher | So far, the only interesting thing I have found is that bzfs frequently processes two MsgPlayerUpdateSmall packets in a single main loop pass, which causes the second one to increase the reported jitter because it has the same server timestamp. |
| 18:08.15 | JeffM2501 | don't they have an ID? |
| 18:08.26 | JeffM2501 | so they don't get taken out of order? |
| 18:08.39 | BulletCatcher | It isn't an out-of-order problem. |
| 18:08.48 | JeffM2501 | just 2 at once? |
| 18:08.54 | cygal | why does it process two packets? |
| 18:09.09 | JeffM2501 | it probably got 2 during a frame |
| 18:09.13 | BulletCatcher | Jitter is computed by comparing client timestamp changes to server timestamp changes. |
| 18:09.22 | JeffM2501 | we should have it save all the updates it gets untill after the message loop |
| 18:09.34 | JeffM2501 | then process just the newest ones at |
| 18:09.35 | BulletCatcher | When bzfs processes two at once, they have the same server timestamp. |
| 18:09.39 | JeffM2501 | yeah |
| 18:10.26 | BulletCatcher | I see. I'll look at changing that. Fewer updates will make it smoother. |
| 18:10.27 | JeffM2501 | or if the current packets timestamp is the same as the last update then ignore it for jitter |
| 18:10.52 | BulletCatcher | That will be easy to do. I'll try that first. |
| 18:11.26 | JeffM2501 | did anyone review the lag code to see if it was changed for trunk ? |
| 18:11.51 | BulletCatcher | I see no relevant changes in the LagInfo class. |
| 18:12.42 | BulletCatcher | "diff" reports very few differences of any kind. |
| 18:13.38 | JeffM2501 | odd that the lag would be so much larger in trunk then |
| 18:13.56 | JeffM2501 | unless it was my changes to how the server handles messages |
| 18:14.48 | JeffM2501 | perhaps the map lookup takes a very long time |
| 18:15.12 | *** join/#bzflag I_Died_Once (~I_Died_On@c-98-244-158-51.hsd1.ga.comcast.net) |
| 18:23.53 | *** join/#bzflag Swigg (~Default@bzflag/player/Swigg) |
| 18:29.13 | BulletCatcher | Ignoring jitter updates when the server timestamp is unchanged cuts the average jitter from 10ms to 5ms via loopback. |
| 18:30.00 | BulletCatcher | Jitter numbers range from 4.2 to 6.5. |
| 18:31.52 | BulletCatcher | If 5 is the new zero then we could live with that, I suppose, but there must be something else in the way. |
| 18:31.54 | BulletCatcher | The new network handling code is my prime suspect. |
| 18:33.41 | BulletCatcher | I still haven't really looked at lag, the computation of which is completely independent of jitter. |
| 18:40.03 | trepan | an easy thing to try is to revert (completely), how timestamps are used |
| 18:40.34 | trepan | (ex: TimeKeeper::getCurrent() vs TimeKeeper::getTick(), and remove the getDRTime() stuff) |
| 18:42.12 | trepan | (note that v2_0branch's Player.cxx contains no getCurrent() calls) |
| 18:45.58 | BulletCatcher | I haven't gotten as far as looking at the client, yet. Indeed, there are many opportunities there for packet delays. |
| 18:47.29 | BulletCatcher | It could even be as simple as sending updates to the server at the end of the frame instead of earlier. |
| 18:53.08 | *** part/#bzflag Upsetter (~Ups@89.246.172.128) |
| 18:54.36 | BulletCatcher | In the bzfs main loop we call MSGMGR.update() near the end. IIRC that flushes outgoing data that will have been been queued earlier in the loop. |
| 18:55.34 | trepan | why is outbound data being queued? |
| 18:55.47 | trepan | (with the exception of filled system buffers ...) |
| 18:56.09 | BulletCatcher | That's the new network code. (If I recall correctly.) |
| 18:56.47 | blast007 | also, I had noticed that some messages are either being sent, received, or processed out of order. bzfs was processing the MsgPlayerData before the MsgEnter, which failed since it didn't have a player to assign the player data to |
| 18:58.14 | JeffM2501 | trepan, so that large groups of messages don't kill the transport |
| 18:58.25 | JeffM2501 | like banlist and the like, lets them trickle out |
| 18:58.52 | trepan | only need to queue them based on system buffers |
| 18:59.09 | trepan | (can use select() to detect when you can send more) |
| 18:59.24 | JeffM2501 | IIRC windows dosn't have a big system buffer |
| 18:59.27 | JeffM2501 | but whatever you say |
| 19:03.25 | trepan | buffer sizes seem to be set in NetHandler.cxx |
| 19:03.31 | trepan | UDP is 128K |
| 19:03.34 | trepan | TCP is 64K |
| 19:03.53 | JeffM2501 | then yank that code and fix it up |
| 19:04.08 | trepan | you did it, you fix it ;) |
| 19:04.15 | BulletCatcher | It would help if we could send UDP messages immediately rather than queuing. |
| 19:04.49 | JeffM2501 | too much has changed around it |
| 19:04.59 | trepan | might as well do the same for TCP, tbh |
| 19:06.30 | JeffM2501 | probalby can make a small change and have the buffer system send right away |
| 19:07.14 | JeffM2501 | cus a TON of stuff got moved over to the buffered network message class |
| 19:07.45 | BulletCatcher | More calls to MSGMGR.update() would be a proof-of-concept. |
| 19:08.14 | JeffM2501 | there may be a simpler thing |
| 19:08.25 | trepan | (like stick one in BufferedNetworkMessageManager::queueMessage()) |
| 19:08.42 | JeffM2501 | yeah |
| 19:09.25 | trepan | it's odd that that call looks up the 'msg' in the current 'pendingOutgoingMessages' (and places it in the back if it's already in there) |
| 19:09.35 | trepan | should that ever happen? |
| 19:09.49 | JeffM2501 | probably me just being paranoid |
| 19:10.41 | trepan | wonder if that has anything to do with the packet re-order blast mentionned, debug message :) |
| 19:11.05 | JeffM2501 | this is why I should not be allowed to write network code |
| 19:11.27 | *** join/#bzflag Yassen (Yassen@unaffiliated/yassen) |
| 19:12.30 | CIA-32 | BZFlag: 03JeffM2501 * r20996 10/trunk/bzflag/src/game/BufferedNetworkMessage.cxx: send messages when they are put into the buffer to see if that helps lag and crap |
| 19:12.44 | JeffM2501 | there, that should send right away |
| 19:14.24 | BulletCatcher | Unfortunately, it didn't help much. |
| 19:15.07 | JeffM2501 | if message manager is the problem then it will be hard to pull it's quite pervasive in the code |
| 19:17.44 | CIA-32 | BZFlag: 03trepan * r20997 10/trunk/bzflag/src/game/BufferedNetworkMessage.cxx: * added a debug message |
| 19:19.13 | trepan | note that NetHandler already seems to have buffered output |
| 19:19.38 | JeffM2501 | well then it wasn't working |
| 19:19.50 | trepan | bzfs.cxx/processConnectedPeer() -> sendBufferedNetDataForPeer() -> peer.netHandler->bufferedSend() |
| 19:19.53 | JeffM2501 | the message buffer was added to fix lockups when the server sent out big things |
| 19:20.35 | trepan | hm, sendBufferedNetDataForPeer also has it's own buffer, 'sendChunks' |
| 19:20.43 | trepan | (well, the 'peer' does) |
| 19:21.56 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 19:22.10 | trepan | triple buffering? isn't that what they do for smoother gfx? :) |
| 19:23.09 | *** join/#bzflag Think_Differentl (~js@bzflag/player/ThinkDifferent) |
| 19:25.34 | BulletCatcher | trepan: That debug message fires every time, as far as I can tell. |
| 19:28.12 | trepan | ah, yes, my bad |
| 19:28.28 | trepan | pendingOutgoingMessages vs. outgoingQueue ... |
| 19:31.43 | CIA-32 | BZFlag: 03trepan * r20998 10/trunk/bzflag/src/game/BufferedNetworkMessage.cxx: |
| 19:31.43 | CIA-32 | BZFlag: * removed the debug message from r20997, |
| 19:31.43 | CIA-32 | BZFlag: (pendingOutgoingMessages vs. outgoingQueue, mucho queueing) |
| 20:00.56 | *** join/#bzflag xaver (~xaver@pD9ED5E26.dip.t-dialin.net) |
| 20:01.31 | *** join/#bzflag xaver__ (~xaver@pD9ED5E26.dip.t-dialin.net) |
| 20:09.36 | *** join/#bzflag xaver (~xaver@pD9ED5E26.dip.t-dialin.net) |
| 20:16.48 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 20:22.55 | CIA-32 | BZFlag: 03bullet_catcher * r20999 10/trunk/bzflag/src/game/LagInfo.cxx: |
| 20:22.55 | CIA-32 | BZFlag: Log details of lag and jitter updates. |
| 20:22.55 | CIA-32 | BZFlag: Ignore jitter updates when the server timestamp is unchanged. |
| 20:24.36 | BulletCatcher | The jitter updates occur every update, so bzfs -ddddd is quite noisy. |
| 20:42.46 | temporalD | 5 d's ? |
| 20:45.14 | BulletCatcher | It enables level 5 debug messages. |
| 20:49.45 | temporalD | ok - that's new to me - thx |
| 20:50.52 | BulletCatcher | I run my server with -dd to get level 2 messages for the log file. |
| 20:51.13 | BulletCatcher | joins, chat, etc. |
| 20:51.13 | *** join/#bzflag Swigg (~Default@bzflag/player/Swigg) |
| 20:54.06 | *** join/#bzflag R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:02.50 | trepan | fwiw, -d5 = -ddddd (v2.99, server & client) |
| 21:15.34 | *** join/#bzflag Packman (~chatzilla@125-236-135-85.jetstream.xtra.co.nz) |
| 21:16.54 | Packman | is there a config or server variable option that specifies how often super flags are automatically reset? |
| 21:17.31 | blast007 | _maxFlagGrabs controls the maximum number of times a flag can be picked up before it respawns somewhere else |
| 21:18.01 | Packman | but there's no /reset flags every minute? |
| 21:18.05 | blast007 | no |
| 21:18.22 | blast007 | a plugin could do it though |
| 21:18.28 | blast007 | but I wouldn't recommend resetting them *all* |
| 21:18.33 | blast007 | at least at the same time |
| 21:19.05 | Packman | is there a way to keep flags in a zone meaning they can't be dropped outside? |
| 21:19.29 | Packman | you can make flags spawn in a zone but you can't prevent them from being 'taken' outside, if you have several maxflaggrabs |
| 21:19.49 | blast007 | there's a flagStay plugin that makes you drop specific flag types if you leave a certain area |
| 21:20.14 | blast007 | that one is even bundled with the source, afaik |
| 21:20.50 | Packman | ok, thank you |
| 21:21.08 | blast007 | might be a wiki page on it |
| 21:21.27 | blast007 | there doesn't seem to be any documentation on it in the provided README.txt |
| 21:22.59 | *** join/#bzflag Yassen (Yassen@unaffiliated/yassen) |
| 21:23.56 | Packman | i found it at http://my.bzflag.org/w/FlagStay |
| 21:24.55 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 21:28.17 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 21:31.01 | temporalD | Packman: there is a really really buggy "bzcron" plugin that can run commands on a schedule |
| 21:31.19 | temporalD | mofo runs it and it fails to load about 70% of the time |
| 21:31.35 | Packman | heh |
| 21:31.43 | blast007 | really hackish too |
| 21:32.21 | blast007 | it basically makes the server connect to itself as an observer, then gives that observer admin rights so it can run stuff ;) |
| 21:32.49 | Packman | any idea if bboxes can be combined within the same plugin-supported object? |
| 21:33.06 | CIA-32 | BZFlag: 03bullet_catcher * r21000 10/trunk/bzflag/src/game/MsgStrings.cxx: Clarify the output when messages are not decoded in detail. |
| 21:33.21 | blast007 | Packman: you'd have to check the plugin source |
| 21:58.59 | CIA-32 | BZFlag: 03bullet_catcher * r21001 10/trunk/bzflag/src/ (bzfs/bzfs.cxx game/BufferedNetworkMessage.cxx): |
| 21:58.59 | CIA-32 | BZFlag: With -DDEBUG, log sent and received messages except for MsgPlayerUpdateSmall. |
| 21:58.59 | CIA-32 | BZFlag: Add FIXME on r20996 change. |
| 21:58.59 | CIA-32 | BZFlag: Log when player updates are out of order and ignored. |
| 22:00.43 | BulletCatcher | That should be the server side of what is needed to help analyze out-of-order message processing, blast007. |
| 22:05.28 | blast007 | k |
| 22:24.47 | *** join/#bzflag JeffM1 (~Jeff@adsl-75-50-184-13.dsl.lsan03.sbcglobal.net) |
| 23:04.49 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |
| 23:05.17 | *** join/#bzflag JeffM (~Jeff@bzflag/projectadmin/JeffM) |
| 23:05.17 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 23:15.25 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 23:15.25 | *** mode/#bzflag [+v joevano] by ChanServ |
| 23:16.59 | *** join/#bzflag allejo (~allejo@pool-173-51-205-154.lsanca.fios.verizon.net) |
| 23:20.05 | *** join/#bzflag chaoscon (~jeremy@smartserv/ceo/chaoscon) |