From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #72 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/72 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: rars-d@lysator.liu.se Reply-To: rars@lysator.liu.se (Rars mailing-list) ------------------------------ Content-Type: text/plain rars-d Digest Volume 97 : Issue 72 Today's Topics: Re: Intention Re: Intention Rars Race Results for 7-27 Re: Intention Re: Intention Re: Intention Re: Rars Race Results for 7-27 Re: Rars Race Results for 7-27 Re: Intention ------------------------------ Date: Thu, 31 Jul 97 16:34:03 -0500 From: "Jonathan Michael Butzke" To: "Rars mailing-list" Subject: Re: Intention Message-Id: <199707312139.VAA98492@pop03.ca.us.ibm.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > >Another thing I thought of: we would need to put something in the >situation structure that would tell the robot if it was raining or not. >That would be important, and a real driver would be able to tell if it >was or not. We wouldn't have to do the same with the wind because what >driver has his crew tell him which way the wind is from. He might know the >starting direction, though. >:)Yes, we definatly need better sized cars. 15 feet wide is a little large. >:)Hey, maybe we could change the cars to normal size, and just display them >:)bigger until we add the ZOOM stuff?! Would that work? >:) I think someone mentioned this before, but I am wondering what effect adding weather will have when there really isn't a setup for the cars, Do you think that the slight changes in track friction (since it will affect all cars equally) will have a big difference on race outcomes? I guess if the car were better able to cope with the different frictions it might pick a better line around the track just as some cars run better on the hard or soft surfaces now. However, things like wind I don't see having a big enough effect to change race performance (although I have not really studied the physics of wind on racing cars and am therefore speaking purely on conjecture...) I will agree that the two big things are realistic car sizes and better collision avoidance. The first is up to RARS, the second is up to us individually.... just my thoughts.... Jonathan Michael Butzke ------------------------------ Date: Thu, 31 Jul 1997 18:55:23 -0400 (EDT) From: Daniel Brooks To: rars@lysator.liu.se cc: Rars mailing-list Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 31 Jul 1997, Jonathan Michael Butzke wrote: :)>Another thing I thought of: we would need to put something in the :)>situation structure that would tell the robot if it was raining or not. :)>That would be important, and a real driver would be able to tell if it :)>was or not. We wouldn't have to do the same with the wind because what :)>driver has his crew tell him which way the wind is from. He might know the :)>starting direction, though. :) :)>:)Yes, we definatly need better sized cars. 15 feet wide is a little large. :)>:)Hey, maybe we could change the cars to normal size, and just display them :)>:)bigger until we add the ZOOM stuff?! Would that work? :)>:) :) :)I think someone mentioned this before, but I am wondering what effect :)adding weather will have when there really isn't a setup for the cars, :)Do you think that the slight changes in track friction (since it will :)affect all cars equally) will have a big difference on race outcomes? :)I guess if the car were better able to cope with the different :)frictions it might pick a better line around the track just as some :)cars run better on the hard or soft surfaces now. However, things like :)wind I don't see having a big enough effect to change race performance :)(although I have not really studied the physics of wind on racing cars :)and am therefore speaking purely on conjecture...) Well, in a way you are kinda right. I'm wondering, how does the tire's cooeff of friction change as it is used? What we could do is find a way to bas the coeff of friction partially on the amount of use the tire has gotten, and then let the robot change his tires whenever he wants. We would probably want to implement pit stops first, though (they would need to be in a fixed location, say first seg, and they would need a whole seperate peice of track you drive on to pit. Just like in a real race.). We even could have it check and add more wear to the tires is he has meen running into walls, cars, ect. Then we add the weather, and changing tires becomes more important, because if it starts raining half way through the race, everyone is likely to have different amounts of wear on their tires because some have changed them, some haven't. :)I will agree that the two big things are realistic car sizes and better :)collision avoidance. The first is up to RARS, the second is up to us :)individually.... Yea, realistic cars will be better. Also, I was wondering, if I am 15 feet fro the left wall, does this mean my left edge is 15 feet away from the wall, or is my center 15 feet from the wall? It never was really clear which one, but I think it was the second one, because every one's cars use s.to_lft + s.to_rgt for the width, rather than s.to_lft + CARWIDTH + s.to_rgt. TTYL, Daniel Brooks ________________________________________________________________________ __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com / /\ http://www.geocities.com/SiliconValley/Vista/2083 / / \ / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute / / /\ \ \ Electrically Charged Particles Moving at Velocities in / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. / /_/____\ \ \ /__________\ \ \ "We're very sorry, Mister Schrodinger, \_____________\/ but the cat refuses to go in the box." ------------------------------ Date: Thu, 31 Jul 1997 19:06:19 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Rars Race Results for 7-27 Message-Id: Content-Type: text RARS Bi-weekly Race Report & News About Upcoming Races July 27, 1997 RARS is the Robot Auto Racing Simulation, a competition for programmers and an on-going challenge for practicioners of Artificial Intelligence and real-time adaptive optimal control. It consists of a simulation of the physics of cars racing on a track, a graphic display of the race, and a separate control program (robot "driver") for each car. All RARS software and activities are free and open to the public. It runs on DOS, Windows, OS/2, UNIX, Linux, and several other platforms. For more information e-mail to mindwarp@cftnet.com or rscott@netusa.net. Or visit the Rars website at http://www.ebc.ee/~mremm/rars/rars.htm Contents Submissions Todays Races Preliminary lap times Race Report Authors Point Standings Upcoming Races Comments -------------------------------------------------------------------- Submissions Please! Any people who want to submit for the first time please give yourselves more than a day or two (I made that mistake when I started). Submissions are to be SOURCE CODE only. -------------------------------------------------------------------- Here is a repeat of the announcement about todays races: July 13th, (Unlimited Division Races) No. of races 2 Tracks: Castle Combe, Brands Hatch (alternate Hockenheim) Laps: not less than 100/200 miles Software version: 0.64 Surface Type: 1 no practice, random starting order. This is a modified .64 where all cars must cross the finish line once before the race is over. The drivers will be uploaded to ftp.ijs.com to a file called driv0727.zip after the 8-15 session. In the file there will nothing, no public cars to update. -------------------------------------------------------------------- Preliminary lap times Hockenheim (Hock.trk) Car Laps Avg MPH Damage Notes ------------------------------------------------------------- Bulle 97.83 Ralph2 97.55 Apex 89.27 Updated Magic 89.06 Jas 89.05 RW 87.78 Jammer 85.64 SmoothB 85.60 Lilbamb 84.67 Brands Hatch (Brands.trk) Car Laps Avg MPH Damage Notes ------------------------------------------------------------- Bulle 85.69 SmoothB 83.09 Ralph2 81.45 Jas 81.28 Apex 79.91 Updated Magic 77.01 RW 1 74.03 30000+ Jammer 75.35 Lilbamb 73.32 -------------------------------------------------------------------- Race Notes: Race 1: mv0725c1.zip 9 cars for 25 laps. The track was hock.trk. The drivers were: Ralph2, LilBam, Jas, Jammer, RW, Magic, Apex8, Bulle, and SmoothB. The initial RVG seed was 53815. results of race 1: starting positions: Apex8, LilBam, Bulle, SmoothB, Ralph2, Jammer, RW, Jas, and Magic. 1 Bulle avg spd 97.14 25 laps 2689 damage 4 fuel 10 pts accum 2 Ralph2 avg spd 96.22 25 laps 3200 damage 22 fuel 6 pts accum 3 Apex8 avg spd 89.35 23 laps 9893 damage 17 fuel 4 pts accum 4 RW avg spd 87.99 23 laps 15559 damage 20 fuel 3 pts accum 5 Jas avg spd 87.68 23 laps 24726 damage 17 fuel 2 pts accum 6 Jammer avg spd 85.77 23 laps 4393 damage 23 fuel 1 pts accum 7 SmoothB avg spd 85.54 23 laps 12337 damage 30 fuel 0 pts accum 8 LilBam avg spd 83.05 17 laps 30202 damage 44 fuel 0 pts accum 9 Magic avg spd 85.94 2 laps 30209 damage 137 fuel 0 pts accum Race 2: mv0725c2.zip 9 cars for 41 laps. The track was brands.trk. The drivers were: Ralph2, LilBam, Jas, Jammer, RW, Magic, Apex8, Bulle, and SmoothB. The initial RVG seed was 5665. results of race 1: starting positions: Ralph2, SmoothB, Jas, Bulle, RW, Magic, Jammer, LilBam, and Apex8. 1 Bulle avg spd 83.61 41 laps 3035 damage 1 fuel 10 pts accum 2 SmoothB avg spd 81.75 41 laps 21949 damage 2 fuel 6 pts accum 3 Apex8 avg spd 79.83 40 laps 17467 damage 6 fuel 4 pts accum 4 Ralph2 avg spd 77.78 39 laps 17724 damage 21 fuel 3 pts accum 5 Jammer avg spd 75.28 35 laps 30496 damage 39 fuel 2 pts accum 6 Magic avg spd 76.43 24 laps 30903 damage 65 fuel 1 pts accum 7 Jas avg spd 80.5 18 laps 30306 damage 85 fuel 0 pts accum 8 LilBam avg spd 70.82 12 laps 30250 damage 108 fuel 0 pts accum 9 RW avg spd 74.34 1 laps 30120 damage 144 fuel 0 pts accum ---------------------------------------------------------------------- Points for Day Driver Race 1 Race 2 Total Finish Last 5 new-old Total ---------------------------------------------------------------------- Lisa 0.0 6.0 0.0 2.5 8.0 16.5 Jas 3 1 4 5 1.5 3.0 0.0 6.0 4.0 14.5 Lilbamb 0.0 0.0 0.0 0.0 0.5 0.5 RW 4 4 5 1.5 0.0 3.0 0.0 0.5 5.0 Jammer 2 3 5 4 3.0 1.0 1.5 0.5 2.0 8.0 Magic 2 2 0.0 0.0 10.0 4.0 3.0 17.0 Apex 6 4 10 2 6.0 3.0 1.5 0.5 0.0 11.0 Bulle 10 10 20 1 10.0 10.0 6.0 10.0 8.0 44.0 SmoothB 1 6 7 3 4.0 3.0 4.0 2.5 0.0 13.5 ---------------------------------------------------------------------- Finishes Car Total 1 2 3 4 5 6 ------------------------------------------------------------------------------------------------------------------------------------ Lisa 16.5 2 1 1 3 0 0 Jas 14.5 2 2 4 0 1 0 Lilbamb 0.5 0 0 1 0 2 1 RW 5.0 1 0 0 0 2 1 Jammer 8.0 0 2 1 3 4 0 Magic 17.0 2 1 1 1 1 0 Apex 11.0 0 1 2 2 2 0 Bulle 44 5 2 0 0 0 0 SmoothB 13.5 0 0 3 1 0 0 -------------------------------------------------------------------- This is the point standings. Marc Gueury 44.0 pts (Belgium) Bulle Sebastien Tixier 17.0 pts (France) Magic Henning Klaskala 16.5 pts (Germany) Lisa Jurgen Sang 14.5 pts (Germany) Jas Dennis Lew 13.5 pts (Canada) SmoothB Maido Remm 11.0 pts (Estonia) Apex Kim Laurio 8.0 pts (Sweden) Jammer Robert Wilderspin 5.0 pts (Britain) RW Al Davis .5 pts (US) LilBambi -------------------------------------------------------------------- This is the RARS address book. Juergen Sang jusa@darkstar.bb.bawue.de Henning Klaskala bm321465@muenchen.org Al Davis adavis5555@aol.com Kim Laurio kim@ida.his.se Robert Wilderspin rob@feverish.demon.co.uk Sebastien Tixier s-tixi95@bat710.univ-lyon1.fr Maido Remm mremm@ebc.ee Marc Gueury marc.gueury@skynet.be Dennis Lew av504@freenet.toronto.on.ca Upcoming RARS Race Meets RACING SCHEDULE (all races track surface 1) July 13th, Castle Combe and Brands Hatch, Unlimited 100 Miles Alternate: SilverStone (Hock.trk) July 27th, Castle Combe and Brands Hatch, Unlimited 100 Miles Alternate: Hungaring (Hungary.trk) TENTATIVE RACING SCHEDULE (all races track surface 1, v.64) Tentative Alternates: Aug. 24 -- Belgian Grand Prix, Spa-Francorchamps. Sept. 7 -- Italian Grand Prix, Monza. Sept. 21 -- Austrian Grand Prix, Osterreichring Sept. 28 -- Luxembourg Grand Prix, Nurburgring. Oct. 12 -- Japanese Grand Prix, Suzuka. Oct. 26 -- Portuguese Grand Prix, Estoril. -------------------------------------------------------------------- Comments from Ralph ------------------------------ Date: Thu, 31 Jul 97 16:41:44 -0500 From: "Jonathan Michael Butzke" To: "Rars mailing-list" Subject: Re: Intention Message-Id: <199707312146.VAA142558@pop03.ca.us.ibm.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > >What units are we talking about, as far as time goes? Seconds? >Milliseconds? What? > >:)> 3) Perhaps make pitting only work on the first segment? Where the pits >:)> usually are... >:) >:)Is it necessary to make this limitation? Surely the extra compication >:)to make it work on any segment is not too much? > >I think it is. We are striving for an element of realism, and a real >driver can't just stop anywhere he wants and refuel. > I could be wrong but I think he was saying let the track designer put the pits on any segment, not limiting it to the first.... As far as time goes, make it a realistic amount of time, if a car hits a wall in a F1 race, it takes 30+ seconds for a minor bump to a couple of minutes for major damage (assuming the car can even run again...) >I also think the track files should include a couple of entries that >define the pit area. YOu would include info like width, length, start >coords, end coords, left or right side of the track, stuff like that. It >would need to be drawn on the screen, and we might want to have individual >stoping places that the pit() function goes to. (I would want it to >calculate the fastest way to get there to, have the car smoothly >deceleratet to a stop, the accelerate as fast as possible to leave, know >what I mean?) We should maybe provide a bare bones pit() function, but use >overloading to allow the robot to provide it's own, and have another >function that repairs the car, refuels ect. That way it is done >consistantly. Also, maybe the time could be a little more random, say 10s >with a random amount up to 3-4s added on, because no pit stop takes >exactally 12s. Then you would add on time for repairs, maybe >repairAmount^2 or what ever, then with a small random amount added on, >maybe an extra couple of seconds. How about a constant amount for pitting, plus a driver decision on how long to wait for repairs, the longer they wait, the more damage repaired. For the most part a simple pit stop is pretty consistant, I guess the couple of seconds of deviation is more realistic, but I think having a 12s stop with an additional say 1 second for 100 units of repair (with the driver deciding how much to repair on a given stop) would give a fairly realistic time while keeping it straight forward enough to plan around... Jonathan Michael Butzke ------------------------------ Date: Fri, 1 Aug 1997 02:27:45 -0400 (EDT) From: Daniel Brooks To: rars@lysator.liu.se cc: Rars mailing-list Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 31 Jul 1997, Jonathan Michael Butzke wrote: :)>What units are we talking about, as far as time goes? Seconds? :)>Milliseconds? What? :)> :)>:)> 3) Perhaps make pitting only work on the first segment? Where the pits :)>:)> usually are... :)>:) :)>:)Is it necessary to make this limitation? Surely the extra compication :)>:)to make it work on any segment is not too much? :)> :)>I think it is. We are striving for an element of realism, and a real :)>driver can't just stop anywhere he wants and refuel. :)> :) :)I could be wrong but I think he was saying let the track designer put :)the pits on any segment, not limiting it to the first.... As far as :)time goes, make it a realistic amount of time, if a car hits a wall in :)a F1 race, it takes 30+ seconds for a minor bump to a couple of minutes :)for major damage (assuming the car can even run again...) Mmmm... Yea, had not thought of it that way. That would be the best way. :) :)>I also think the track files should include a couple of entries that :)>define the pit area. YOu would include info like width, length, start :)>coords, end coords, left or right side of the track, stuff like that. It :)>would need to be drawn on the screen, and we might want to have individual :)>stoping places that the pit() function goes to. (I would want it to Ok, so the info wee need about a pit would be like this: start seg end seg % before pit % after pit which side of track width length //could these be calculated from above? radius // We could even get really fancy and give each car a seperate little stopping area in the pit lane, just like in a real race. Then we can eliminate collisions between cars that would just stop as fast as they can refuel, then leave. Since they stop near the begining of the pit, others would risk hitting them. If they had a slot to go to, and the HAD to go there, it might be different. Also, maybe we should tell the robot drivers who else is pitting. Maybe put something in the situation structure to say something like cars 4, 6 and 12 are pitting. Maybe we should have an array of structures that gives info about when each car last pitted, average speed since last pit, length of last pit, damage fixed last pit, ect. That way the robot could try to predict if another car is going to pit soon. That would be especially helpful if you are stuck behind some bozo, and think he might pit soon. Then you would be able to take advantage of the chance to pass as soon as he begins to pit. Some thing like that. :)>calculate the fastest way to get there to, have the car smoothly :)>deceleratet to a stop, the accelerate as fast as possible to leave, know :)>what I mean?) We should maybe provide a bare bones pit() function, but use :)>overloading to allow the robot to provide it's own, and have another :)>function that repairs the car, refuels ect. That way it is done :)>consistantly. Also, maybe the time could be a little more random, say 10s :)>with a random amount up to 3-4s added on, because no pit stop takes :)>exactally 12s. Then you would add on time for repairs, maybe :)>repairAmount^2 or what ever, then with a small random amount added on, :)>maybe an extra couple of seconds. Actually, a better idea is to have the robot drive into the pit area himself, and just add an int to the result structure, maybe amPitting, that is a flag that the car is entering the pit area. :) :)How about a constant amount for pitting, plus a driver decision on how :)long to wait for repairs, the longer they wait, the more damage :)repaired. For the most part a simple pit stop is pretty consistant, I :)guess the couple of seconds of deviation is more realistic, but I think :)having a 12s stop with an additional say 1 second for 100 units of :)repair (with the driver deciding how much to repair on a given stop) :)would give a fairly realistic time while keeping it straight forward :)enough to plan around... Yea, something like that, though I like repairAmount ^ 2 / 1000000 * Constant better than just 1:100, though it may end up like that. Either way, you end up with a reliable function. Maybe have a function provided to the robot to calculate how long for a repairAmount, or visa verci. That way the programmer doesn't have to know for sure what the formula is. TTYL, Daniel Brooks ________________________________________________________________________ __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com / /\ http://www.geocities.com/SiliconValley/Vista/2083 / / \ / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute / / /\ \ \ Electrically Charged Particles Moving at Velocities in / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. / /_/____\ \ \ /__________\ \ \ "We're very sorry, Mister Schrodinger, \_____________\/ but the cat refuses to go in the box." ------------------------------ Date: Fri, 01 Aug 1997 10:57:31 From: Maido Remm To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: Intention Message-Id: <3.0.1.16.19970801105731.0a675950@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" At 02:27 01.08.1997 -0400, you wrote: >:) >:)>I also think the track files should include a couple of entries that >:)>define the pit area. YOu would include info like width, length, start >:)>coords, end coords, left or right side of the track, stuff like that. It >:)>would need to be drawn on the screen, and we might want to have individual >:)>stoping places that the pit() function goes to. (I would want it to > >Ok, so the info wee need about a pit would be like this: >start seg >end seg >% before pit >% after pit >which side of track >width >length //could these be calculated from above? >radius // > >We could even get really fancy and give each car a seperate little >stopping area in the pit lane, just like in a real race. Then we can >eliminate collisions between cars that would just stop as fast as they can >refuel, then leave. Since they stop near the begining of the pit, others >would risk hitting them. If they had a slot to go to, and the HAD to go >there, it might be different. Also, maybe we should tell the robot drivers >who else is pitting. Maybe put something in the situation structure to say >something like cars 4, 6 and 12 are pitting. Maybe we should have an array >of structures that gives info about when each car last pitted, average >speed since last pit, length of last pit, damage fixed last pit, ect. That >way the robot could try to predict if another car is going to pit soon. >That would be especially helpful if you are stuck behind some bozo, and >think he might pit soon. Then you would be able to take advantage of the >chance to pass as soon as he begins to pit. Some thing like that. > The pitting itself can be designed in many different ways, I would leave the decision about actual design to the person who is actually starting to do that :-). The truth is we need a pit stops and repair and what is reminded by Daniel: the information about other robots situation. When I designed team for BORS races (where multiple entries per person were allowed) I wanted to know whether my robot is ahead of teammate or not or whether my teammate has gone out of race. Unfortunately, I did not find a way to get that information about other cars. It would be useful to know even in current version how much fuel or damage has the car in front of you. Currently we get only s.nearby.who and s.nearby.braking and s.nearby.for_position. The new members in s.nearby could be .fuel(or .last_pitted_on_lap would be more realistic?) .damage .position .out //if out of race .behind_leader .laps_completed .locating_in_segment# .last_lap_time .best_lap_time etc. This would be nice to know for every car, not only 5 closest cars. Or is that requiring too much computing time? ------------------------------ Date: Fri, 01 Aug 1997 13:02:33 From: Maido Remm To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: Rars Race Results for 7-27 Message-Id: <3.0.1.16.19970801130233.233f22ee@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" At 19:06 31.07.1997 -0400, you wrote: > RARS Bi-weekly Race Report > & News About Upcoming Races > July 27, 1997 >Hockenheim (Hock.trk) > Car Laps Avg MPH Damage Notes >------------------------------------------------------------- > Bulle 97.83 > Ralph2 97.55 > Apex 89.27 Updated Is there a possibility that you actually forgot to update the Apex? Or are you using different filename for the track (hock or HOCK)? Optimized Apex should have done 92 mph. By no means I want to question the validity of current race (I am quite happy with 2 podium finishes:-)) but just to make sure everything will be OK in next race for what the current Apex have been optimized too. With best wishes, Maido ------------------------------ Date: Fri, 01 Aug 1997 09:30:32 -0400 From: Ralph Scott To: Rars mailing-list Subject: Re: Rars Race Results for 7-27 Message-ID: <33E1E4F8.10F6@netusa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maido Remm wrote: > Is there a possibility that you actually forgot to update the Apex? Or > are > you using different filename for the track (hock or HOCK)? Optimized > Apex > should have done 92 mph. > By no means I want to question the validity of current race (I am > quite > happy with 2 podium finishes:-)) but just to make sure everything will > be > OK in next race for what the current Apex have been optimized too. Yes. I thought I had replaced the old with the new, but in reality, I had renamed the new to something close. I reran the races this morning, apex came in (Hock)7+ and (Brands) 3rd. We'll keep the old results. ---ralph ------------------------------ Date: Fri, 01 Aug 1997 09:39:37 -0400 From: Ralph Scott To: Rars mailing-list Subject: Re: Intention Message-ID: <33E1E719.1F11@netusa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maido Remm wrote: > > At 02:27 01.08.1997 -0400, you wrote: > > >:) > >:)>I also think the track files should include a couple of entries that > >:)>define the pit area. YOu would include info like width, length, start > >:)>coords, end coords, left or right side of the track, stuff like that. It > >:)>would need to be drawn on the screen, and we might want to have individual > >:)>stoping places that the pit() function goes to. (I would want it to > > > >Ok, so the info wee need about a pit would be like this: > >start seg > >end seg > >% before pit > >% after pit > >which side of track > >width > >length //could these be calculated from above? > >radius // > > This is all nice, but who will do the work to redo all the track files? > >We could even get really fancy and give each car a seperate little > >stopping area in the pit lane, just like in a real race. Then we can This seems to me to require too much of the driver. > > The truth is we need a pit stops and repair and what is reminded by Daniel: > the information about other robots situation. > When I designed team for BORS races (where multiple entries per person were > allowed) I wanted to know whether my robot is ahead of teammate or not or > whether my teammate has gone out of race. Unfortunately, I did not find a > way to get that information about other cars. > It would be useful to know even in current version how much fuel or damage > has the car in front of you. Currently we get only s.nearby.who and > s.nearby.braking and s.nearby.for_position. > > The new members in s.nearby could be > .fuel(or .last_pitted_on_lap would be more realistic?) > .damage > .position > .out //if out of race > .behind_leader > .laps_completed > .locating_in_segment# > .last_lap_time > .best_lap_time > etc. > This would be nice to know for every car, not only 5 closest cars. Or is > that requiring too much computing time? What I did for java rars was to allow anyone to access any of the other cars information. All of it. I then intended it to be all read-only. I also then had a routine to compute the relative information on an as-needed basis. Which I think wound up being used for collision detection anyhow. ---ralph -------------------------------- End of rars-d Digest V97 Issue #72 **********************************