| 00:55.20 | *** join/#bzflag Gabe_G23 (n=Gabe_G23@cpe-069-134-026-246.nc.res.rr.com) |
| 01:10.36 | *** join/#bzflag whodaman (n=whodaman@about/apple/macbook/whodaman-) |
| 01:11.11 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 01:33.36 | JeffM | how do reports get cleared? all at once? or one at a time? |
| 01:38.27 | blast007 | there is no method to clear them afaik, besides deleting/editing the report file |
| 01:53.49 | *** join/#bzflag Wits_ (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 02:18.57 | TheRedBaron | correct |
| 02:19.02 | TheRedBaron | on the /report issue |
| 02:27.29 | *** join/#bzflag whodaman (n=whodaman@about/apple/macbook/whodaman-) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag [dmp] (n=dennis@dryas.d75.net) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag eTangenT (i=etangent@inge069019.halls.colostate.edu) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag pacman87 (n=Timothy@resnet-45-219.dorm.utexas.edu) |
| 02:27.29 | *** join/#bzflag wegstar_ (i=wegstar@2306ds2-hvi.1.fullrate.dk) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag QuantumTim (n=tim@62-249-230-206.no-dns-yet.enta.net) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag donny_baker (n=joevano@about/essy/vvvvv/donnybaker) [NETSPLIT VICTIM] |
| 02:27.29 | *** join/#bzflag catay (n=smertens@kaiya.catay.be) |
| 02:27.30 | *** mode/#bzflag [+v donny_baker] by irc.freenode.net |
| 03:13.23 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 03:29.08 | *** join/#bzflag L4m3r (n=l4m3r@about/essy/warning/L4m3r) |
| 03:29.08 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 03:34.23 | JeffM | time to redo the report system :) |
| 03:34.32 | *** join/#bzflag bier_ (n=bier@p54A55022.dip.t-dialin.net) |
| 03:36.30 | *** join/#bzflag cosmos (n=cosmos@valentino.hepcat.org) |
| 03:37.45 | JeffM | do ANY servers have more then one bzfs instance using the same report file? |
| 03:37.52 | JeffM | or do those people use the report pipe? |
| 03:38.13 | blast007 | I doubt many people use the report pipe |
| 03:38.23 | blast007 | not sure about sharing the report file |
| 03:38.31 | blast007 | seems like it would be a bad idea anyway |
| 03:38.38 | JeffM | it woudl be hard to know what report came from what server |
| 03:38.42 | blast007 | yeah |
| 03:38.52 | JeffM | ok, then that makes this a little easier |
| 03:39.15 | blast007 | "/report The map has a bug by the top teleporter!" "Crud, which map.." |
| 03:39.59 | JeffM | reports are going into there own source file, and getting the ability to be indexed and iterated ;) |
| 03:51.29 | *** join/#bzflag bier__ (n=bier@pD9E2DA66.dip.t-dialin.net) |
| 03:56.02 | *** join/#bzflag noyb (n=noyb@nat/sun/x-90e54040691c0716) |
| 04:10.29 | JeffM | ok when you do /viewreports some_text, is it expected that text be something in the body of the report, or the user or both? |
| 04:12.24 | blast007 | heh... didn't even realize that viewreports could take a pattern |
| 04:12.44 | JeffM | yeah |
| 04:12.47 | blast007 | currently works for both username and the report text |
| 04:12.55 | JeffM | it's the entire line |
| 04:13.02 | JeffM | if you search for "reported by" you' |
| 04:13.02 | blast007 | yeah, figured |
| 04:13.06 | JeffM | you'll get em all ;) |
| 04:13.12 | blast007 | hehe |
| 04:13.36 | JeffM | but I'm changing how they are stored and returned, so should it be just name or body, or both? |
| 04:14.14 | blast007 | probably both |
| 04:14.25 | JeffM | k |
| 04:14.48 | JeffM | the report stuff is writen ALL wackass |
| 04:23.45 | JeffM | oh look, the function just got shorter too :) |
| 04:24.09 | blast007 | :) |
| 04:29.47 | *** join/#bzflag spldart (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 04:29.47 | *** mode/#bzflag [+v spldart] by ChanServ |
| 04:32.04 | cosmos | spldart |
| 04:33.18 | spldart | Cosmos! |
| 04:37.42 | short_circuit | cuz my connection still totally suxors |
| 04:38.58 | cosmos | heh |
| 04:39.03 | cosmos | whqts new |
| 04:40.55 | short_circuit | Brand new? Putting the world back together after hurricane ike. Not so new? finding a new confortable routine to get into ;) |
| 04:42.09 | cosmos | hurricanes ouch |
| 04:43.16 | short_circuit | I find I'm becoming one of the moldy oldies.. Pining for the days of hepcat and spirals. hehehe |
| 04:44.00 | cosmos | i was asked to bring hepcat back |
| 04:44.35 | cosmos | which was kind of cool |
| 04:45.22 | short_circuit | Unfortunately most of the newbs wont appreciate it :-\ |
| 04:47.11 | L4m3r | cosmos: I could probably talk the mofos into hosting you if you want to bring it back. Any attempt to re-populate the maps has failed, ever since silvercat went down |
| 04:49.45 | short_circuit | Wow... It seems like I've been in longer than what bzbb says.... 3.5 years orso. The caps on babylon, towers and pillbox seem so long ago now. |
| 04:49.57 | cosmos | heh |
| 04:50.25 | cosmos | well we played bzflag on the sgi clusters in the 90s |
| 04:50.31 | cosmos | but i set up my first server in 2003 |
| 04:50.38 | cosmos | brb |
| 04:51.41 | short_circuit | k, Man... I hosted my first server on Windows 98 SE. Then XP then Debian sarge and finally etch.. can 3.5 years + be right?!?! I must be in the dark ages |
| 04:52.46 | short_circuit | Huh.. that reminds me.. I need to try the latest lenny again soon. |
| 04:53.24 | short_circuit | BTW.. Pogo says "Wow... Long time no see" |
| 04:55.45 | a_meteorite | hi pogo |
| 04:56.34 | Flash | wow. haven't seen cosmos in ages! |
| 05:03.41 | JeffM | wheee, now the reports source file got bigger :) |
| 05:08.21 | CIA-48 | BZFlag: 03JeffM2501 * r18697 10/trunk/bzflag/ (10 files in 4 dirs): |
| 05:08.21 | CIA-48 | BZFlag: Take the report system out of commands.cxx and move it to a reports class in it's own files. |
| 05:08.21 | CIA-48 | BZFlag: change the report system to be more consistent in it's function, and provide methods for access to individual reports |
| 05:08.21 | CIA-48 | BZFlag: add methods to clear reports individually or en-masse |
| 05:08.23 | CIA-48 | BZFlag: expose the new report system to the API. |
| 05:08.41 | JeffM | all that just so I could make something in a plugin..... |
| 05:29.02 | short_circuit | bzzt |
| 05:32.53 | *** join/#bzflag KingofCamelot (i=KingofCa@ip68-6-42-246.sb.sd.cox.net) |
| 05:33.00 | Flash | we are anti-exception throwing, right? |
| 05:33.16 | Flash | KingofCamelot..... sounds familiar.... |
| 05:35.06 | Flash | logs.cpp:253: warning: cannot pass objects of non-POD type 'class bz_ApiString' through '...'; call will abort at runtime |
| 05:35.18 | JeffM | bahh |
| 05:40.25 | JeffM | fixed but no CIA |
| 05:41.10 | Flash | compiles cleanly, at least |
| 05:45.30 | CIA-48 | BZFlag: 03bryjen * r18699 10/trunk/bzflag/src/bzfs/ (bzfs.cxx bzfs.h commands.cxx): make global variable name less generic |
| 05:46.00 | CIA-48 | BZFlag: 03bryjen * r18700 10/trunk/bzflag/src/bzfs/ (Reports.cxx Reports.h reports.cxx reports.h): filename case |
| 05:46.29 | JeffM | bryjen: they didn't get added as uppercase? |
| 05:46.48 | bryjen | no, all lower |
| 05:46.58 | JeffM | suck |
| 05:47.13 | JeffM | initaly I made them lower, then saw my mistake, renamed them to upper, THEN added them to svn |
| 05:53.54 | KingofCamelot | @Flash...yea, long time no BZFlag IRC. :P Been quite busy. |
| 06:08.34 | CIA-48 | BZFlag: 03JeffM2501 * r18701 10/trunk/bzflag/plugins/webadmin/ (loops.cpp loops.h templates/Reports.page webadmin.vcproj): add reports page and associated loop |
| 06:16.32 | JeffM | what perm lets you /report? |
| 06:16.48 | JeffM | is it just talk? |
| 06:19.10 | Flash | yes |
| 06:19.25 | Flash | <PROTECTED> |
| 06:19.33 | JeffM | thanks |
| 06:19.38 | JeffM | didn't have my main tree up |
| 06:22.15 | CIA-48 | BZFlag: 03JeffM2501 * r18704 10/trunk/bzflag/plugins/webadmin/ (actions.cpp actions.h templates/Reports.page webadmin.cpp): add action and templates to file a report |
| 07:07.15 | *** join/#bzflag Legoguy_ (n=Legoguy@adsl-71-143-234-54.dsl.emhril.sbcglobal.net) |
| 07:18.23 | *** join/#bzflag Gilly (n=btw@83.146.211.140) |
| 07:31.03 | brlcad | TheRedBaron: oops! sorry I totally forgot to respond earlier |
| 07:31.10 | brlcad | (i didn't have a few minutes at the time) |
| 07:31.31 | brlcad | wasn't intentionally ignoring you |
| 08:39.46 | *** join/#bzflag Skeeve (n=Skeeve@p508A3D7E.dip.t-dialin.net) |
| 08:40.02 | Skeeve | JeffM? Are you still around? |
| 08:46.36 | whodaman | not in the channel :P |
| 08:58.23 | *** join/#bzflag Upsetter (n=ups@i577B54E8.versanet.de) |
| 10:03.24 | *** join/#bzflag MPS_ (n=mathias@217.116.120.21) |
| 10:13.39 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 10:30.56 | *** join/#bzflag LongDon (n=LongDon@host-091-097-004-032.ewe-ip-backbone.de) |
| 11:02.53 | *** part/#bzflag LongDon (n=LongDon@host-091-097-004-032.ewe-ip-backbone.de) |
| 12:54.52 | *** join/#bzflag swigg (n=Paul@71-14-108-006.dhcp.gnvl.sc.charter.com) |
| 13:04.30 | *** join/#bzflag KTL (n=KTL@213.219.161.42.adsl.dyn.edpnet.net) |
| 13:09.51 | *** join/#bzflag CIA-48 (n=CIA@208.69.182.149) |
| 13:11.34 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 13:14.53 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 13:14.53 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 14:09.48 | *** join/#bzflag JBdiGriz (n=dbw@adsl-75-36-36-49.dsl.sndg02.sbcglobal.net) [NETSPLIT VICTIM] |
| 14:09.48 | *** join/#bzflag Upsetter (n=ups@i577B54E8.versanet.de) [NETSPLIT VICTIM] |
| 14:09.48 | *** join/#bzflag short_circuit (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 14:09.49 | *** join/#bzflag noyb (n=noyb@nat/sun/x-90e54040691c0716) [NETSPLIT VICTIM] |
| 14:09.49 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 14:09.50 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.155) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag cods (n=cods@rsbac/developer/cods) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag trepan (n=trepan@unaffiliated/trepan) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag Deepa|AFK (i=deepa@abused.armchairs.be) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag AAA_awright (n=acubed@wsip-70-184-126-222.ph.ph.cox.net) |
| 14:09.50 | *** join/#bzflag F687s (n=noah@cpe-98-30-181-122.woh.res.rr.com) |
| 14:09.50 | *** join/#bzflag Pryon (n=Pryon@irc.animalcules.com) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag Manu (n=jujibo@about/essy/JujiboHunter/Manu) |
| 14:09.50 | *** mode/#bzflag [+ovvo JBdiGriz short_circuit trepan Manu] by irc.freenode.net |
| 14:09.50 | *** join/#bzflag brad (n=brad@static.moooo.org) |
| 14:09.50 | *** join/#bzflag chaoscon (i=jeremy@smartserv/ceo/chaoscon) |
| 14:09.50 | *** join/#bzflag jorgenpt (n=jorgenpt@tjer.no) [NETSPLIT VICTIM] |
| 14:09.50 | *** join/#bzflag Birdie (n=Birdie@unaffiliated/birdie) |
| 14:09.50 | *** mode/#bzflag [+v Manu] by irc.freenode.net |
| 14:10.24 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 14:26.04 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 15:05.47 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.155) |
| 15:17.14 | *** join/#bzflag JBdiGriz (n=dbw@adsl-75-36-36-49.dsl.sndg02.sbcglobal.net) [NETSPLIT VICTIM] |
| 15:17.14 | *** join/#bzflag cods (n=cods@rsbac/developer/cods) [NETSPLIT VICTIM] |
| 15:17.14 | *** join/#bzflag Manu (n=jujibo@about/essy/JujiboHunter/Manu) |
| 15:17.14 | *** join/#bzflag F687s (n=noah@cpe-98-30-181-122.woh.res.rr.com) |
| 15:17.15 | *** join/#bzflag Pryon (n=Pryon@irc.animalcules.com) [NETSPLIT VICTIM] |
| 15:17.15 | *** mode/#bzflag [+oov JBdiGriz Manu Manu] by irc.freenode.net |
| 15:17.40 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.155) |
| 15:53.51 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 16:24.02 | *** join/#bzflag short_circuit (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 16:31.35 | Skeeve | New patch for 2.0.13 submitted - please feel free to test |
| 16:31.40 | Skeeve | http://my.bzflag.org/bb/viewtopic.php?p=129419#129419 |
| 16:39.34 | blast007 | why 2.0.x? that version is dead. |
| 16:40.19 | JeffM | cus he wants to use it, and is scared to add the requred messages to the server for 3.0 |
| 16:40.35 | JeffM | parsing the text is not a good way to do it, specialy if it gets translated ;) |
| 16:41.02 | JeffM | goes to work |
| 16:54.13 | temp_dist | Skeeve: I had to remove the first level of the path from your patch |
| 16:54.23 | temp_dist | started the paths with src/bzflag |
| 16:54.31 | temp_dist | then it built fine and works in game |
| 17:02.46 | Skeeve | of course, temp_dist. patch -p1 will do so. |
| 17:03.24 | temp_dist | hehe - ok then |
| 17:09.58 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:10.55 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 17:13.43 | Skeeve | blast007: 2.0.x isn't dead. It's still used. And as long as no 3.0 release date is announcend, I don't think developing for that is something for me. |
| 17:14.57 | Skeeve | JeffM: Parsing is the only way I can do it. If the message gets translated, the client will have to be translated too. BTW: The password request message is also "parsed". So I did it as the developers did ;-) |
| 17:15.35 | *** join/#bzflag Saturos (n=Saturos@i59F77727.versanet.de) |
| 17:20.18 | JeffM | Skeeve, I know |
| 17:20.50 | JeffM | Skeeve, actualy there is a patch that does dynamic translations |
| 17:21.04 | JeffM | I was simply answering blast's question as accurately as I could |
| 17:21.10 | JeffM | not fault on your part, just the way it is :) |
| 17:25.54 | *** join/#bzflag red-der (n=chatzill@pD9E2C33D.dip.t-dialin.net) |
| 17:27.27 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:30.32 | *** join/#bzflag Erroneous (n=dtremena@about/essy/CrazyCoder/DTRemenak) |
| 17:30.32 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 17:31.39 | red-der | are there some badwordfiles I can download somewhere or do I have to make them myself? |
| 17:32.25 | JeffM | should be one in the misc dir in the source tree |
| 17:33.04 | red-der | thanks |
| 17:43.53 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 17:45.18 | Skeeve | JeffM Is the translation done BEFORE the client gets tehm? |
| 17:45.50 | JeffM | usualy after |
| 17:46.00 | JeffM | so yeah it could be made to work |
| 17:46.06 | JeffM | if you get it early enough |
| 17:46.10 | Skeeve | So maybe it already might work. |
| 17:46.14 | JeffM | still a better thing is a MsgShotsLeft ;) |
| 17:46.37 | Skeeve | Sure. But that really is something for 3.0 |
| 17:46.59 | JeffM | thats what we were talking about |
| 17:47.12 | JeffM | blast007 was speaking about "why not 3.0" |
| 17:47.17 | JeffM | that's honestly all we care about here |
| 17:47.44 | Skeeve | But as you (you developers not you Jeff) still fiddle around with the protocol and where to put the shot tracking and how to design the HUD, I don't think a patch would be too helpful, don't you agreee? |
| 17:48.07 | JeffM | depends on how much is in the patch |
| 17:48.15 | JeffM | if your patch adds the message, then yeah it's useufll |
| 17:48.22 | JeffM | but you said you would not touch te server |
| 17:48.25 | JeffM | so that ends that |
| 17:49.28 | Skeeve | That was in regards to 2.0. I think, touching 3.0 servers is feasible. But then I'd need someone willing to help in testing, i.e. setting up a server and checking the server side. At least I guess so |
| 17:49.57 | Skeeve | I didn't want to touch 2.0 servers as I'msure no one will exchange his server just to enable my patch |
| 17:50.31 | JeffM | you can't hit 2.0 servers anyway, it' make the clients incombatable |
| 17:50.46 | JeffM | you can not run a local server for testing? |
| 17:51.07 | Skeeve | I don't know. Can I? |
| 17:51.31 | JeffM | it's just an executable, why could you not run it? |
| 17:52.20 | Skeeve | No one can connect, just me. No one (with experience) can look into the logs or whatever to see whether it still works properly? |
| 17:52.40 | JeffM | you could set a shot limit on a flag and make sure it worked ;) |
| 17:52.42 | JeffM | but it's ok |
| 17:52.48 | JeffM | sounds like it's outside of your comfort zone |
| 17:52.51 | JeffM | no worries |
| 17:53.16 | Skeeve | I wouldn't even know how to do that. I can learn it, sure. But then: That sounds like WORK ;-) |
| 17:54.11 | Skeeve | BTW: Why not put the flag limit into the data that's send to the client when downloading the world? |
| 17:54.26 | Skeeve | Or should it be a dynamically changable value? |
| 17:54.27 | JeffM | because when flag limits were added, it was a hack |
| 17:54.32 | JeffM | and yes it should be dynamic |
| 17:54.55 | L4m3r | I think the "hack" aspect is for the best |
| 17:54.58 | JeffM | shot limits were added after 2.0 was released so the only way to make it work on old clients is to hav the server just force a drop |
| 17:55.01 | L4m3r | since everything is serverside |
| 17:55.09 | Skeeve | So why not put it as an attribute to the flags? Then no message would be needed, as the client can keep track |
| 17:55.25 | L4m3r | do we WANT the client to keep track? sounds like a step backwards :) |
| 17:55.30 | Skeeve | no |
| 17:55.31 | JeffM | L4m3r, yes I'd keep it server side, but I'd also send out a message to tell the client what to display |
| 17:55.36 | L4m3r | exactly |
| 17:55.36 | Skeeve | The server keeps track too |
| 17:55.49 | JeffM | Skeeve, because what if you want to add shots with out picking up a flag |
| 17:55.55 | JeffM | a flag event is not the only thing |
| 17:55.56 | Skeeve | But why send a message after each shot? |
| 17:56.03 | JeffM | I'd not send one for each shot |
| 17:56.09 | L4m3r | modify the limit on-the-fly |
| 17:56.13 | JeffM | I'd send one on pickup |
| 17:56.24 | JeffM | and assume the client will make the same countdown as the server |
| 17:56.36 | L4m3r | for instance, you could limit shots dynamically based on the number of players on the server |
| 17:56.44 | JeffM | unless they get MORE or LESS shots from some other thing (server logic, or plugin) then resend the limit |
| 17:56.48 | Skeeve | okay. So we talk about the same idea, jeff. I thought that each individual flag could get that attribute |
| 17:57.08 | JeffM | no, that limits the shots limits to only going with flags |
| 17:57.16 | Skeeve | okay |
| 17:57.20 | Skeeve | understood |
| 17:57.25 | JeffM | what if I want to add a plugin that "reloads" you with a zone? |
| 17:57.35 | JeffM | how do I send you more shots for your existing flag? |
| 17:57.38 | Skeeve | so it's basically what I implemented, just another message that needn't be parsed |
| 17:57.58 | JeffM | you implemented a better display for the current hack |
| 17:58.01 | JeffM | that's not a bad thing |
| 17:58.16 | Skeeve | Thanks ;-) |
| 17:58.20 | JeffM | but if we are going to do it for real, we should do it right in the most usefull way |
| 17:58.48 | Skeeve | So should we decide upon that now and I try to reinvent the 3.0 wheel? ;-) |
| 17:58.58 | JeffM | it's not a wheel |
| 17:59.04 | Skeeve | Just a joke |
| 17:59.07 | JeffM | I've just told you how I want it done |
| 17:59.11 | JeffM | MsgShotLimit |
| 17:59.17 | JeffM | it has a time and a limit |
| 17:59.31 | Skeeve | define time |
| 17:59.37 | JeffM | server clock |
| 17:59.38 | JeffM | time |
| 17:59.50 | JeffM | when the limit was in effect |
| 17:59.54 | Skeeve | ah! To keep clinets in sync? |
| 18:00.08 | JeffM | that way if the client shoots during the lag it can know that it "used one" |
| 18:00.09 | JeffM | yeah |
| 18:00.17 | JeffM | this is a network game ;) |
| 18:00.37 | Skeeve | See⦠here come the difficulties I have ;-) |
| 18:01.50 | JeffM | Timekeeper::getCurrent().getSeconds() |
| 18:01.54 | Skeeve | So there is, for each shot, a time when it was fired? |
| 18:01.57 | JeffM | no |
| 18:02.07 | JeffM | you have to track that on the client in the shot tracker you have to write |
| 18:02.17 | JeffM | with the ServerSyncedClock |
| 18:02.51 | Skeeve | I feel that's way over my current abilities |
| 18:03.05 | JeffM | best way to expand them is to learn |
| 18:03.16 | Skeeve | If I do it, someone (you know him!) wil HAVE TO cross check it |
| 18:03.30 | JeffM | sure all patches are reviewed before they are applied |
| 18:04.22 | Skeeve | I'll think about it |
| 18:08.22 | Skeeve | BTW: Is there a way to apply patches to the svn tree? I'd like to see my 16-Button switch applied to 2.0 - even if it's regarded "dead". Should there ever be a 2.0.14, it would be in there like it is in 3.0. And also the shotguide patch that's already in 3.0 could be added to 2.0.13. |
| 18:08.49 | JeffM | sure we can apply them |
| 18:08.51 | JeffM | but won't |
| 18:08.57 | Skeeve | That would be GREAT! |
| 18:09.01 | Skeeve | Argh. |
| 18:09.05 | Skeeve | Why? |
| 18:09.07 | JeffM | if there is a .14 it will ONLY contain what ever bug fix forces 14 |
| 18:09.11 | JeffM | because we want to move forward |
| 18:09.22 | JeffM | if we spend too much time working on 2.0.x we'll never be rid of it |
| 18:09.31 | JeffM | .12 was only to fix a linux build problem |
| 18:09.50 | Skeeve | *sigh* |
| 18:09.51 | JeffM | there are tons of things I could put into a .14 but then I'd never get 3.0 out |
| 18:09.59 | JeffM | at some point you have to just let go |
| 18:10.11 | JeffM | 3.0 is way late as is |
| 18:10.31 | Skeeve | Are there already servers running? |
| 18:10.36 | JeffM | sure |
| 18:10.45 | Skeeve | I mean: In real use by players? |
| 18:10.47 | JeffM | no |
| 18:10.48 | L4m3r | not really |
| 18:10.50 | JeffM | dev servers |
| 18:10.51 | L4m3r | just test servers |
| 18:11.02 | JeffM | players won't swap untill we release it |
| 18:11.10 | JeffM | that's why we have to push to get it done and released |
| 18:11.19 | JeffM | rather then constantly patching an old buggy protocoll |
| 18:11.22 | L4m3r | most of them, anyway |
| 18:11.30 | L4m3r | I think there are still people playing 1.10 :P |
| 18:11.41 | JeffM | those people ALSO have 2 |
| 18:11.45 | JeffM | some play the older ones for fun |
| 18:11.54 | Skeeve | If my Indy were up and running, I'd be playing 1.1 too I guess ;-) |
| 18:11.56 | JeffM | but if we release then the majority of games will move |
| 18:12.17 | JeffM | 1.1 was pre open source |
| 18:12.38 | Skeeve | I have the original CD, I think |
| 18:13.49 | Skeeve | I have this http://popcorn.cx/computers/sgi/indy/indy-r5000-01.jpg computer in my cellar |
| 18:14.09 | JeffM | I have an O2 under my desk |
| 18:15.04 | Skeeve | Great! I was allowed to take my Indy home when I got the O2 at work |
| 18:15.18 | Skeeve | But that's way back in 1998 or so |
| 18:24.46 | JeffM | I bought my o2 on ebay on accident |
| 18:52.20 | *** join/#bzflag LongDon1 (n=LongDon@host-091-097-069-096.ewe-ip-backbone.de) |
| 19:19.24 | *** join/#bzflag bier (n=bier@p54A55022.dip.t-dialin.net) |
| 19:33.36 | *** join/#bzflag Think_Differentl (n=fatass__@unaffiliated/thinkdifferentl/x-838543) |
| 19:36.00 | *** part/#bzflag LongDon1 (n=LongDon@host-091-097-069-096.ewe-ip-backbone.de) |
| 20:13.40 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 20:14.43 | *** join/#bzflag MindstormsKid (n=chatzill@wikipedia/MindstormsKid) |
| 20:14.55 | MindstormsKid | ummmmm |
| 20:15.19 | MindstormsKid | we have a hacker who can hack anyone's account |
| 20:15.45 | MindstormsKid | i saw him be abom, ahs3, etc. all with the correct password |
| 20:16.41 | MindstormsKid | Abominable: ^^ |
| 20:17.11 | Abominable | MindstormsKid, when and where? |
| 20:17.32 | MindstormsKid | a few minutes ago and on the "no abominable allowed" server |
| 20:17.35 | MindstormsKid | :/ |
| 20:17.42 | Abominable | Ahaha |
| 20:17.57 | Abominable | donny_baker sk3letr0n has another server up |
| 20:18.06 | Abominable | MindstormsKid, that's not us |
| 20:18.10 | MindstormsKid | i know |
| 20:18.11 | Abominable | It's a plugin, not a hack |
| 20:18.16 | MindstormsKid | :O |
| 20:18.42 | MindstormsKid | but he id'd |
| 20:19.03 | Abominable | donny_baker 67.125.156.212 |
| 20:19.14 | Abominable | yeah, but it's still a plugin |
| 20:19.19 | MindstormsKid | ok |
| 20:19.26 | MindstormsKid | now i see... |
| 20:20.01 | MindstormsKid | sk3 runs the fun house, and that's where marz was impersonated with the correct password... |
| 20:20.12 | MindstormsKid | :/ |
| 20:20.40 | MindstormsKid | does that mean he has the correct password, or just a fake one? |
| 20:22.05 | AHA | its a plugin |
| 20:22.06 | Abominable | MindstormsKid, he's not really putting in a password. |
| 20:22.09 | Abominable | It's a plugin |
| 20:22.10 | MindstormsKid | ok |
| 20:22.13 | AHA | he doesn't know their passwords |
| 20:22.15 | MindstormsKid | well, i have to go :D |
| 20:22.38 | MindstormsKid | i'll tell marzi :/ |
| 20:24.30 | JeffM | what a marron |
| 20:24.39 | JeffM | what's the server? |
| 20:25.41 | JeffM | if/when he comes back we need to tell him to not incite pannic |
| 20:25.50 | JeffM | or he won't be able to come here again |
| 20:33.26 | *** join/#bzflag Constitution (n=const@unaffiliated/macsforme) |
| 20:51.26 | Constitution | any bzbb admins around? |
| 20:56.25 | JeffM | ? |
| 21:00.45 | TheRedBaron | panics |
| 21:01.10 | TheRedBaron | brlcad: its ok - you don't love me :( |
| 21:03.03 | short_circuit | The sky is falling!.......................??? ;) |
| 21:06.38 | Constitution | JeffM: nvm, someone forgot to click the link in their activation email |
| 21:09.07 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 21:16.29 | *** join/#bzflag TheRedBaron1 (n=kemhof@75.144.224.155) |
| 21:20.02 | *** join/#bzflag kirun (n=kirun@50.163.pn.adsl.brightview.com) |
| 21:25.20 | *** join/#bzflag bryjen (n=bryjen@cpe-75-81-208-175.we.res.rr.com) |
| 21:25.20 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 21:30.09 | *** join/#bzflag KingofCamelot (i=KingofCa@ip68-6-42-246.sb.sd.cox.net) |
| 21:48.55 | AAA_awright | JeffM: The global auth is really only supposed to be used by the server to authenticate people, so information provided by bzfs is useless to the client... what if the list server notified which session UUID were authenticated on that server, as opposed to bzfs doing it? |
| 21:49.43 | AAA_awright | Probably not a brilliant idea, but it is worth a shot |
| 21:52.46 | JeffM | what use would that be? |
| 21:55.39 | AAA_awright | It would show that people were authenticated through the central mechanism, versus the server, who can authenticate anyone from any server (a good thing, but could be used in a bad way). idk. |
| 21:56.00 | JeffM | locals don't hve a BZID |
| 21:56.05 | JeffM | that's how you can tell |
| 21:56.20 | JeffM | we also put globals in the global.verified group IIRC |
| 21:56.40 | JeffM | but no mater what it's the game server that sends out the + or - and it can lie |
| 21:56.47 | JeffM | so again, what use would it be? |
| 21:57.08 | JeffM | heck you can't even do local ID in 3.0 anymore |
| 21:57.37 | CIA-48 | BZFlag: 03JeffM2501 * r18705 10/trunk/bzflag/BUGS: remove bugs that aren't bugs anymore |
| 21:58.25 | blast007 | I should make a plugin that gives people a $ instead of a + if they give me lots of money |
| 21:58.32 | JeffM | heh |
| 21:58.38 | JeffM | sadly the character isn't set by the server |
| 21:58.45 | blast007 | yet ;) |
| 21:58.50 | JeffM | true |
| 21:59.03 | JeffM | custom scoreboard cols would be nice |
| 22:03.22 | Skeeve | JeffM? An idea for the MsgShotLimit which might simplify the handling? Or maybe not? Shall I explain? |
| 22:03.33 | JeffM | huh? |
| 22:03.45 | Skeeve | hah! |
| 22:03.52 | Skeeve | ;-) Why huh? |
| 22:04.17 | JeffM | cus I have no idea what you just said |
| 22:04.35 | Skeeve | I have an idea to simplify the MsgShotLimit a bit |
| 22:04.40 | JeffM | ok |
| 22:04.46 | JeffM | what is it? |
| 22:04.50 | Skeeve | You said it should contain a timestamp and a limit |
| 22:04.57 | JeffM | yes |
| 22:05.26 | Skeeve | My idea: It contains the flag involved (i still think limits have to do somehow with flags) and the limit |
| 22:05.38 | JeffM | no |
| 22:05.46 | JeffM | what if the player dosn't have a flag |
| 22:05.50 | Skeeve | Let me explain |
| 22:05.53 | JeffM | shots have been abstracted from flag |
| 22:06.04 | Skeeve | then tell me what's wrong. |
| 22:06.24 | JeffM | what use does the flag have in the message? |
| 22:06.26 | Skeeve | What's the use of a limit if you have no flag? Shall ALL shots be limtable? |
| 22:06.31 | JeffM | yes |
| 22:06.37 | JeffM | that's max flexability |
| 22:07.00 | Skeeve | So that's then the No-Flag Flag ,_) |
| 22:07.12 | JeffM | aka the starting case for all spawned tanks |
| 22:07.16 | JeffM | Flags::NULL |
| 22:07.27 | JeffM | yet you can still have your stot type set by the server |
| 22:07.29 | Skeeve | Nevermind. Let me explain. Because I think the timestamping might get a bit complicated |
| 22:07.37 | JeffM | ok |
| 22:08.03 | Skeeve | Let's for now assume, that, to each flag, there is a (dynamic) limit, set by the serrver |
| 22:08.30 | Skeeve | So if the client picks up a flag, the server sends a msg: your flag: this limit |
| 22:08.54 | Skeeve | Ideally the client didn't shoot yet |
| 22:09.04 | Skeeve | so no problem, the client can count |
| 22:09.36 | Skeeve | If the client shot before the message arrived, it already counted and compares the count to the limit send |
| 22:09.43 | Skeeve | Either it's below -> fine |
| 22:10.17 | Skeeve | or above -> Not so fine, The flag needs to be dropped before I can display that there was a limit. But then: Maybe my lag is already too high ;-) |
| 22:10.31 | Skeeve | The other case might be |
| 22:10.45 | Skeeve | I alread dropped th flag and picked up another one |
| 22:10.46 | JeffM | the shot limit message would be sent in the same outbound packet with the flag message so it would work the same way |
| 22:10.57 | JeffM | with out having to tie shots to flags |
| 22:11.08 | Skeeve | So the message can safely be dropped as the flag doesn't account for me |
| 22:11.09 | JeffM | I would prefer shots and flags be keept serperate as much as possible |
| 22:11.21 | Skeeve | I don't get the point of that |
| 22:11.40 | JeffM | so you can have custom game modes that use shots with out needing flags |
| 22:11.42 | Skeeve | (replace "the flag" with "the limit" above) |
| 22:11.51 | JeffM | to make the protocoll more flexable |
| 22:12.10 | JeffM | the more flex we have in the proto the more we can do with out becoming incompatable |
| 22:13.14 | JeffM | keeping a list of flags and shot limtis seems just as complex as keeping a list of players and shot limits |
| 22:13.55 | Skeeve | I see the complexity in the timestamp of each flag and limit, getting that in sync |
| 22:13.55 | JeffM | if you aren't comfortable doing it, that's fine, someone else can do it |
| 22:14.08 | JeffM | we already have functions to keep clocks in sync |
| 22:14.14 | JeffM | we do it for postional updates |
| 22:14.19 | JeffM | so it's the same thing |
| 22:14.20 | Skeeve | And in that I don't see a benefit. But that is my fault |
| 22:14.25 | JeffM | client jsut keeps a list of what it's shot |
| 22:14.28 | JeffM | it's prety easy |
| 22:14.48 | JeffM | shots since last pickup |
| 22:14.52 | JeffM | and the time of the last pickup |
| 22:15.00 | Skeeve | what's a "pickup"? |
| 22:15.02 | JeffM | since you can asssume each pickup is unlimited shots |
| 22:15.04 | JeffM | flag grab |
| 22:15.08 | Skeeve | HA! |
| 22:15.14 | Skeeve | Ther it is, the flag |
| 22:15.28 | JeffM | ok, time since last shot change |
| 22:15.33 | Skeeve | I stil don't see the need for a timestamp here |
| 22:15.35 | JeffM | since the shot change is sent with the flag message |
| 22:15.41 | JeffM | in case there is a delay |
| 22:15.48 | JeffM | lag is wierd |
| 22:15.54 | JeffM | so it's best to be able to handle it |
| 22:16.15 | JeffM | but then worst case is if the client gets out of sync, the server just dropps the flag on them |
| 22:16.16 | Constitution | TheRedBaron: ping |
| 22:16.21 | Skeeve | yes. but I still don't see the need for the timestam. Last chang: Reset xounter to 0 and start counting. |
| 22:16.51 | JeffM | Skeeve, in case you want to do something like "unlimited shots for a min, then limit them to 5 shots" |
| 22:17.11 | Skeeve | If the server sends to what the chang was (which "flag") I know whether or not the message is important to me |
| 22:17.13 | JeffM | so the shot limit message would come after the shot type change, and they'd need to know what shots they fired after the 1 min mark |
| 22:17.25 | TheRedBaron | Constitution: pong |
| 22:18.20 | Skeeve | Ah! But that's a different kind of limit, isn't it? |
| 22:18.36 | JeffM | it's using the limit message with time to get various effects |
| 22:18.42 | JeffM | rather then hardcoding each limit type |
| 22:18.52 | JeffM | hence the flexability I'm talking about |
| 22:19.29 | JeffM | with out a timestamp in that case it coudl be possible for a tank to get an "extra" shot or 2 based on lag |
| 22:19.38 | JeffM | if they just applied the limit when they got the message |
| 22:19.53 | JeffM | the time stamp is like "effective as of" mark |
| 22:20.16 | Skeeve | But still: With the stamp you can get the extra shots |
| 22:20.30 | JeffM | not if the client tracks it correctly |
| 22:20.33 | Skeeve | The shots are already fired when the new limit arrives |
| 22:20.38 | Constitution | TheRedBaron: is the my.inex replay server working? I'm doing a "/replay list *200810*" and I get nothing, even though I know I matches there yesterday |
| 22:21.10 | JeffM | yeah so the client knows it shot say "2" after the limit time, because it tracked the shot times, so it subtrats 2 from that limit when it gets it |
| 22:21.17 | JeffM | now both the client and server are in perfect sync |
| 22:23.33 | Skeeve | It still seems to me as if I need to keep an ordered list of each of my shots with timestamp when they were fired so that I can count all the shots after the timestamp I just received just in order to make sure I didn't fire more than allowed. |
| 22:23.45 | JeffM | yeah, that's the shot tracking |
| 22:23.50 | JeffM | so |
| 22:23.57 | JeffM | hooray for maps :) |
| 22:24.13 | Skeeve | didn't get the last joke |
| 22:24.14 | JeffM | std::map<double,int> shothistorymap |
| 22:24.25 | Skeeve | ah ok |
| 22:24.26 | JeffM | it'll even keep em sorted for you :) |
| 22:24.39 | JeffM | yes, you are correct, you method would be simpler to program |
| 22:24.41 | JeffM | that is for sure |
| 22:24.45 | JeffM | but it would be a lot less flexable |
| 22:24.55 | JeffM | and just because something is easy don't mean it is the best way to do it |
| 22:25.16 | JeffM | and if we are going to do something we should try to make it as flexable as we reasonaby can |
| 22:25.21 | JeffM | and I don't feel this is too unreasonable |
| 22:25.26 | TheRedBaron | hrm |
| 22:25.28 | Skeeve | So if I find out know, the last two shots were too much. What then? |
| 22:25.46 | JeffM | if it becomes unreasonable during implemenation, then sure we discuss and maybe take that out, and let it be "ok" to loose a shot or 2 |
| 22:25.58 | JeffM | then just drop your flag and say screw it |
| 22:26.05 | JeffM | the server will block em anyway |
| 22:26.10 | JeffM | it should be a rare case |
| 22:26.21 | JeffM | you'll get the shots back as errors and delete them |
| 22:26.45 | JeffM | all that means is you are a laggy laggy bastard and should not be playing network video games |
| 22:26.57 | TheRedBaron | Constitution: the only thing thats change is adding the countdownresume delay |
| 22:27.11 | Skeeve | we also need to track in that map a flag change. |
| 22:27.38 | JeffM | flag change forces a shot type resend, so it's ok to clear the map on a shot change |
| 22:27.46 | JeffM | then it'll all just start over |
| 22:28.59 | JeffM | the client can't get a new flag with out data from the server anyway |
| 22:29.04 | Skeeve | So a limit msg only accouints, if it's first timestamp is on or before the limit's timestamp |
| 22:29.04 | JeffM | so the server can send all the stuff |
| 22:29.18 | Skeeve | if it's first map-timestamp |
| 22:29.25 | JeffM | the message would be the limit from that time |
| 22:29.41 | JeffM | so techincaly the server could send out an update each shot if it wanted to and everything should work |
| 22:29.50 | JeffM | the client should not care about the past that much |
| 22:30.38 | JeffM | it's probably even reasonable to only have the client keep say the last minute of shots |
| 22:30.45 | JeffM | since if lag is that high, you are screwed |
| 22:31.17 | JeffM | the goal is to simply make the client not be out of sync from the servr for most players |
| 22:31.24 | JeffM | so that you don't have shots being redacted |
| 22:31.40 | JeffM | that's the problem we have now |
| 22:31.46 | Skeeve | Let me try to elaborate a simpler approach again, if I may |
| 22:31.53 | JeffM | sure |
| 22:32.10 | Skeeve | drop the timestamp, introduce a counter |
| 22:32.20 | Skeeve | the counter counts shotchanges |
| 22:32.36 | Skeeve | and it servers like an id |
| 22:32.56 | Skeeve | So if the server sends a limt, it also sends the id (counter) of the shot change |
| 22:33.15 | Skeeve | I simply count shots after each changew and don't keep a list |
| 22:33.34 | Skeeve | If the limit is reached or exceeded: Flag is dropped. |
| 22:33.45 | JeffM | that dosn't let you do the limit after a fixed time thing |
| 22:33.45 | Skeeve | If the id (counter) is too old: I needn't care |
| 22:33.53 | Skeeve | it does |
| 22:34.07 | Skeeve | as the server can send (after a minute) a new limit |
| 22:34.16 | JeffM | but then that's off by a lag time |
| 22:34.37 | JeffM | you could have goten off one or 2 shots in that lag time |
| 22:34.45 | JeffM | and the server has subtracted them from your limit, but you did not |
| 22:34.49 | JeffM | and you are out of sync |
| 22:35.07 | Skeeve | example please |
| 22:35.20 | JeffM | it's been 1 min, I say you now have 10 shots left |
| 22:35.22 | JeffM | I send the message |
| 22:35.30 | JeffM | you send me a shot |
| 22:35.36 | JeffM | but have not gotten the limit yet |
| 22:35.42 | JeffM | I say you have 9 shots left |
| 22:35.46 | JeffM | you get the limit |
| 22:35.53 | JeffM | you think you have 10 shots left |
| 22:36.06 | JeffM | you shoot 10 times |
| 22:36.16 | JeffM | on the 9th new shot, I say you are out. |
| 22:36.28 | JeffM | the 10th new shot you send you think was valid, I say was invalid |
| 22:36.37 | JeffM | I have to redact the shot |
| 22:36.59 | Skeeve | No. I think there's a flaw in your example |
| 22:37.04 | Skeeve | Let me try |
| 22:37.25 | Skeeve | 1 minute unlimited shots and then 10 shots left is the scenario, okay. |
| 22:37.34 | JeffM | yes |
| 22:37.35 | Skeeve | So first I think iunlimited and shoot |
| 22:37.47 | Skeeve | I count each shot |
| 22:37.52 | Skeeve | You too count |
| 22:38.03 | Skeeve | After 1 minute you say |
| 22:38.04 | JeffM | I see where you are going |
| 22:38.12 | Skeeve | currentcount + 10 is now you limit |
| 22:38.18 | JeffM | I say, you have 10 shots left after the 27 you just shot |
| 22:38.21 | JeffM | right? |
| 22:38.25 | Skeeve | Right |
| 22:38.31 | Skeeve | so 37 is my new limit |
| 22:38.38 | *** join/#bzflag BenUrban (n=benurban@unaffiliated/benurban) |
| 22:38.40 | JeffM | you are just using shot count instead of time |
| 22:38.43 | JeffM | it's the same work |
| 22:38.45 | Skeeve | right |
| 22:38.47 | Skeeve | And no list |
| 22:38.53 | JeffM | you have a count |
| 22:38.54 | Skeeve | nope |
| 22:39.01 | JeffM | you are still storing history |
| 22:39.04 | Skeeve | I don't need to go through a list |
| 22:39.13 | JeffM | you coudl keep a count and time |
| 22:39.17 | JeffM | and do the same thing |
| 22:39.25 | Skeeve | I keep 2 integers (or maybe larger) |
| 22:39.32 | JeffM | I'd keep an int and double ;) |
| 22:39.52 | JeffM | but hey, try it and see |
| 22:39.56 | JeffM | it's your patch |
| 22:40.03 | Skeeve | If you send the accumulated shotcount, you're right |
| 22:40.05 | JeffM | don't forget about packetloss ;) |
| 22:40.39 | Skeeve | How is it handle now? |
| 22:40.52 | JeffM | depends how the data is sent |
| 22:40.52 | Skeeve | If I pc superflag butthe message is lost? |
| 22:41.02 | JeffM | you never pick up a flag |
| 22:41.08 | JeffM | the server tells you "you got this flag" |
| 22:41.18 | Skeeve | (I don't like this IRC client. It swallows letters) |
| 22:41.41 | JeffM | it is a way that we can get out of sync if you don't get that messag |
| 22:42.00 | JeffM | thats why I want to be sure that any new stuff we do we be sure to work in systems that can work with packetloss |
| 22:42.05 | JeffM | so we can get better |
| 22:42.30 | Skeeve | How would you handle packetlos with the timestamp-idea? |
| 22:42.33 | JeffM | like for flagpickup we should do an ack |
| 22:43.21 | JeffM | well if it dosn't go thru, we'd still just drop the flag and redact |
| 22:43.24 | JeffM | that'd be fine |
| 22:43.55 | JeffM | if the server had missing shots, both would have the same problem |
| 22:44.04 | Skeeve | Okay. I'll think about it. Timestamp + accumulated limits and no map would be fine for me |
| 22:44.04 | JeffM | the client would always have it's shot history so for time it'd be cool |
| 22:44.17 | JeffM | again, it's your patch, do it how you wish |
| 22:44.31 | Skeeve | And I only wanted a better HUS ;-) |
| 22:44.43 | JeffM | I belive you know what my requirements are, so I'm sure you'll work them in |
| 22:44.44 | Skeeve | Now I'm talked into server and protocol patching |
| 22:44.52 | Skeeve | You're a bastard, Jeff! ;-) |
| 22:44.57 | JeffM | ok, then don't do it |
| 22:44.59 | JeffM | I care not |
| 22:45.14 | Skeeve | Don't take me serious. |
| 22:45.24 | Skeeve | I will really think about it and see what I can do |
| 22:45.39 | JeffM | what bothers me is that you seem to fear lists |
| 22:45.41 | JeffM | and that is not good |
| 22:45.55 | Skeeve | I fear lists when I don't see a benefit |
| 22:46.04 | JeffM | if the task isn't up to your comfortable skill level, then don't try to hack the idea to fit your level, let it go |
| 22:46.20 | JeffM | if you can make it work with a count and time stamp that's fine |
| 22:46.40 | JeffM | I'm just not a big fan of delta states, they get screwed up too often |
| 22:47.30 | Skeeve | I really see no benefit as it really comes down to counting each time when a new limit arrives. So why not count in the first place. The only result I heard of was: Drop flag (or change shot) if the limit is reached or exceeded |
| 22:47.50 | JeffM | because wierd crap happens on a network ;) |
| 22:48.03 | Skeeve | it also happens if I keep a list |
| 22:48.21 | Skeeve | and If I keep and count a list, I have less time for network stuff |
| 22:48.23 | JeffM | with a time list, the server jsut says "at this time you had this limit" |
| 22:48.40 | JeffM | if the client list for shots before that time is wrong, it dosn't affect the limit |
| 22:48.55 | JeffM | with your count, you get off by one between the client and server and your limit is busted |
| 22:48.59 | JeffM | that's what I don't like |
| 22:49.16 | JeffM | there is a smaller window for error |
| 22:49.39 | JeffM | you need consitency back to the last shot change, I just need it back to the timestamp |
| 22:49.46 | JeffM | something that should be a lag time |
| 22:50.25 | *** join/#bzflag swigg (n=Paul@71-14-108-006.dhcp.gnvl.sc.charter.com) |
| 22:51.32 | Skeeve | Isn't every shot acknowledged? Or are just false shots rejected? |
| 23:22.56 | JeffM | in the curent code they are not |
| 23:23.05 | JeffM | once shotbranch is done they will be |
| 23:23.22 | JeffM | but then once shot branch is done we can simply say "you have X shots left after shotID N" |
| 23:27.50 | TheRedBaron | does 2.0.12 not accept the recdir directive ? |
| 23:32.46 | Constitution | TheRedBaron: it should. something not working? |
| 23:33.38 | TheRedBaron | something is not working |
| 23:33.47 | TheRedBaron | No new recordings since sept 29 |
| 23:34.30 | Skeeve | Will shotbranch be done for 3.0? |
| 23:34.45 | TheRedBaron | the only thing thats changed is upgrade to 2.0.12 to use countdown resume delay |
| 23:35.20 | *** join/#bzflag bryjen (n=bryjen@cpe-75-81-208-175.we.res.rr.com) |
| 23:35.20 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 23:37.35 | *** join/#bzflag KTL (n=KTL@213.219.161.42.adsl.dyn.edpnet.net) |
| 23:41.51 | TheRedBaron | Constitution: running it manually works |
| 23:42.21 | TheRedBaron | and saves it in the correct directory - so my filesystem perms are correct. |
| 23:44.01 | Constitution | ok |
| 23:44.32 | Constitution | the plugin is loaded, right? |
| 23:46.29 | Constitution | and I dunno whether this should make a difference, but is the plugin from the 2.0.12 build or the old one from 2.0.10? |
| 23:52.54 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 23:53.07 | JeffM | now, finaly time to work on some shirt stuff :) |
| 23:56.21 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 23:58.50 | *** join/#bzflag CBG` (n=CBG@cpc1-newe2-0-0-cust289.cdif.cable.ntl.com) |
