From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #49 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/49 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 49 Today's Topics: Changing to only one division. Re: problems Newbie on board. . . Re: problems BORS results 24.04 RE: problems RARS version RE: problems Re: BORS results 24.04 Re: I'm a REAL!! newbie. . . Re: Newbie on board. . . Re: I'm a REAL!! newbie. . . RE: problems Re: problems RE: problems ------------------------------ Date: Wed, 23 Apr 1997 21:50:04 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Changing to only one division. Message-Id: Content-Type: text Due to lack of experts, I will condense the two divisions into one, and redo the points. Henning Klaskala is now in second (after recomputing the points). Jas is first. ---ralph ------------------------------ Date: Wed, 23 Apr 1997 18:47:30 -0700 (PDT) From: Mike and Suzanne DeHaemer To: Rars mailing-list Subject: Re: problems Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Apr 1997, Daniel Brooks wrote: ... > If I run the race without our cars, it runs > fine then reboots. If I have our cars, it locks up before I can begin the > race. I didn't have time to figure out which car it was, thought it won't > be hard. > > Also, I tried running it under Windows (grasping at straws), but still > have it a DOS program. After it ran, I got an error message saying that > the program had issued an invalid instruction, and to save all data and > reboot. Well, I tried setting the compiler (Turbo C++ 3.0 for DOS) to > compile only with 8088/8086 instructions via Options|Compiler|Advanced > code generation. Still no luck. I would also suggest turning on all warnings when you compile your cars and eliminate all the warnings that you can. Or at least make sure you understand why the warnings are there. Also turn on array bounds checking. > I believe the problem to be in the really quickly thrown together car. I > hope I can solve the problem, but the invalid instruction bothers me a > little. In my experience teaching C, these type errors are caused by misusing variables. For example, indexing an array out of bounds, having two variables of different types refer to the same location (through pointers), uninitialized pointers, etc. Be especially careful of arrays passed as arguments to functions. One way to catch the error before rebooting is to trap the invalid instruction exception using the signal() function call to install your own exception handler. But this may be more complicated than you need. Mike & Suzanne DeHaemer dehaemer@best.com ------------------------------ Date: Tue, 23 Jan 1996 21:18:35 -0500 From: Kaden Hazzard To: "rars@lysator.liu.se" Subject: Newbie on board. . . Message-ID: <310596FB.7580D700@clover.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, here I am. A measly newbie with only a few years programming experience, trying to get to know more about RARS. Could anyone here send me the last week's worth of this mailing list in a digest form? Thanx in advance. . . -Shiny II ------------------------------ Date: Wed, 23 Apr 1997 20:51:54 -0700 From: Christopher D Lund To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: problems Message-Id: <3.0.1.32.19970423205154.0088ac60@carlsbad.ucsd.edu> Content-Type: text/plain; charset="us-ascii" Ralph writes: >This is a good thing to know. I got the sound idea from one of the cars. >It had code to beep when dead_ahead was set (honking?). Its best used >when you can't see your printfs (like on a graphical screen). Or in cases where the text on the screen can't/shouldn't be disturbed. I like the honking reference, it's both cute and realistic. >The file thing never worked too well for me because i didn't know the >setvbuf trick. It took me a while to figure it out. It works particularly well in Windows programs where the calling order of routines isn't necessarily clear. - Christopher Lund ------------------------------ Date: Thu, 24 Apr 1997 09:54:56 -0300 From: Maido Remm To: rars@lysator.liu.se Subject: BORS results 24.04 Message-Id: <3.0.1.16.19970424095456.08fff78e@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" Here are the results from the second race of BORS 24th April, 1997 ========================================================================== COMMENTS 15 competitors on simple one mile oval at Milwaukee. Five cars from Henning, three from me and three from new driver Steve 'GryMor' Metke. Plus Ralph2 by Ralph Scott Jas and Magic. Qualifying was real close with 6 cars showing almost equal speed (well, five of them had almost equal code). Track was narrow and 100 laps races were a real test for everybody. Who could not avoid other cars was out soon. Nevertheless, there were some cars that survived well. We had only one slow car that caused trouble, Grymc1; others were more or less equally competitive. Unfortunately, this slow car caused more trouble than I expected. In first race many cars could not pass Grymc1 quickly and were following it within short distance. Eventually a bunch of cars was taken out after being hit from behind. Gryma1 and H3 had a real battle in the second half of race. 5 laps before the end H3 refueled, so Gryma1 took the lead. But... it needed refueling just half lap before the finish. Almost a nice win for the rookie robot :-) .Well, second place is also really good. Second race. The trouble car Grymc1 was taken out in first lap, so were other slower cars. The rest of race was real battle between 9-10 cars. Initially they moved in two big groups, carefully following each other. Then one and another slowly accumulated damage and several cars retired. In second half Ralph2 showed impressive driving style and lead by several laps. It went to the last lap as a leader and then collided to H2 that was 12 laps down but decided to refuel. Bad luck, Ralph2 was out of race and H2 took the checkered flag several laps later. Nice race, worth to look at. Third race. First 20 laps decided the winner. Only four cars survived after several big pile-ups. Those were slow Grymc1 and a trio H2-H3-H1. I do not know whether the latter three were programmed to follow each other, but synchronization of their driving was impressive. Carefully passing Grymc1 every lap, they finished together and H2 earned a second win. Jas was a quick car leading in first half of all races but did not survive to the end. Obviously it is designed for road races and the passing tactic is too agressive for ovals. Overall, Henning's cars were a step ahead of others. ========================================================================= SUBMISSIONS Next race is at Indianapolis 2.5 mile oval. 3 races, 50 laps each, -s1 option. RARS version 0.65b, car size 10x15 feets. This track is longer and passing is not as important here as speed. Actually this is the fastest RARS track with average speed exceeding 125 mph. The track has 4 90 degree curves that could demand sligthly different driving style than previous tracks. Submit any number of car source files to mremm@ebc.ee The deadline for submissions is 7th of May 8AM GMT. All robots that have been submitted so far will continue until removed by author. ========================================================== RACE RESULTS All robots of this and following races are public. Download them at http://www.ebc.ee/~mremm/rars/rars.htm or ftp://ftp.ijs.com/incoming (bdrv2404.zip 45kb). If you have PC, you might want to download bexe2404.zip, which contains rars exe file for dos (162kb) and track file. Just type "rars -nr56333" and you will see exactly what happened in the race (all other variables are compiled into program as default). I can post drivers to the list or to anybody who wants it. QUALIFICATION 10 laps solo speed. The best of 2 attempts. 1. H2 91.51 mph 2. H5 91.48 3. H4 91.47 4. H1 91.47 5. H3 91.45 6. Rachel99 91.43 7. Jas 90.91 8. Apex7 90.67 9. Ralph2 88.23 10.Grymb1 87.48 11.Gryma1 87.45 12.Apex1 86.87 13.Magic 86.38 14.Apex5 82.64 15.Grymc1 26.63 RACE 15 cars for 100 laps. The track was mlwaukee.trk. The drivers were: H2, H5, H4, H1, H3, Rachel99, Jas, Apex7, Ralph2, Grymb1, Gryma1, Apex1, Magic, Apex5, and Grymc1. The initial RVG seed was 56333. Results of race 1: starting positions: H2, H5, H4, H1, H3, Rachel99, Jas, Apex7, Ralph2, Grymb1, Gryma1, Apex1, Magic, Apex5, and Grymc1. 1 H3 avg spd 78.30 100 laps 7198 damage 140 fuel 20 pts accum 2 Gryma1 avg spd 79.29 100 laps 622 damage 147 fuel 16 pts accum 3 Grymc1 avg spd 26.65 34 laps 18603 damage 143 fuel 14 pts accum 4 Ralph2 avg spd 80.21 29 laps 30476 damage 111 fuel 12 pts accum 5 Grymb1 avg spd 80.34 6 laps 30067 damage 140 fuel 10 pts accum 6 H4 avg spd 75.02 3 laps 31834 damage 144 fuel 8 pts accum 7 Apex5 avg spd 74.76 3 laps 77620 damage 146 fuel 6 pts accum 8 H2 avg spd 74.48 3 laps 88554 damage 145 fuel 5 pts accum 9 Apex7 avg spd 75.02 2 laps 47627 damage 146 fuel 4 pts accum 10 Apex1 avg spd 79.58 2 laps 30682 damage 145 fuel 3 pts accum 11 Rachel99 avg spd 80.85 2 laps 30267 damage 146 fuel 2 pts accum 12 H5 avg spd 79.67 1 laps 30252 damage 146 fuel 1 pts accum 13 H1 avg spd 65.16 1 laps 30548 damage 146 fuel 0 pts accum 14 Jas avg spd 76.96 1 laps 38636 damage 148 fuel 0 pts accum 15 Magic avg spd 0 0 laps 49622 damage 149 fuel 0 pts accum Results of race 2: starting positions: H2, H5, H4, H1, H3, Rachel99, Jas, Apex7, Ralph2, Grymb1, Gryma1, Apex1, Magic, Apex5, and Grymc1. 1 H2 avg spd 71.87 100 laps 27525 damage 124 fuel 25 pts accum 2 H1 avg spd 71.13 100 laps 24807 damage 129 fuel 16 pts accum 3 Ralph2 avg spd 83.17 99 laps 30095 damage 21 fuel 26 pts accum 4 H4 avg spd 70.29 98 laps 24082 damage 125 fuel 20 pts accum 5 H3 avg spd 69.59 97 laps 27359 damage 128 fuel 30 pts accum 6 Gryma1 avg spd 66.85 93 laps 17849 damage 71 fuel 24 pts accum 7 H5 avg spd 75.29 82 laps 30455 damage 11 fuel 7 pts accum 8 Apex7 avg spd 79.39 55 laps 31012 damage 88 fuel 9 pts accum 9 Grymb1 avg spd 85.53 33 laps 30229 damage 101 fuel 14 pts accum 10 Jas avg spd 90.51 18 laps 31926 damage 127 fuel 3 pts accum 11 Rachel99 avg spd 87.38 6 laps 30180 damage 141 fuel 4 pts accum 12 Apex1 avg spd 82.79 1 laps 66196 damage 147 fuel 4 pts accum 13 Apex5 avg spd 80.95 1 laps 31913 damage 148 fuel 6 pts accum 14 Grymc1 avg spd 0 0 laps 34237 damage 149 fuel 14 pts accum 15 Magic avg spd 0 0 laps 31870 damage 149 fuel 0 pts accum Results of race 3: starting positions: H2, H5, H4, H1, H3, Rachel99, Jas, Apex7, Ralph2, Grymb1, Gryma1, Apex1, Magic, Apex5, and Grymc1. 1 H2 avg spd 79.09 100 laps 14524 damage 141 fuel 45 pts accum 2 H3 avg spd 79.10 100 laps 20761 damage 140 fuel 46 pts accum 3 H1 avg spd 79.09 100 laps 15910 damage 139 fuel 30 pts accum 4 Apex5 avg spd 79.85 43 laps 30422 damage 106 fuel 18 pts accum 5 Grymc1 avg spd 26.64 34 laps 10455 damage 143 fuel 24 pts accum 6 Ralph2 avg spd 80.94 16 laps 30079 damage 129 fuel 34 pts accum 7 Jas avg spd 86.07 15 laps 30220 damage 133 fuel 9 pts accum 8 Grymb1 avg spd 64.67 3 laps 32040 damage 143 fuel 19 pts accum 9 Apex7 avg spd 79.38 2 laps 30918 damage 146 fuel 13 pts accum 10 Magic avg spd 82.43 2 laps 38026 damage 146 fuel 3 pts accum 11 Apex1 avg spd 82.59 2 laps 30396 damage 146 fuel 6 pts accum 12 H4 avg spd 75.97 1 laps 36876 damage 146 fuel 21 pts accum 13 H5 avg spd 85.61 1 laps 36554 damage 147 fuel 7 pts accum 14 Gryma1 avg spd 65.89 1 laps 30005 damage 148 fuel 24 pts accum 15 Rachel99 avg spd 89.84 1 laps 30055 damage 148 fuel 4 pts accum =========================================================== I removed myself from the overall competition. STANDINGS Race points Person 1 2 3 4 5 6 7 Total ____________________________________________________________________________ __________ Henning Klaskala, 22 46 68 bm321465@muenchen.org Jurgen Sang, 42 9 51 jusa@darkstar.bb.bawue.de Ralph Scott, - 34 34 ralph@alpha.netusa.net Sebastien Tixier, 28 3 31 s-tixi95@bat710.univ-lyon1.fr Steve Metke, - 24 24 GryMor@cc.wwu.edu ___________________________________________________________________________ ------------------------------ Date: Thu, 24 Apr 1997 09:26:50 +-200 From: Torben Thellefsen To: "rars@lysator.liu.se" Subject: RE: problems Message-ID: <01BC5094.537CC900@pc-5> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit > > Well, we fixed one problem only to run into another. After we added > > MOVIE.CPP to our prj file, we modified it for our robot and compiled it. > > At first we did Debug|Run to compile and run it, but that showed a rars > > screen briefly and then the computer rebooted. Then we just compiled it > > and went to DOS to run it. It ran fine, but when it went to exit after the > > 2 races, the computer rebooted. What are we doing wrong? Surely it cant > > have been this bad for every body?! > > The rebooting problem is a killer. My usual method for this sort of > thing is to narrow it down via printfs. If they go by too quick, > then I try sounds. Different pitches at different points in the > program. This should at least get you to within 5-10 lines of the > problem spot, if you can't take it from there, try getting back to > the list with your new found knowledge. I've had very good experiences with this little function (transcribed from memory, actual syntax may vary): void DEBUG(char *dumpstr) { FILE *fp = fopen("dumpfile","ra"); if (fp) { fprintf(fp, "%s\n", dumpstr); fclose(fp); }; }; // Use: DEBUG("Here we are"); It writes all your debugging messages into a file (here: "dumpfile"), closing it after every write so that no messages are lost. When your computer comes back up, you can use the dumpfile for debugging while following the flow of the program in another window (assuming a sort of GUI). Hope this helps, Torben ------------------------------ Date: Thu, 24 Apr 1997 12:58:31 +0100 From: "marsh" To: rars@lysator.liu.se Subject: RARS version Message-ID: <19970424105718.AAA5143@sztpc04.iabg.de> This is primarily a question for Ralph and Maido, Are your races run using version 0.65b? And are there any other differences between the versions you are running and the ones which I am likely to download? (This question arises because I see on Maido's web page that it mentions that some changes have been made to correct certain things such as collisions affecting both cars, I want to make sure that the version that I am using is the same as the one which will be used in races). Matt ------------------------------ Date: Thu, 24 Apr 1997 10:14:32 -0700 From: Christopher D Lund To: rars@lysator.liu.se (Rars mailing-list) Subject: RE: problems Message-Id: <3.0.1.32.19970424101432.008b7100@carlsbad.ucsd.edu> Content-Type: text/plain; charset="us-ascii" Torber writes: >I've had very good experiences with this little function (transcribed from memory, actual syntax may vary): > >void DEBUG(char *dumpstr) { > FILE *fp = fopen("dumpfile","ra"); > if (fp) { > fprintf(fp, "%s\n", dumpstr); > fclose(fp); > }; >}; > >// Use: >DEBUG("Here we are"); A couple of points here... >It writes all your debugging messages into a file (here: "dumpfile"), >closing it after every write so that no messages are lost. That's the thing I like about the setvbuf method I wrote of yesterday, namely, you don't have to open and close the file for each write. In any event, (and I don't know that you aren't doing this), if you setup your function as: void DEBUG (char *dumpstr,...) and then use vprintf in (again, a function Borland leads me to believe is standard across platforms), your debug function can be used to dump variables to the file as well, easing the debugging further. - Christopher Lund ------------------------------ Date: Thu, 24 Apr 1997 13:58:42 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Re: BORS results 24.04 Message-Id: Content-Type: text > > All robots of this and following races are public. Download them at > http://www.ebc.ee/~mremm/rars/rars.htm or ftp://ftp.ijs.com/incoming > (bdrv2404.zip 45kb). If you have PC, you might want to download > bexe2404.zip, which contains rars exe file for dos (162kb) and track file. > Just type "rars -nr56333" and you will see exactly what happened in the > race (all other variables are compiled into program as default). I can post > drivers to the list or to anybody who wants it. Is it me, or is bexe2404.zip not in incoming? ---ralph ------------------------------ Date: Thu, 24 Apr 1997 18:13:29 -0400 (EDT) From: Daniel Brooks To: Kaden Hazzard cc: Robot Auto Racing Simulation Subject: Re: I'm a REAL!! newbie. . . Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 23 Jan 1996, Kaden Hazzard wrote: :)I just started messing around with RARS today, and I found your name on :)the mailing list. If you could be of any assistance, please don't laugh :)at my stupidity, could you answer these questions: I'm sure your not stupid, but I'll be glad to try my best to answer your questions. Also, if you sign up on the mailing list, you can then send it to the list (rars@lysator.liu.se) and every body will be able to answer you. :)1. What form do I compile robots to, for DOS? .obj, .lib? Also, what do :)you use for a command line AFTER you compile that? You include it in the project file. Then find in CARZ.CPP where there are a bunch of 'robot ...; robot ...;'. This is where your robot is initilized. Just replace one of the names with the name of your function. Then, down a ways, there is an array defination that contains the function name of the robot, the colors for head and tail, and other things I can't remeber off the top of my head. Any way, replace the same robot name as before with your robot name.I'm pretty sure this is all you have to change. Anyone else out there on the list, Am I correct? ie: if you make a robot called "mine", you would need a 'robot mine' line in CARZ.CPP. I replaced 'cntrl0' to add this my robot, replace which ever you want. Then, a little farther down, you come to the array (I can't remeber the name, car_clrs or something like that), put your function name in the place of the robot you replaced earlier. :)2. For windows, where are the header files for making a .dll robot? I don't know. Look on the FTP site, they prpbably have one for Windows already. Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Thu, 24 Apr 1997 19:04:16 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: Newbie on board. . . Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 23 Jan 1996, Kaden Hazzard wrote: :)Well, here I am. A measly newbie with only a few years programming :)experience, trying to get to know more about RARS. Could anyone here :)send me the last week's worth of this mailing list in a digest form? :)Thanx in advance. . . Look on the main rars page. somewhere on there is a link to a site that archives the mailing list. Look there. Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Thu, 24 Apr 1997 19:27:44 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Re: I'm a REAL!! newbie. . . Message-Id: Content-Type: text > > On Tue, 23 Jan 1996, Kaden Hazzard wrote: > I recognize that name from the robot battle list. > You include it in the project file. Then find in CARZ.CPP where there are > a bunch of 'robot ...; robot ...;'. This is where your robot is > initilized. Just replace one of the names with the name of your function. > Then, down a ways, there is an array defination that contains the function > name of the robot, the colors for head and tail, and other things I can't > remeber off the top of my head. Any way, replace the same robot name as > before with your robot name.I'm pretty sure this is all you have to > change. Anyone else out there on the list, Am I correct? The short description is just to realize that you have to somehow link your driver code into the main program so that it can reference it via an array. > :)2. For windows, where are the header files for making a .dll robot? > > I don't know. Look on the FTP site, they prpbably have one for Windows > already. Presumably you may want the VC++ version. ---ralph ------------------------------ Date: Thu, 24 Apr 1997 19:24:10 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: RE: problems Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 24 Apr 1997, Torben Thellefsen wrote: :)I've had very good experiences with this little function (transcribed from memory, actual syntax may vary): :) :)void DEBUG(char *dumpstr) { :) FILE *fp = fopen("dumpfile","ra"); :) if (fp) { :) fprintf(fp, "%s\n", dumpstr); :) fclose(fp); :) }; :)}; :) :)// Use: :)DEBUG("Here we are"); :) :)It writes all your debugging messages into a file (here: "dumpfile"), closing it after every write so that no messages are lost. When your computer comes back up, you can use the dumpfile for debugging while following the flow of the program in another window (assuming a sort of GUI). Cool, I bet if I combined this with another tip I recieved, it will be very usefull. All I'll have to do is use a C++ syntax. Thanx, Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Thu, 24 Apr 1997 19:02:05 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: problems Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Apr 1997, Mike and Suzanne DeHaemer wrote: :)I would also suggest turning on all warnings when you compile your cars and :)eliminate all the warnings that you can. Or at least make sure you :)understand why the warnings are there. :) :)Also turn on array bounds checking. I'll try this. :)> I believe the problem to be in the really quickly thrown together car. I :)> hope I can solve the problem, but the invalid instruction bothers me a :)> little. :) :)In my experience teaching C, these type errors are caused by misusing :)variables. For example, indexing an array out of bounds, having two :)variables of different types refer to the same location (through pointers), :)uninitialized pointers, etc. Be especially careful of arrays passed as :)arguments to functions. I'll look for this as well. MAybe I messed up CARZ.CPP, and thats why it doesn't work. :)One way to catch the error before rebooting is to trap the invalid :)instruction exception using the signal() function call to install your own :)exception handler. But this may be more complicated than you need. I will learn the signal function, and use it. Nothing else seems to work, not even sounds. I suppose this is because it no longer even gets to my car to play the sounds. Say, do you have to compile in 16 cars ever time, or can you have less? If so, I'll just compile it with out our cars and see what happens. Thanks for all your help, Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Thu, 24 Apr 1997 20:00:56 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: RE: problems Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 24 Apr 1997, Christopher D Lund wrote: :)Torber writes: :)>I've had very good experiences with this little function (transcribed from :)memory, actual syntax may vary): :)> :)>void DEBUG(char *dumpstr) { :)> FILE *fp = fopen("dumpfile","ra"); :)> if (fp) { :)> fprintf(fp, "%s\n", dumpstr); :)> fclose(fp); :)> }; :)>}; :)> :)>// Use: :)>DEBUG("Here we are"); :)>It writes all your debugging messages into a file (here: "dumpfile"), :)>closing it after every write so that no messages are lost. :)That's the thing I like about the setvbuf method I wrote of yesterday, :)namely, you don't have to open and close the file for each write. I was thinking of combining the two so that I wouldn't have to open and close repeatedly. The only problem is that I'm not real sure how it works. I'm going to look in the help files, but I don't use the printf stuff much, so I'm a little rusty on how they work. Ah well, nothing a little practice won't cure. :)In any event, (and I don't know that you aren't doing this), if you setup :)your function as: :) :) void DEBUG (char *dumpstr,...) :) :)and then use vprintf in (again, a function Borland leads me to :)believe is standard across platforms), your debug function can be used to :)dump variables to the file as well, easing the debugging further. I'm assuming that theres something special about vprintf() that allows you to use arguments that can't be known until runtime. If so, I understand the above. Thanks for all your help, Daniel Brooks PS: When we solve this problem, lets write a tutorial about how to fix odd problems in RARS. | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | Ya know, I have a nasty feeling that this is a bug that would stick out like a sore thumb if a real programmer looked at it. -------------------------------- End of rars-d Digest V97 Issue #49 **********************************