| 00:05.15 | *** join/#bzflag PrezKennedyII (i=Matthew@whitecalf.net) |
| 00:17.04 | *** join/#bzflag smoooth (n=smoooth@cpe-098-024-234-056.ec.res.rr.com) |
| 00:20.27 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 00:20.28 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:35.17 | *** part/#bzflag smoooth (n=smoooth@cpe-098-024-234-056.ec.res.rr.com) |
| 00:44.14 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 00:44.14 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 01:29.15 | *** join/#bzflag Jeffrey_ (n=chatzill@adsl-99-35-128-154.dsl.pltn13.sbcglobal.net) |
| 01:47.03 | Bambino_ | ahs3-: ping |
| 01:48.01 | *** join/#bzflag needhelp1 (n=Louise@unaffiliated/needhelp1) |
| 01:48.18 | needhelp1 | howdy, im looking to chat with the admin of bzflags webpage |
| 01:49.24 | JefferyM | needhelp1, sup? |
| 01:49.24 | needhelp1 | JefferyM: may i PM? |
| 01:49.30 | JefferyM | sure |
| 01:49.37 | needhelp1 | TY |
| 01:52.37 | me1 | trepan, why? |
| 01:57.24 | *** join/#bzflag sfgbwrth (n=sfgbwrth@pool-71-253-201-139.nrflva.east.verizon.net) |
| 01:57.51 | *** part/#bzflag needhelp1 (n=Louise@unaffiliated/needhelp1) |
| 02:12.22 | *** part/#bzflag sfgbwrth (n=sfgbwrth@pool-71-253-201-139.nrflva.east.verizon.net) |
| 02:42.37 | *** join/#bzflag Yassen (n=chatzill@pool-98-117-128-137.sttlwa.fios.verizon.net) |
| 02:51.13 | *** join/#bzflag pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 02:54.38 | *** join/#bzflag cloncker (n=bob@pool-71-253-220-200.nrflva.east.verizon.net) |
| 03:08.51 | *** part/#bzflag Ebert (n=EbErT@adsl-211-42-161.asm.bellsouth.net) |
| 03:21.48 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 03:27.21 | *** join/#bzflag swigg (n=Default@bzflag/player/Swigg) |
| 03:41.20 | *** part/#bzflag temp_dist (n=pidgin@bzflag/serverop/TemporalDistraction) |
| 04:11.37 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 04:14.40 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 05:16.54 | *** join/#bzflag Bambino__ (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) |
| 05:20.37 | *** join/#bzflag Bambino__ (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) |
| 05:28.45 | *** join/#bzflag JeffM (n=Jeff@bzflag/projectadmin/JeffM) |
| 05:28.45 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 05:31.43 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 05:38.35 | blast007 | hrm, so lua was removed? :/ |
| 05:41.41 | JeffM | ibot logs |
| 05:41.41 | ibot | extra, extra, read all about it, logs is http://ibot.rikers.org/%23bzflag/, or stats http://ibot.rikers.org/stats/bzflag.html.gz |
| 05:42.10 | Bulldozer | ibot needs a nice search interface ;) |
| 05:42.19 | Bulldozer | or his logger does, rather |
| 05:42.23 | JeffM | it's not that hard if you know the date |
| 05:42.46 | Bulldozer | no, but it would still be nice :) |
| 05:42.49 | *** join/#bzflag Bambino__ (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) |
| 05:42.54 | JeffM | so would ending world hunger ;) |
| 05:43.00 | Bulldozer | lol, yes |
| 05:44.52 | JeffM | trepan: what were the specific short term problems? |
| 05:47.43 | JeffM | DTRemenak: can you take a look around for the mobo/cpu you said you may have? :) |
| 05:48.09 | Bulldozer | jorgenpt: What is the purpose of having the RCLink Frontend/Backend? (i.e. why do the scripts not communicate directly with the client?) |
| 05:48.39 | JeffM | I belive it was to have a single API for the scripts |
| 05:48.44 | JeffM | basicly an interface lib |
| 05:49.04 | Bulldozer | For reasons of Python, then? |
| 05:49.10 | JeffM | or any language |
| 05:49.16 | Bulldozer | Hmm, I see. |
| 05:49.19 | JeffM | the idea was to have the logic modules be able to be made in ANYTHING |
| 05:49.58 | JeffM | then an AI student could use whatever language they were most familiar with |
| 05:58.52 | Bulldozer | jorgenpt: What is the purpose of AdvancedRobot.cxx/h and Robot.cxx/h ? |
| 05:59.29 | JeffM | is he even awake now? |
| 05:59.38 | Bulldozer | Dunno, maybe not :) |
| 05:59.46 | JeffM | what's the difference in the files? |
| 06:00.08 | Bulldozer | Oh, I know the difference between Robot and AdvancedRobot |
| 06:00.27 | JeffM | and they are? |
| 06:00.53 | Bulldozer | I'm wondering why those two files exist at all (vs BZAdvancedRobot.cxx, and BZRobot.cxx) |
| 06:01.01 | JeffM | I know what you are wondering |
| 06:01.05 | JeffM | but that's not what I'm asking ;) |
| 06:01.45 | Bulldozer | Robot defines a "basic" set of functions for robots (the units primarily being in degrees), for "simple" robots. |
| 06:02.23 | JeffM | are they historicaly different? |
| 06:02.24 | Bulldozer | Whereas AdvancedRobot has an extended set of functionality (this time, primarily dealing in radians), for more complex robots |
| 06:02.46 | JeffM | it is possible that' it's an evolutionary step |
| 06:03.01 | JeffM | and to keep API compatability you put your new stuff in a new file |
| 06:03.11 | JeffM | do they have different headers? |
| 06:04.28 | Bulldozer | In the context of RoboCode, my understanding was they were meant to be two separate things; they wanted to start early at a level where the students wouldn't have studied radians in math yet. |
| 06:04.29 | JeffM | then sounds like a fair enough assumption |
| 06:06.04 | Bulldozer | All I can think of is that the classes exist purely for the purpose of natively running robocode bots in bzflag |
| 06:06.29 | Bulldozer | But that's going to be pretty pointless because we don't do independent radar and gun rotation |
| 06:06.31 | JeffM | that was one of the goals, to make a robocode compatable API |
| 06:06.47 | JeffM | so those bots just have to go with that limitation |
| 06:07.00 | JeffM | dosn't mean that we can't have a very robocode like API to help the students |
| 06:07.07 | JeffM | do you want to change it or something? |
| 06:07.25 | Bulldozer | No, I'm just trying to make sure I understand all the bzrobots code here. |
| 06:07.46 | JeffM | yes robocode compatability was a very big part of the last set of changes to it |
| 06:08.07 | Bulldozer | When I saw something like "void setTurnGunLeft(double degrees);" and "void setTurnRadarLeft(double degrees);", I was rather confused :) |
| 06:08.10 | JeffM | the idea is to leverage as much robocode docs and code as possible |
| 06:08.37 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 06:08.37 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 06:09.11 | JeffM | the specific trait of gun and radar turning are not the major parts of robocode bots |
| 06:10.26 | Bulldozer | I would beg to differ, but if we want to at least make the API available for compatibility reasons, then that's fine. |
| 06:10.33 | Bulldozer | Just so I understand what's going on :) |
| 06:11.16 | JeffM | it's a major part of the how you get your tank into postition, but the code for doing big stuff like finding targets, moving, etc.. that is all stuff we can reuse |
| 06:11.42 | Bulldozer | Yes |
| 06:11.48 | JeffM | adapting an existing bot to assume full 360 radar, and no turret rotation should not be hard |
| 06:12.00 | JeffM | then you have the major guts of a bot you can tweak for good bzflag gameplay |
| 06:12.20 | JeffM | that's much simpler then porting an existing bot to a totaly new API |
| 06:12.25 | Bulldozer | Sure. |
| 06:12.34 | JeffM | and that's what I belive the general idea is |
| 06:12.48 | Bulldozer | Yeah |
| 06:12.58 | Bulldozer | Same API, different attack/dodge strategy :) |
| 06:13.32 | Bulldozer | Definitely very nice |
| 06:13.33 | JeffM | yeah |
| 06:14.09 | JeffM | is there a way in that API to query the turret movement range? and the radar angle? |
| 06:15.27 | Bulldozer | In the robocode API, yes |
| 06:15.41 | JeffM | then it makes sense |
| 06:15.59 | JeffM | we'd return 0 for the turret range and +-180 for the radar angle |
| 06:16.24 | JeffM | then existing bot code would say "is the target outside the range of my turret?" and answer "yes" |
| 06:16.26 | Bulldozer | er |
| 06:16.37 | JeffM | cus it would HAVE to have code to turn the tank for targets outside of the range |
| 06:16.38 | Bulldozer | Sorry, I think I misunderstood the question |
| 06:16.52 | JeffM | and the bot tell the dynamics of the tank it's driving? |
| 06:17.00 | JeffM | as in how far it can turn its' turret side to side? |
| 06:17.14 | Bulldozer | Robocode will tell you the angle of the radar/turret relative to the heading of the tank |
| 06:17.25 | JeffM | but will it tell you it's movement limits? |
| 06:17.37 | JeffM | or does it assume 360deg ? |
| 06:17.39 | Bulldozer | there are no limits; the range of movement is 360 degrees |
| 06:17.52 | JeffM | then what is the radar angle assumed to be? |
| 06:17.58 | Bulldozer | there's a limited range of movement per turn |
| 06:18.12 | JeffM | turn? |
| 06:18.56 | Bulldozer | Robocode operates in discrete "turns"; i.e. you give a command, or set of commands; then they are carried out. that is your "turn" |
| 06:19.03 | JeffM | ahh |
| 06:19.07 | JeffM | that's silly :) |
| 06:19.17 | JeffM | that's just a timeslice mechanism |
| 06:19.25 | Bulldozer | so you say, turn radar right 360 degrees; end turn |
| 06:19.38 | JeffM | why would you turn the radar 360 deg? |
| 06:19.38 | Bulldozer | then after your next turn, the radar has rotated 45 degrees |
| 06:19.43 | JeffM | ahh |
| 06:19.50 | Bulldozer | after two turns, it has rotated 90, and so on |
| 06:19.55 | JeffM | but how much of a view does the radar show? |
| 06:20.21 | Bulldozer | the radar has something similar to a callback routine |
| 06:20.32 | JeffM | that tells you what you can see? |
| 06:20.44 | Bulldozer | at the end of your turn, a callback is made for each bot that was seen in the 45 degree sweep |
| 06:20.52 | JeffM | so it's a 45 sweep |
| 06:21.01 | JeffM | yeah the API should return those angles to the bot |
| 06:21.05 | Bulldozer | May not be 45 exactly; I can check the specs |
| 06:21.15 | JeffM | then you could write bot code that was smart and could work with different tanks :) |
| 06:21.44 | JeffM | like say you got the ability to have a 90deg radar, then the bot code could take advantage of it |
| 06:22.05 | Bulldozer | It's defined by "rules", which are global to a game |
| 06:22.13 | Bulldozer | by default it is 20 degrees per "turn" |
| 06:22.13 | JeffM | ahhh ok |
| 06:22.26 | JeffM | so for bzflag, set the rules to 0 per turn |
| 06:22.41 | JeffM | guess robocode runs at a fixed internal frame rate |
| 06:22.54 | Bulldozer | timeslices and frames are seperate |
| 06:23.13 | JeffM | it should not have real frames, since it dosn't draw anything |
| 06:23.20 | JeffM | can it do more then one thing in a turn? |
| 06:23.32 | JeffM | or does it just get an update each turn? |
| 06:23.32 | Bulldozer | Robot can't, AdvancedRobot can |
| 06:23.49 | JeffM | sure advanced robot seems more like a real bot |
| 06:24.19 | Bulldozer | Sounds like we need to implement the Rules class... |
| 06:24.26 | Bulldozer | http://robocode.sourceforge.net/docs/robocode/robocode/Rules.html |
| 06:24.28 | JeffM | probably |
| 06:24.50 | *** join/#bzflag Bambino__ (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) |
| 06:24.54 | JeffM | then set the turret and radar speeds to 0, and the radar angle to 360 |
| 06:25.24 | JeffM | but it dosn't matter that much |
| 06:25.41 | JeffM | I know we arn't binary compatabile with robocode, just mostly API compatable |
| 06:54.38 | jorgenpt | Bulldozer: Yes, JeffM is right about frontend/backend. It was also how the old code did it, except it was more of a "telnet-like" API. |
| 06:55.18 | jorgenpt | Bulldozer: Also, as you concluded, the BZAdvanced/Advanced etc classes are separate because the goal was to provide an API that would require very little modification to test and use RoboCode AIs. |
| 06:58.11 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-046-072.ewe-ip-backbone.de) |
| 06:58.24 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-046-072.ewe-ip-backbone.de) |
| 07:00.40 | Bulldozer | jorgenpt: Ah |
| 07:03.53 | Bulldozer | jorgenpt: When was the last time the code actually worked? |
| 07:04.23 | jorgenpt | I'm sorry, I'm not at liberty to disclose that information. |
| 07:04.32 | jorgenpt | (Actually, I'm not sure what revision/time that was) |
| 07:04.49 | jorgenpt | The code has been gathering dust for a while now. |
| 07:06.39 | Bulldozer | jorgenpt: Just hoping to get a handle on why the bots aren't spawning :) |
| 07:07.45 | jorgenpt | Of course, just ask if you wonder about anything. I'm glad JeffM has been around to answer; I'm still studying for my exams, I have one tomorrow. |
| 07:07.47 | Bulldozer | How did it work before? Is is possible I'm doing something wrong in the server or client startup? |
| 07:08.09 | jorgenpt | Well, how am I supposed to answer that? That's quite the generic question. |
| 07:08.17 | Bulldozer | Oh nice, good luck on the exam - I won't bug you too much. |
| 07:08.29 | jorgenpt | Just ask, and I'll try to reply when I see it. :) |
| 07:08.58 | jorgenpt | Also, my laptop is KIA, :/w |
| 07:09.07 | jorgenpt | heads to take a shower |
| 07:09.49 | Bulldozer | Um, let me see... If I do ./bzfs -ms 4 and then ./bzrobots -team blue bot1@localhost, it should work, right? |
| 07:10.42 | Bulldozer | i.e. there's nothing particularly special or not obvious that needed to be done to get a working demo running, right? |
| 07:11.20 | jorgenpt | No, it used to be straight forward enough. |
| 07:11.30 | jorgenpt | I can't comment on the bzfs-flags, but that looks good. |
| 07:30.04 | jorgenpt | Or, well, don't you need a script/module as the parameter? |
| 07:30.19 | jorgenpt | Like ./bzrobots -team blue bot1@localhost foo.py or foo.so. :) |
| 07:30.49 | Bulldozer | oh yeah, missed that, yes, I run it like so |
| 07:31.12 | jorgenpt | Also, what did the branch issue end up being resolved as? |
| 07:31.21 | Bulldozer | branch issue? |
| 07:31.38 | *** join/#bzflag GiantEnemyCrab (n=GiantEne@c-76-115-175-223.hsd1.wa.comcast.net) |
| 07:31.39 | jorgenpt | Well, the discussion on wether or not to use your own branch. :) |
| 07:31.44 | Bulldozer | Oh |
| 07:31.51 | Bulldozer | They all said to use trunk |
| 07:32.00 | jorgenpt | Okay |
| 07:32.08 | Bulldozer | So I have torn it to bits accordingly... |
| 07:32.30 | Bulldozer | I suppose it's better; keep me more organized |
| 07:35.16 | jorgenpt | (: |
| 07:36.40 | Bulldozer | Something isn't being initialized correctly; it was segfaulting (null ptr) at a location where the reference was presumably expected to be valid. |
| 07:37.16 | Bulldozer | It should check the reference anyway, which I did, so it doesn't segfault anymore, nevertheless, it still doesn't work. |
| 07:38.50 | Bulldozer | Are frontend.log and backend.log supposed to be created when it's run? |
| 07:39.05 | Bulldozer | Or is there some switch I'm not seeing somewhere? |
| 07:51.38 | jorgenpt | Yeah, they're supposed to be created when it's run |
| 07:51.57 | jorgenpt | At the first call of FRONTENDLOGGER / BACKENDLOGGER |
| 07:52.18 | jorgenpt | But I'm off to read. Good luck. :-) |
| 07:58.04 | *** join/#bzflag GiantEnemyCrab (n=Powerboo@c-76-115-175-223.hsd1.wa.comcast.net) |
| 08:01.33 | *** part/#bzflag Bulldozer (n=mathew@unaffiliated/kingrobot) |
| 08:08.48 | *** join/#bzflag GiantEnemyCrab (n=LargeEne@c-76-115-175-223.hsd1.wa.comcast.net) |
| 08:09.34 | GiantEnemyCrab | configuring new client, lol |
| 08:51.52 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 08:51.52 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 10:02.28 | GiantEnemyCrab | is not currently running iTunes. |
| 10:03.10 | brad | ~lart GiantEnemyCrab |
| 10:03.10 | ibot | whacks GiantEnemyCrab with the cluebat |
| 10:03.36 | GiantEnemyCrab | sorry still playing with new client |
| 10:37.19 | *** join/#bzflag Wyk3d (n=Wyk3d@c7.campus.utcluj.ro) |
| 11:24.31 | *** join/#bzflag QuantumT1m (n=tim@62.249.230.206) |
| 12:03.26 | *** join/#bzflag Abominable_ (i=Abominab@user-0ce2hpi.cable.mindspring.com) |
| 12:03.56 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-046-072.ewe-ip-backbone.de) |
| 12:06.03 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-046-072.ewe-ip-backbone.de) |
| 12:38.20 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 13:07.32 | brad | http://sourceforge.net/projects/bzflag/ someone deleted bzflag :O |
| 13:11.52 | RAThomas | more like someone deleted sourceforge ;) |
| 13:16.40 | *** join/#bzflag bier|tp (n=bier@p54A57B1D.dip.t-dialin.net) |
| 13:19.17 | cloncker | What's the difference? |
| 13:19.28 | brad | it has been undeleted...crisis over :p |
| 13:19.47 | brad | was saying "project not found" for a while |
| 13:20.03 | brad | or rather...all projects were saying that |
| 13:21.40 | *** join/#bzflag spldart (n=short_ci@bzflag/contributor/spldart) |
| 13:21.40 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:44.35 | brlcad | trepan: did you implement a stroke parameter on the fonts at some point? |
| 13:45.01 | brlcad | or was that something being done through lua, or am I just misremembering that you even did anything with strokes/outlines |
| 13:45.37 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 13:47.08 | trepan | brlcad: it was in the LuaFontTexture files (and MakeFont() call), using a gaussian blur |
| 14:12.10 | *** join/#bzflag temp_dist (n=pidgin@bzflag/serverop/TemporalDistraction) |
| 14:12.36 | brlcad | trepan: got it, cool - thanks |
| 14:14.00 | Manu | hugs brlcad |
| 14:14.12 | brlcad | howdy Manu |
| 14:14.22 | Manu | brlcad: relaxed ;) |
| 14:14.31 | brlcad | you are? |
| 14:14.34 | Manu | yes |
| 14:14.41 | brlcad | excellent |
| 14:15.10 | Manu | I'm at work.. but relaxed :) |
| 14:23.56 | *** join/#bzflag Rob5a (n=rob5a@dslb-092-078-034-141.pools.arcor-ip.net) |
| 14:39.25 | *** join/#bzflag Upsetter (n=ups@i577B53F7.versanet.de) |
| 14:46.59 | *** join/#bzflag Wyk3d1 (n=Wyk3d@c7.campus.utcluj.ro) |
| 14:49.52 | *** join/#bzflag Wyk3d (n=Wyk3d@c7.campus.utcluj.ro) |
| 14:57.52 | *** join/#bzflag ep (n=quassel@ip68-97-126-55.ok.ok.cox.net) |
| 15:04.03 | *** join/#bzflag TimRiker (n=timr@173-117-164-93.pools.spcsdns.net) |
| 15:04.04 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:28.56 | *** join/#bzflag Carnage00 (n=chatzill@dyn216-8-133-236.ADSL.mnsi.net) |
| 15:55.04 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 15:57.40 | jcp | What, exactly, is up with lua being removed? |
| 15:57.52 | jcp | I heard something about that, and was wondering what exactly is going on... |
| 15:58.38 | *** join/#bzflag Wyk3d1 (n=Wyk3d@c7.campus.utcluj.ro) |
| 16:40.45 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 16:40.45 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 16:41.26 | *** join/#bzflag bier|tp (n=bier@p54A54DD2.dip.t-dialin.net) |
| 17:18.25 | joevano | jcp: not sure |
| 17:18.47 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 17:25.36 | *** join/#bzflag MindstormsKid (n=chatzill@Wikipedia/MindstormsKid) |
| 17:36.09 | brlcad | jcp: I believe the overall gist was to help stabilize things for the upcoming release |
| 17:36.25 | jcp | so no client-side scripting for 3.0? |
| 17:36.41 | brlcad | basically minimizing the issues overall |
| 17:36.57 | jcp | upcoming releasE? |
| 17:36.59 | brlcad | plus the interface exposes a LOT of functionality and features .. lots of issues there (potential and real) |
| 17:37.05 | jcp | yeah |
| 17:37.13 | jcp | (and that comment was not intended sarcastically) |
| 17:37.23 | jcp | is there an estimate yet on when 3.0 is coming out? |
| 17:38.12 | brlcad | there may have been other motivations too, but that's what it seemed like to me |
| 17:38.29 | brlcad | tis a flawed question, there is never an estimate |
| 17:38.38 | jcp | well yeah, I suppose... |
| 17:38.47 | jcp | I meant, your comment sounded like the release was going to be soon |
| 17:38.50 | brlcad | it's out when it's out, the sooner the better |
| 17:38.58 | jcp | whereas the previous impression I had received was that it could be a matter of years |
| 17:39.11 | brlcad | well it'll get released when it's percieved that all the issues are quelled |
| 17:39.30 | brlcad | frankly, it could be years |
| 17:39.35 | brlcad | it could be days |
| 17:39.45 | brlcad | neither is likely, but sure .. it coulde |
| 17:40.04 | JefferyM | was there a branch made before the removal and who's idea was it to yank it? |
| 17:40.05 | jcp | hmm |
| 17:40.16 | jcp | JefferyM: I think trepan's, he made the commit |
| 17:40.26 | brlcad | he pulled it |
| 17:40.35 | JefferyM | with no prompting? |
| 17:41.13 | brlcad | oh i'm sure there was some form of prompting, but it's hard to say |
| 17:41.21 | JefferyM | k |
| 17:41.28 | JefferyM | just remembers last time code was pulled |
| 17:41.39 | jcp | what happened? |
| 17:41.58 | JefferyM | long story |
| 17:44.00 | *** join/#bzflag jcp_m2 (n=pocketir@unaffiliated/javawizard2539) |
| 17:46.06 | *** join/#bzflag temp_work (n=temporal@bzflag/serverop/TemporalDistraction) |
| 17:53.10 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 18:02.51 | BulletCatcher | jcp/jcp_m2: The TODO file starts with a "required for release of 3.0" section. I assume Cygal will take care of some of them for GSoC, but others are beyond "bug" scope. |
| 18:04.43 | JefferyM | I think the big things left are bots, maybe some DR |
| 18:05.38 | JefferyM | I'd like to see the change where the client asks if you want to allow images from the host. |
| 18:08.08 | BulletCatcher | Regarding DR, two clients with similar small ping times should see almost exactly the same thing, right? |
| 18:08.10 | BulletCatcher | During one test I was able to see small differences in ricochet timing with two side-by-side clients. |
| 18:08.37 | JefferyM | rico may have issues, as it wasn't really changed much |
| 18:09.05 | JefferyM | and small discrepencies are expected with the current code |
| 18:09.27 | JefferyM | how was the movement of the tanks? |
| 18:10.13 | BulletCatcher | I wasn't paying as much attention to tank movement. With only two it is hard to have a good viewpoint. |
| 18:10.35 | JefferyM | how small were the diffs in rico? |
| 18:11.31 | BulletCatcher | It was just noticeable. Perhaps just a few frames. |
| 18:12.03 | JefferyM | that's not too bad |
| 18:12.10 | BulletCatcher | Would you expect shot ends to be simultaneous with the current code? |
| 18:12.21 | JefferyM | not 100% |
| 18:12.27 | JefferyM | but it should be closer then 2.0.x |
| 18:13.25 | BulletCatcher | I know I am showing high expectations here, but why wouldn't they be within a frame of each other? |
| 18:14.34 | JefferyM | beause there will be small difts in the lag comp clock |
| 18:14.42 | JefferyM | and the code dosn't do a frame sync |
| 18:14.57 | JefferyM | it's just trying to compenstate for what it thinks the general lag is |
| 18:15.03 | *** join/#bzflag Rob5a2 (n=rob5a@dslb-092-078-034-141.pools.arcor-ip.net) |
| 18:15.04 | JefferyM | every packet will have a small variance in lag |
| 18:15.29 | JefferyM | it wasn't trying to get it perfect, just close enough to not cause big problems like 2.0.x does |
| 18:16.12 | BulletCatcher | Okay. I'll adjust my expectations. :-) |
| 18:16.23 | JefferyM | heh |
| 18:16.31 | JefferyM | were you expecting it to be a lockstep system? |
| 18:17.18 | BulletCatcher | I do not expect different clients to have their frames synchronized, but the rest of it ought to be really close. |
| 18:17.31 | JefferyM | a couple frames is really close ;) |
| 18:17.41 | JefferyM | the lag comp I did was pretty basic |
| 18:17.56 | JefferyM | it just added a compensation for what we think the lag is |
| 18:18.25 | JefferyM | as oposed to 2.0.x that does no compensation |
| 18:18.32 | blast007 | I'm still not overly fond of the lag comp, specfically with how it affects bullets (tanks jumping up will have bullets appear to shoot from below their tank) |
| 18:18.35 | JefferyM | so all possitions are behind by the lag time. |
| 18:18.46 | JefferyM | got a better idea? |
| 18:19.05 | BulletCatcher | We might have to make lag comp a client-side option. |
| 18:19.14 | JefferyM | that's a bad idea |
| 18:19.20 | JefferyM | since clients do death too |
| 18:19.54 | BulletCatcher | Ah. Optional will have to wait until death is server-side. |
| 18:19.55 | blast007 | just seems that it causes more problems than it fixes |
| 18:20.06 | JefferyM | unless you want to rewrite it all as an input driven system that is server controlled, this was the simplest way to make a more accurate state |
| 18:20.26 | JefferyM | blast007, if tha'ts true after a good round of play testing, pull it |
| 18:20.34 | JefferyM | but I don't think we can say that with out testing it |
| 18:20.47 | JefferyM | yes some things will be differnet, and feel different from 2.0.x |
| 18:21.07 | JefferyM | but if you feel that a major gameplay element is having meat based lag comp, then pull it. |
| 18:21.42 | JefferyM | cus in your jump case, in 2.0.x you may see him and his shot at the bottom of the jump |
| 18:21.59 | JefferyM | but if you shoot him there, he will not die, because he actualy IS up in the air |
| 18:22.03 | blast007 | I just feel that people with high lag might have an extra advantage |
| 18:22.12 | blast007 | with regard to shooting |
| 18:22.21 | JefferyM | they have an advantage now re dying;) |
| 18:22.59 | JefferyM | when you see a high lag person, the postion on your screen should be more accurate to the postion on thier screen |
| 18:23.03 | blast007 | they can drop down at someone, and to the other player, it will appear that they have already dropped below their height, but on his screen, he's right in front of them and can fire, and then the bullet will basically spawn inside their tank ;) |
| 18:23.19 | blast007 | (or am I wrong there?) |
| 18:23.24 | JefferyM | that can happen |
| 18:23.47 | JefferyM | do you think that happens more or less then a high lag person not dying from a shot? |
| 18:23.52 | JefferyM | what is worse? |
| 18:24.09 | blast007 | I think that when you're able to lead your shots, you can more easily kill someone with lag |
| 18:24.23 | JefferyM | then pull it and part of bzflag is doing meat based lag comp |
| 18:24.40 | JefferyM | I would think that killing is better then shooting, but I may be wrong |
| 18:25.04 | blast007 | needs some more testing to be sure what's better |
| 18:25.09 | JefferyM | indeed |
| 18:25.24 | JefferyM | gonna be a sad release if it dosn't have some kinda lag comp |
| 18:25.29 | JefferyM | mostly graphical changes then |
| 18:26.08 | BulletCatcher | The difference I notice most is that lag comp makes other tanks more jerky in their movement. |
| 18:26.23 | JefferyM | it will make them jerk a bit when they change directions |
| 18:26.29 | JefferyM | since there is no smothing |
| 18:26.36 | JefferyM | but where they are should be more accurate |
| 18:26.41 | JefferyM | it's a tradeoff |
| 18:26.58 | JefferyM | it's up to you guys if you feel it's worth it or not |
| 18:27.03 | BulletCatcher | Yeah. We need more experience with the new lag comp before making a final decision. |
| 18:27.04 | JefferyM | but everyone should have the same code |
| 18:27.21 | JefferyM | I think a lot of people don't like it because it just feels different |
| 18:27.34 | blast007 | I don't like it because shots don't line up ;) |
| 18:27.47 | JefferyM | well no lag comp code was added for shots |
| 18:27.57 | JefferyM | so perhaps that can be fixed with something |
| 18:28.11 | JefferyM | make bzflag turn based, then get the best of both worlds |
| 18:28.28 | JefferyM | or implement a much more complex simulation system. |
| 18:28.39 | JefferyM | if the server did deaths, then we can have clients do smothing |
| 18:28.45 | JefferyM | and make the graphics look better |
| 18:29.35 | JefferyM | the jumps would be smaller on the server too, because it'd only be 1/2 the lag |
| 18:29.42 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 18:34.00 | *** join/#bzflag Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 18:34.00 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 18:36.04 | jcp_m2 | personally, I think accounting for lag is an element of gameplay |
| 18:39.01 | jcp_m2 | and I'd rather have to shoot ahead of people than have to die sporadically because of a lag jumper |
| 18:39.34 | jcp_m2 | goes back to his computer |
| 18:47.58 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 19:09.57 | *** join/#bzflag Will07c5 (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 19:22.03 | *** join/#bzflag jcp1 (n=jw@unaffiliated/javawizard2539) |
| 19:29.21 | *** join/#bzflag Think_Differentl (n=fatass@bzflag/player/ThinkDifferent) |
| 19:41.17 | JefferyM | well if everyone else feels that way, then pull the lag comp |
| 19:41.22 | JefferyM | or move it to a fork |
| 19:41.36 | JefferyM | and assume bzflag will always be played like a lan game |
| 19:42.02 | JefferyM | at that point you also need to make sure that you tell new players that they have to compensate for a changing number as part of gameplay. |
| 19:42.09 | JefferyM | and it's not a bug |
| 20:00.18 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 20:07.27 | brlcad | doesn't feel that way |
| 20:07.50 | brlcad | no DR can be much worse than 'bad' DR |
| 20:09.01 | me1 | jcp1, if someone's lag is jumping around, how would you "compensate for it" anyway? |
| 20:11.35 | CBG | Maybe everyone should play WoW and stop caring already.. |
| 20:22.26 | jcp1 | me1: in my playing experience, players that don't have (relatively) constant lag are few and far between |
| 20:22.38 | me1 | so what are you complaining about? |
| 20:23.11 | jcp1 | that DR with constant lag would cause shots to spawn inside tanks when jumping, as stated above |
| 20:23.41 | jcp1 | It's much easier to compensate, in terms of playing style, for constant lag than it is to avoid a bullet that you can't see |
| 20:24.14 | me1 | I think i'm missing part of a convo |
| 20:24.34 | jcp1 | goes to find it |
| 20:24.44 | me1 | "lag jumper" doesn't sound anything at all as "causeing shots to spawn inside tanks when jumping" |
| 20:25.30 | jcp1 | quote from blast007: ...tanks jumping up will have bullets appear to shoot from below their tank... |
| 20:25.58 | jcp1 | and I think I was connected on my dad's cell, but he mentioned that if a tank jumps up and fires, and has lag, then DR would cause the bullet to spawn somewhat in front of the tank |
| 20:26.07 | jcp1 | once the player gets the message that the bullet has, indeed, been fired |
| 20:26.23 | jcp1 | so some players that are in front of the player that fires wouldn't be able to see the bullet until it is inside of their tank, at which point they die |
| 20:26.48 | CBG | And how is that different to if the enemy is lagging in the first place? |
| 20:26.53 | me1 | if you are right in front of a tank, you have zero time to dodge regardless |
| 20:26.57 | CBG | I doubt the shot would be delayed further... |
| 20:27.52 | jcp1 | me1: no, I mean if the person is lagging 300ms, and you're however far a shot can travel in that amount of time away, then without DR you see the bullet as fired from the tank, but with DR you see it right when it gets to you |
| 20:28.06 | jcp1 | so in one case you might be able to dodge or jump, whereas in the other case you definitely could not |
| 20:29.22 | CBG | jcp1: no, if the enemy is lagging 300ms, you see the shot 300ms+ after it was fired. If the distance between your tank and the enemy's tank is equivalent to that of the distance his shot can travel in 300ms, you die the same moment you see the shot. |
| 20:29.42 | jcp1 | CBG: exactly. Whereas without DR you have 300ms to react |
| 20:29.47 | jcp1 | before the shot hits you |
| 20:30.05 | CBG | jcp1: No, what I described is exactly what happens WITHOUT DR. |
| 20:30.05 | me1 | and this only happens when someone jumps up and shoots at the top of his or her jump? |
| 20:30.11 | CBG | I described the effect of lag. |
| 20:30.24 | jcp1 | CBG: no, you described the effect of lag coupled with DR to compensate for it |
| 20:30.43 | CBG | No. I described the effect of lag. Prove me wrong. |
| 20:30.57 | jcp1 | with lag, the shot doesn't spawn 300ms worth of distance in front of the tank. It spawns where the tank is, just 300ms after the person clicked |
| 20:31.08 | jcp1 | with DR, the shot spawns 300ms worth of distance in front of the tank to other people |
| 20:31.42 | CBG | You know when someone is lagging, you have to shoot ahead of them. Yes? |
| 20:32.09 | jcp1 | Yes. And that's because they see your shot fire 300ms after it really does fire, so they've driven 300ms worth of distance further |
| 20:32.26 | *** join/#bzflag LongDon (n=LongDon@host-091-097-178-059.ewe-ip-backbone.de) |
| 20:32.27 | CBG | Why? Because they are further ahead than they appear to be. Does the same not apply to their shots? That their shots are ahead of where they appear to be? |
| 20:32.35 | *** part/#bzflag LongDon (n=LongDon@host-091-097-178-059.ewe-ip-backbone.de) |
| 20:33.03 | jcp1 | But deaths result from where their shot *appears* to be, not where it really is |
| 20:33.26 | jcp1 | DR causes deaths to result from where the shot really is, and without DR deaths occur where the shot appears to be |
| 20:33.30 | CBG | Is this true? JefferyM/brad ^ |
| 20:34.22 | jcp1 | waits |
| 20:34.48 | CBG | s/brad/brlcad/ |
| 20:34.50 | CBG | (Sorry brad :P ) |
| 20:34.59 | jcp_m4 | yeah, that's kinda what I thought :) |
| 20:35.34 | jcp | wonders if he should ping another person that might know... |
| 20:37.36 | jcp | oh what the heck |
| 20:37.39 | jcp | blast007: ^ |
| 20:38.10 | JefferyM | jcp, I think you have it backwards |
| 20:38.18 | JefferyM | replace tank with shot, and you are right |
| 20:38.37 | JefferyM | you never see where the person that you hit is |
| 20:38.38 | jcp | JefferyM: hmm? The opinion I got from the comments above was that DR was going to be applied to shots too |
| 20:38.47 | JefferyM | jcp, indirectly |
| 20:38.54 | JefferyM | the shots use the tank postion for starts |
| 20:39.03 | JefferyM | so the shot start is DRed |
| 20:39.16 | JefferyM | IIRC there is a timestamp on the shot |
| 20:39.18 | jcp | but what about the forward movement of the shot? |
| 20:39.37 | jcp | Are the logs for this channel live? |
| 20:39.37 | JefferyM | that is burned into the shot vector that is sent with the shot IIRC |
| 20:39.41 | JefferyM | no |
| 20:39.44 | JefferyM | they take a day |
| 20:39.48 | jcp | drat |
| 20:39.51 | JefferyM | why? |
| 20:40.09 | JefferyM | I'm not saying there may not be bugs with the shots and DR as it's implemented |
| 20:40.09 | CBG | I have 14+ hours of scrollback... Why? |
| 20:40.10 | jcp | iirc i was chatting on my dad's phone, which I don't have the history for in this window when the comment I'm looking for was said |
| 20:40.37 | jcp | CBG: go up to somewhere after jcp parted, and there was a comment that the DR would cause shots to spawn inside tanks |
| 20:40.37 | JefferyM | what was said dosn't mater, look at what the code does :) |
| 20:40.46 | jcp | hmm, good point :) |
| 20:40.53 | CBG | Roughly how many hours ago? |
| 20:41.01 | jcp | Probably 30 minutes, maybe an hour |
| 20:41.09 | jcp | was by blast007 iirc |
| 20:41.09 | JefferyM | the DR can cause a client to not see the time from the shot spawn till NOW |
| 20:41.12 | JefferyM | so that is a correct statement |
| 20:41.18 | jcp | exactly |
| 20:41.22 | jcp | that's what I was trying to say before |
| 20:41.26 | JefferyM | but that is where the shot is on the other person's machine |
| 20:41.31 | jcp | right |
| 20:41.36 | JefferyM | what is your other option? to lie to your screen? |
| 20:41.38 | jcp | I'd much rather shoot in front of people than dodge a bullet I can't see |
| 20:41.44 | JefferyM | then you don't die when he thinks he shot you |
| 20:42.00 | jcp | right. Isn't that the way it is with 2.0 now |
| 20:42.01 | jcp | ? |
| 20:42.15 | JefferyM | yes, for all shots |
| 20:42.20 | jcp | exactly |
| 20:42.21 | JefferyM | but you also don't get the advantage |
| 20:42.24 | JefferyM | of DR |
| 20:42.33 | JefferyM | where if you see a shot go thru someone, THEY DIE |
| 20:42.52 | jcp | Right. I'd prefer the disadvantage of having to shoot in front of people to kill them to the disadvantage of being killed by shots I can't see |
| 20:42.52 | JefferyM | so you'd reather have iffy deaths, then accurate shots? |
| 20:43.04 | jcp | pretty much, yes |
| 20:43.30 | JefferyM | that's because you are the person getting killed in that case |
| 20:43.38 | JefferyM | how about the case where you shoot someone and they don't die? |
| 20:43.48 | JefferyM | how do you teach new players that they have to compensate for lag? |
| 20:43.54 | jcp | you tell them |
| 20:44.00 | jcp | Like people do in 2.0 |
| 20:44.20 | JefferyM | and you feel that is a valid game design? |
| 20:44.26 | jcp | Personally, I do |
| 20:44.45 | jcp | but I obviously don't represent the opinion of the bzflag developers as a whole |
| 20:44.49 | JefferyM | every comercial game designer on the planent would say you are full of crap |
| 20:44.57 | jcp | ok, then I guess I'm full of crap |
| 20:45.01 | JefferyM | as I've said, if everyone feels that way, then pull it |
| 20:45.07 | JefferyM | and let bzflag wallow in the past |
| 20:45.20 | jcp | ok. Maybe some sort of poll should be started somewhere to find out what other people think |
| 20:45.20 | CBG | Commercial game designers aint often right. |
| 20:45.20 | JefferyM | when every other internet game in the world can have an accurate state |
| 20:45.27 | CBG | jcp: http://rafb.net/p/aZsZgr21.html |
| 20:45.44 | jcp | oh my gosh. Since everyone who's here now is against me, I'll just pack up my computer right now and head out. Later all. |
| 20:45.44 | JefferyM | CBG, no but they are right more offten then us ;) |
| 20:45.58 | JefferyM | jcp, you arn't alone |
| 20:45.59 | jcp | oh wait, me goes to read the paste |
| 20:46.06 | CBG | JefferyM: quite probably :) |
| 20:46.11 | JefferyM | I'm sure others feel the way you do |
| 20:46.16 | JefferyM | and this IS going to be a big change |
| 20:46.19 | JefferyM | maybe we arn't ready for it |
| 20:46.19 | jcp | there we go |
| 20:46.26 | jcp | <blast007>they can drop down at someone, and to the other player, it will appear that they have already dropped below their height, but on his screen, he's right in front of them and can fire, and then the bullet will basically spawn inside their tank |
| 20:46.34 | CBG | jcp: there are only 3 of us here right now and I don't give a crap either way. ;) |
| 20:46.34 | JefferyM | maybe we have to leave it untill we can make a proper server side system. |
| 20:46.36 | jcp | That's what I was worried about |
| 20:46.45 | jcp | CBG: then why where you arguing like you did? |
| 20:46.58 | CBG | I like to argue. :) |
| 20:47.11 | jcp | That's been obvious for a while :) |
| 20:47.13 | JefferyM | yes at close ranges, if you are within the distance something moves over the lag time, you will see something pop |
| 20:47.22 | jcp | Exactly |
| 20:47.22 | CBG | jcp: xD |
| 20:47.30 | JefferyM | the question is, is that effect worse then not having accurate tank postions? |
| 20:47.33 | jcp | so players with large lag will have quite a bit more advantage than they do now |
| 20:47.41 | JefferyM | and I don't think that question has been answerd yet |
| 20:47.52 | CBG | should be working on his data structures assignment but arguing is much more fun |
| 20:47.56 | JefferyM | they have an advantage in a differnet area |
| 20:48.05 | jcp | I personally think so, because a laggy player can be compensated for by shooting ahead of them, whereas you can't compensate for bullets you can't see |
| 20:48.06 | JefferyM | right now they have advantage in avoidind death |
| 20:48.14 | jcp | but less, because it can be compensated for |
| 20:48.19 | jcp | whereas you can't compensate for invisible shots |
| 20:48.20 | JefferyM | now they have advntage in making shots pop |
| 20:48.25 | JefferyM | ok so pull it |
| 20:48.42 | JefferyM | but I think we should test it first |
| 20:48.47 | jcp | That's fine by me |
| 20:48.51 | JefferyM | if it dosnt' work, it dosn't work |
| 20:48.55 | jcp | (not that I have any authority to decide :) ) |
| 20:49.00 | JefferyM | noone was insisting on keeping it |
| 20:49.10 | JefferyM | so I dont' know why you got all "I'm taking my ball and going home" |
| 20:49.41 | CBG | It's not even his ball! |
| 20:49.44 | jcp | ok, I saw people (like cbg and you) insisting on keeping it, but I probably just misread |
| 20:49.53 | JefferyM | when did I insist on keeping it? |
| 20:49.55 | jcp | well, I'm out for my vacation now. I'll sign on later. |
| 20:50.00 | JefferyM | I simply stated what it was intended for |
| 20:50.08 | jcp | your general attitude suggested that it was a better idea than what's currently there |
| 20:50.11 | CBG | I didn't insist on keeping it, I was just under the impression that you misunderstood the concept. :) |
| 20:50.19 | jcp | but I'm really going to head out for now. Later all |
| 20:50.29 | JefferyM | if shot pops are are more game breaking the innacuate positions, we have to pull it |
| 20:50.32 | jcp | (and I'm not trying to storm off or anything; my parents are just getting mad at me for delaying everyone) |
| 20:50.42 | JefferyM | the problem with your dodge case, is you can't go back in time |
| 20:50.45 | CBG | If I played this silly game anymore, I might insist one way or the other - most likely, I would insist against it like you. |
| 20:50.57 | jcp | ok. Later all for now. |
| 20:51.02 | JefferyM | there will always be distances where there is no way for the client to draw what will happen in the future |
| 20:51.07 | CBG | Bye. |
| 20:51.31 | *** join/#bzflag Will07c5|laptop (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 20:51.38 | JefferyM | the same thing would happen if we had server side deaths, he'd just die :) |
| 20:52.43 | CBG | I say, adjust everyone to have 300ms lag and forget about it. |
| 20:52.54 | JefferyM | that dosn't solve the problem |
| 20:52.59 | JefferyM | or one of the problems |
| 20:53.11 | JefferyM | means you still have to lead based on a non visual value |
| 20:53.32 | CBG | It was supposed to solve any problems. :P |
| 20:53.37 | JefferyM | leading a target is fine, but it should match leading a REAL target, not based on some 'interwebs' value |
| 20:54.02 | JefferyM | you may have menat it as a joke, but it's a valid option, delay the gamestate by a fixed rate |
| 20:54.09 | JefferyM | some games do that |
| 20:54.22 | CBG | I didn't intend it as a joke either. :P |
| 20:54.28 | JefferyM | makes things feel a little slugish, but it can work |
| 20:54.46 | CBG | Yup. |
| 20:54.52 | JefferyM | most action games (FPS) use a server side frame rate with input push IIRC |
| 21:20.19 | *** mode/#bzflag [+o brlcad] by ChanServ |
| 21:30.21 | *** join/#bzflag Pythonoras (n=Pi@94.79.80.126) |
| 21:32.43 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 21:37.52 | *** join/#bzflag kierra (n=jolie@unaffiliated/kierra) |
| 21:40.25 | KingRobot | How deeply is the DR code integrated with the client/server? |
| 21:41.57 | KingRobot | discovers why the robots aren't working :) |
| 21:42.26 | JefferyM | DR is client only |
| 21:42.48 | KingRobot | Why not make it an option then, like that 1980's tank game "Bolo" did? |
| 21:43.04 | JefferyM | so that everyone has the same state |
| 21:43.15 | JefferyM | since death is handled by the client, you want everyone to die in the same predictable way |
| 21:43.38 | KingRobot | Makes sense - it was just a thought after the heated debate ;) |
| 21:43.39 | JefferyM | and going back to OLDER games is not really a good thing |
| 21:43.50 | JefferyM | not all heated debates have merrit |
| 21:43.58 | KingRobot | agrees |
| 21:44.00 | JefferyM | if the current system is not fun to play with, we remove it |
| 21:44.01 | JefferyM | simple as that |
| 21:44.21 | JefferyM | if it simply moves a problem that we have now to a problem that we will have less often, then it is a positive change |
| 21:44.38 | JefferyM | if the changes are equali in effect we have to see what effects fun more |
| 21:45.07 | JefferyM | it's possible this type of DR can't be done untill we have server deaths, then we can do client DR smothing with out worrying about hit accuracy |
| 21:45.33 | JefferyM | during the entire discussion the only thing any developer was insitant on was that we should test it :) |
| 21:47.07 | JefferyM | goes back to making stores work |
| 21:47.59 | KingRobot | http://macintoshgarden.org/games/mac-bzone |
| 21:48.04 | KingRobot | I think the 1992 date is wrong |
| 21:48.07 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 21:48.07 | *** mode/#bzflag [+v spldart] by ChanServ |
| 21:49.46 | TD-Linux | WHOA |
| 21:49.50 | TD-Linux | macintosh garden is back? |
| 21:49.59 | KingRobot | it's a new one, afaik |
| 21:50.20 | TD-Linux | I was angry when it went down |
| 21:50.30 | TD-Linux | I decided to look up some of the really old MECC games I used to play |
| 21:50.37 | TD-Linux | and it turned out it had gone down the day before :( |
| 21:51.07 | *** part/#bzflag kierra (n=jolie@unaffiliated/kierra) |
| 21:51.15 | KingRobot | These guys are loading up mirrors of nearly every mac abandon-ware site in existence. |
| 21:51.30 | KingRobot | And it's user-editable, so the content is going up better and faster than the old site |
| 21:51.47 | KingRobot | Anyway, I got a kick out of the bzone |
| 21:58.08 | KingRobot | Ahh... |
| 21:58.19 | KingRobot | When was bzflag ported to use libtool? |
| 22:05.58 | JefferyM | when the API was made |
| 22:05.58 | JefferyM | LONG ago |
| 22:06.00 | *** join/#bzflag SirMatthew (n=Matthew@c-71-237-204-132.hsd1.or.comcast.net) |
| 22:06.13 | synic | sweet, bzflag shirt is here! |
| 22:06.17 | synic | my coworkers are jealous |
| 22:06.29 | KingRobot | synic: As they should be ;) |
| 22:06.30 | synic | (they just don't know it) |
| 22:06.56 | KingRobot | JeffreyM: Okay - figuring things out one at a time here. |
| 22:08.28 | *** join/#bzflag Yassen (n=chatzill@c-24-16-60-208.hsd1.wa.comcast.net) |
| 22:08.30 | JefferyM | synic, you have one of the last blue ones left. |
| 22:08.40 | synic | I will cherish it |
| 22:08.43 | *** join/#bzflag SirMatthew (i=Matthew@c-71-237-204-132.hsd1.or.comcast.net) |
| 22:08.50 | JefferyM | I think we have one more XXL blue one and that's it |
| 22:23.29 | *** join/#bzflag jcp_m2 (n=pocketir@unaffiliated/javawizard2539) |
| 22:23.31 | spldart | Hrm... shirt... the bzstore only takes paypal doesn't it? |
| 22:24.11 | KingRobot | Are there special flags required for the server to allow bots to spawn and play? |
| 22:26.46 | *** join/#bzflag jcp_m1 (n=pocketir@unaffiliated/javawizard2539) |
| 22:28.02 | Yassen | KingRobot, no, but there is a max at 1 unless specified |
| 22:28.05 | *** join/#bzflag jcp_m1 (n=pocketir@unaffiliated/javawizard2539) |
| 22:28.14 | jcp_m1 | ~ping |
| 22:28.15 | ibot | ~pong |
| 22:30.23 | Yassen | -botsPerIP specifies how many bots can play per ip address and /set _disableBots control how many or if any bots are allowed |
| 22:31.23 | KingRobot | Sure, just making sure I'm not doing something wrong. |
| 22:31.34 | KingRobot | I just tried connecting with a solo bot, and it's working OK |
| 22:32.04 | KingRobot | Thank you |
| 22:38.03 | Yassen | anyone want to check out my robot bug fixes on sourceforge? |
| 22:39.53 | KingRobot | solo or bzrobots? |
| 22:41.09 | Yassen | solo bots |
| 22:50.37 | *** join/#bzflag Carnage00 (n=chatzill@dyn216-8-128-144.ADSL.mnsi.net) |
| 22:52.04 | KingRobot | I'll take a look at them |
| 23:19.22 | *** join/#bzflag bier (n=bier@pD954F0AA.dip.t-dialin.net) |
| 23:22.31 | *** join/#bzflag LongDon (n=LongDon@host-091-097-178-059.ewe-ip-backbone.de) |