From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #73 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/73 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 73 Today's Topics: Re: Intention Re: Intention New file format for tracks Re: New file format for tracks Re: New file format for tracks ------------------------------ Date: Fri, 1 Aug 1997 11:47:54 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Aug 1997, Maido Remm wrote: :)At 02:27 01.08.1997 -0400, you wrote: :)>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 :-). Well, we will have to decide on a way to do it. :)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? Hmmm... good idea, hadn't thought of putting it in .nearby. Maybe we should keep s.nearby like it is, and add s.other_cars with just info about laps and pitting, like what you said above. s.other_cars would be for all cars, s.nearby would only be for the closest cars. Also, I think s.nearby should tell you about people behind you. Or maybe we could just make s.nearby a pointer to the nearby structure, and turn nearby into a linked list, with info about all the cars in like a 100 foot radius, or something. Or would that be confusing to some people? I think that if we did it this way, we wouldn't take too long, but you have to remeber, everything we add is going to take more time somwhere. 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, 1 Aug 1997 12:16:12 -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 Fri, 1 Aug 1997, Ralph Scott wrote: :)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? I don't think it'll be that bad. Just send an email to ech track's creator asking if he'll do it, that'll take care of a bunch. Then the rest just everybody who can, just take one and fix it. We'll want to start on the one's planned for upcomming races first though, you know give them top priority. :)> >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. I don't think it would be too bad. Maybe we could give everybody a working pit function that would get them into the pit area and into their slot, and they could include it in their robot. (I mean actually have a copy of it in their source code) Then if they decide they want to do it differently, why all they have to do is modify it how they want. I would think however, that most would use the code in it and add it to the body of their program, and make it not a function. :)> :)> 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. Cool, how would we do that in C/C++? I know that Java's classes are funky. 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: Sat, 2 Aug 1997 12:16:59 +0200 From: "Krzysztof Langner" To: "Rars mailing list" Subject: New file format for tracks Message-Id: <199708021017.MAA15089@lysander.lysator.liu.se> Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BC9F3D.FA09D0E0" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BC9F3D.FA09D0E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01BC9F3D.FA09D0E0" ------=_NextPart_001_0001_01BC9F3D.FA09D0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to propose new file format for track. This proposition is = very similar to old one, but gives us more flexible structure. The = sample track file is attatched to this message. It should be quit easy = to convert old formats to this new one ( I can even prepare simple = program for this). But what you think about this? I also have some questions. There is a lot of talk about changes in = rars, but: Who will accept this changes and who will prepare new version? Can we agree that the future for rars is Java? If yes can we define = abstract Driver Java class?=20 Krzysztof ------=_NextPart_001_0001_01BC9F3D.FA09D0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 Hi,

I would like to = propose new file=20 format for track. This proposition is very similar to old one, but gives = us more=20 flexible structure. The sample track file is attatched to this message. = It=20 should be quit easy to convert old formats to this new one ( I can even = prepare=20 simple program for this). But what you think about this?

I also have = some questions.=20 There is a lot of talk about changes in rars, but:

Who will = accept this=20 changes and who will prepare new version?

Can we agree that the = future for rars=20 is Java? If yes can we define abstract Driver Java class? 

Krzysztof

  ------=_NextPart_001_0001_01BC9F3D.FA09D0E0-- ------=_NextPart_000_0000_01BC9F3D.FA09D0E0 Content-Type: application/octet-stream; name="Brands.trk" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Brands.trk" ; This is Brands track ; After semicolon we can put some comments ; Each file consist of several sections like [Main] and [Data] ; each section can have different structure ; This files in not case sensitive [Main] ; Main section Version = 1.00 ; Data section format version Segments = 32 ; the number of track segments X_MAX = 3500 ; maximum value of X, Y to be displayed,feet Y_MAX = 2600 Width = 75.0 ; width of race course, feet TRK_STRT_X = 750 ; coordinates of right rail starting point,feet TRK_STRT_X = 2050 SCORE_BOARD_X = 2700 ; coordinates of scoreboard upper left corner SCORE_BOARD_Y = 1000 LDR_BRD_X = 2200 ; coordinates of leader board upper left corner LDR_BRD_Y = 2200 IP_X = 150 ; coordinates of Instrument Panel up. lft corner IP_Y = 2600 LOTIX = 1100 ; coordinates of start of track length message LOTIY = 2500 FINISH = 0.4 ; fraction of 1st segment prior to finish line Radius = degrees ; degrees or radians [Data] ; Track data section 0 500.3 ; ... Hill -76 181 0 312.5 300 46.5 500 68 ; two curves 114.5 0 594 ; cooper straight 400 78 250 70 ;2 curves that add to 148 0 460 -1000 15 0 950 ;pilgrims drop -425 87 0 600 ; david ... straight -250 48.5 0 250 ;westfield -250 30.5 0 187 ;bend -250 35 0 281 ; something belt -200 56 275 36 -200 49 0 375 200 95 0 937 -263 50 -658 81 ;(2 curves) 0 900 -700 41 -330 62 ;(2 curves) 0 250 -500 17 ; Brands hatch should be about 2.6 miles long ------=_NextPart_000_0000_01BC9F3D.FA09D0E0-- ------------------------------ Date: Sat, 02 Aug 1997 17:22:14 From: Maido Remm To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: New file format for tracks Message-Id: <3.0.1.16.19970802172214.439ff9b2@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" At 12:16 02.08.1997 +0200, you wrote: > Hi, > >I would like to propose new file format for track. This proposition is very similar to old one, but gives us more flexible structure. The sample track file is attatched to this message. It should be quit easy to convert old formats to this new one ( I can even prepare simple program for this). But what you think about this? Very nice, but what is the advantage of the new format? How is it more flexible? Do you mean more flexible to put more data in it if we find a way to design pits? I understand that flexibility relies mostly on main program - whether it can understand the track data in multiple forms. With best wishes, Maido ------------------------------ Date: Sat, 2 Aug 1997 19:20:49 +0200 From: "Krzysztof Langner" To: "Rars mailing-list" Subject: Re: New file format for tracks Message-Id: <199708021724.TAA23356@lysander.lysator.liu.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > >I would like to propose new file format for track. This proposition is > >very similar to old one, but gives us more flexible structure. > > Very nice, but what is the advantage of the new format? How is it more > flexible? > Do you mean more flexible to put more data in it if we find a way to design > pits? I understand that flexibility relies mostly on main program - whether > it can understand the track data in multiple forms. If we put new information we can (but don't have to) prepare new program. But we won't have to convert old tracks to new format, because we will know what kind of information is in file. On the other hand we can remove some unnecessary information (maybe SCORE_BOARD_X) and still we will be able to read this file. So we can prepare new version of track file and still read it with old program, or we can prepare new program and still read old file formats And we can put comments anywhere. Krzysztof -------------------------------- End of rars-d Digest V97 Issue #73 **********************************