From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #74 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/74 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 74 Today's Topics: Re: New file format for tracks Re: New file format for tracks Re: New file format for tracks ------------------------------ Date: Sat, 2 Aug 1997 16:02:10 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Re: New file format for tracks Message-Id: Content-Type: text > 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 like it. But there were many things we wanted to do with a new track format. I will have to look for all the things we wanted to add. I have it stored around here somewhere. > > Who will accept this changes and who will prepare new version? Whoever is running the races. ANyone who wants to. > > Can we agree that the future for rars is Java? If yes can we define = > abstract Driver Java class?=20 No. But don't let that stop you. I personally had made a parent driver class (not abstract). ---ralph ------------------------------ Date: Sat, 2 Aug 1997 17:09:28 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: New file format for tracks Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 2 Aug 1997, Krzysztof Langner wrote: [NON-Text Body part not included] Well, it seems as if my email didn't like the message I'm replying to. But, we were talking about a new format for the track file. I kinda like it because it is easier to read. However, we will have to adapt the current code to accept to the new format. Another con is that we will have to adapt all the old track files to the new format. However it does seem like it would have it's benifits. I'm thinking that the various items in the first section don't have to be in any particular order. That would be good because it means it shouldn't be to hard to add new kinds of data to the file (ie: pit stop stuff). I like this idea. I think we should adopt it as the next format, just because it'll be more extensible in the future. Now we have to decide what we do first. We all pretty much aggree we need better pit stops. Also some of us have some ideas for changes in other areas, such as weather simulations. Which do we do first? We can't possibly do therm all at once, not in my opinion anyway. I think we should do them in this order: Pit stops - This will involve mostly changes to the display part so that it can display forked segs, ect. New track files - This will involve rewriting the code to get info from the trk file. Should be simple enough, but I've never worked with files in C yet. Weather - This one will be the most time consuming. It adds a whole new section to the calculations. The weather will be the hardest to do, just because it will have to track lots of data, and be optimized for effencieny. I'd be glad to help with all the coding that will need to be done, but I don't have much access to a computer that can handle RARS. I live in Tampa, Florida. Where is everybody else? Perhaps I could write things here on my computer, test them in dummy progs (no graphics, just data print outs to see if it worked, I've done it before, but never with such a large program), then mail them to somebody who can test them in a real copy of RARS, and tell me if it worked. It would be easiest forme to work on the weather. Let me know what you think. 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: Sun, 3 Aug 1997 09:58:42 +0200 From: "Krzysztof Langner" To: "Rars mailing-list" Subject: Re: New file format for tracks Message-Id: <199708031135.NAA15287@lysander.lysator.liu.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Daniel Brooks wrote: > ... But, we were talking about a new format for the track file. I kinda like > it because it is easier to read. However, we will have to adapt the > current code to accept to the new format. Another con is that we will have > to adapt all the old track files to the new format. However it does seem > like it would have it's benifits. I'm thinking that the various items in > the first section don't have to be in any particular order. That would be > good because it means it shouldn't be to hard to add new kinds of data to > the file (ie: pit stop stuff). I like this idea. I think we should > adopt it as the next format, just because it'll be more extensible in > the future. Now we have to decide what we do first. We all pretty much > aggree we need better pit stops. Also some of us have some ideas for > changes in other areas, such as weather simulations. Which do we do first? > We can't possibly do therm all at once, not in my opinion anyway. I think > we should do them in this order: > > Pit stops - This will involve mostly changes to the display part so > that it can display forked segs, ect. > New track files - This will involve rewriting the code to get info from > the trk file. Should be simple enough, but I've never > worked with files in C yet. > Weather - This one will be the most time consuming. It adds > a whole new section to the calculations. I think that first we should prepare new track files. Mainly because it is the simplest thing to do, and because pit stops needs new track file format too. I can prepare new DOS version (If you don't mind) so the program will be able to read both old and new format. I'd prefer to add one feature at the time. So maybe first new track file than next thing. So what kind of information do we want in a new track file (maybe background picture of the track?) I think that I should explain myself. Yes I don't have any robot yet. The reason for this is that I'm currently working on Win95 version of rars and as all of you I don't have enough spare time. But for sure I'll do it. Krzysztof I'm from Gdansk, Poland. -------------------------------- End of rars-d Digest V97 Issue #74 **********************************