ICR2: Nazareth Timing Bug?

I attempted to update the Record for this track. I plugged in Tracy's qualifying time. The resulting speed when I loaded the track was about 3 mph faster than the actual speed posted by EDS scoring. Does this indicate that the time/scoring in the simulation is also wrong? Does this have something to do with the fact that the track in real life is actually shorter than 1-mile? Rick, can you shine your infinte wisdom and knowledge on this? -- **************************** Michael E. Carver ************************* Upside out, or inside down...False alarm the only game in town. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./. [- < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

Yes, it does. The 3D models of several of the tracks do not exactly match the lengths in the <track>.TXT files, so your times/speeds do not correspond to what you think they should. I'm trying to get a list together of how long ICR2 thinks each track is so that we can put it in the README.TXT for DOS 1.1 and Windows 95/Macintosh 1.0... Rick Genter Technical Lead, IndyCar Racing II Sierra On-Line, Inc.

I suspect that the difference has to do with how the track length is defined. You can actually MEASURE the lap time, but you can't measure the average lap speed. The lap speed (whether in the sim or in real life) is COMPUTED from the lap time and the track length. It's hard to say what the true track length is, as this depends on how you decide to measure it. For example, you could measure the track length as the length of the inside white line; as the length of the outside white line; as the length of the center of the track; as the length of the racing line; ... If the sim is reporting an average speed 3 mph faster than the speed reported in real life, that is because they have defined the track length to be slightly longer than CART (or whoever). These track lengths are somewhat arbitrary anyway, so IMHO Papyrus should have found out from CART (or whoever) what they were using for track length and used the same value. FYI, the track lengths used by Papyrus for the speed calculations are also different between ICR1 and ICR2. You might try putting Tracy's time into ICR1 and see what speed is reported then. -- Mike Corrigan

: >Does this indicate that the time/scoring in the simulation is also : >wrong? Does this have something to do with the fact that the track in : >real life is actually shorter than 1-mile? : > : Yes, it does. The 3D models of several of the tracks do not exactly match : the lengths in the <track>.TXT files, so your times/speeds do not : correspond to what you think they should. : I'm trying to get a list together of how long ICR2 thinks each track is so : that we can put it in the README.TXT for DOS 1.1 and Windows 95/Macintosh : 1.0... : Rick Genter : Technical Lead, IndyCar Racing II : Sierra On-Line, Inc. Well I have done some calculations and ICR2 thinks this track is 0.9872 miles long. It may actually be this in real life too. During ABC's coverage of the race one of the announcers mentioned that the track is actually less than a mile in length. I just can't find any place that says this is anything but a 1-mile oval, however. So if you want to put Paul Tracy's new record in the RECORDS.TXT file and want the speed to show his actual speed use the number 19115, this should produce the speed of 190.737 in the record box. Now what this means is that our records are inflated by 1.28% over actual times on the real track. I am wondering if Papyrus miscalculated the RELS number for this track in the NAZARETH.TXT file. . . -- **************************** Michael E. Carver ************************* Upside out, or inside down...False alarm the only game in town. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./. [- < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

It's not the times that are off, but the speeds. The times reported are correct, it is the calculated speeds which don't match. Of course, it is difficult to say how 'long' a track is as it depends on the line you decide to measure. The RELS number has no affect on either the measured time nor the calculated speed. -- Mike Corrigan

: It's not the times that are off, but the speeds. The times reported are : correct, it is the calculated speeds which don't match. Of course, it is : difficult to say how 'long' a track is as it depends on the line you decide : to measure. But there is a correlation between speed/time/distance. The time to travel a measured amount of distance is where the speed comes in. They calulcate the speed by dividing the distance by time. Since they have the length of the track off, this will affect the speed as well as the time. At a give speed it will take longer to traverse 1 mile than .928 miles. It's all tied together. : The RELS number has no affect on either the measured time nor the : calculated speed. But, if the calculations are off RELS needs to be adjusted to either slow down or speedup the field to bring it in line with the real speeds run an a track of greater distance. : Mike Corrigan -- **************************** Michael E. Carver ************************* Upside out, or inside down...False alarm the only game in town. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./. [- < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

Quoted text (11 lines)

>: It's not the times that are off, but the speeds. The times reported are >: correct, it is the calculated speeds which don't match. Of course, it is >: difficult to say how 'long' a track is as it depends on the line you decide >: to measure. >But there is a correlation between speed/time/distance. The time to >travel a measured amount of distance is where the speed comes in. They >calulcate the speed by dividing the distance by time. Since they have >the length of the track off, this will affect the speed as well as the >time. At a give speed it will take longer to traverse 1 mile than .928 >miles. It's all tied together.

They do calculate the speed by dividing the distance by time. The time is MEASURED (i.e. with a clock). Having the wrong track length does not affect the time in any way. Of course, you could argue that the simulation might allow you to get around the track in less time if it thought the track was shorter, but I don't think that is the problem. In fact, ICR2 uses EXACTLY the same physical model for the tracks as ICR1 does. What is different in ICR2 is the number used for the track length when computing the speed. It is as if they decided to measure the existing track's length on a different line, thus coming up with a different value. For example, let's suppose that Tony George decided to remeasure the length of the track at Indy. He picks a particular line around the track and measures it as 2.55 miles. That wouldn't have any affect on the TIME a car takes to complete a lap, but it would have an affect on the SPEED calculated from the time. For example Tony Stewart had a practice lap yesterday with a lap time of 38.116 seconds. His reported speed was 236.121. With the length specified as 2.55 miles his reported speed would have been 240.844. His time (and the actual track) wouldn't have been affected at all. If Papyrus changed the constant they use to compute speed from time so that they would report the same lap speed for a given lap time as would happen in real life, that wouldn't have any affect on how much time it took for the AI to get around the track (nor on how fast you can get around the track). -- Mike Corrigan

: They do calculate the speed by dividing the distance by time. The time : is MEASURED (i.e. with a clock). Having the wrong track length does : not affect the time in any way. Of course, you could argue that the : simulation might allow you to get around the track in less time if it : thought the track was shorter, but I don't think that is the problem. : >But, if the calculations are off RELS needs to be adjusted to either : >slow down or speedup the field to bring it in line with the real speeds : >run an a track of greater distance. : If Papyrus changed the constant they use to compute speed from time : so that they would report the same lap speed for a given lap time as : would happen in real life, that wouldn't have any affect on how much : time it took for the AI to get around the track (nor on how fast you : can get around the track). I guess we are straying away from the original point. I guess I am concerned that Papyrus's programs may be using the wrong track length to calculate speed and time. Is the problem only in the RECORDS.TXT file or all of the results skewed? This question is based on Rick' following reply which appeared earlier in this thread: Newsgroups: rec.autos.simulators Subject: Re: ICR2: Nazareth Timing Bug? Date: 29 Apr 1996 19:31:10 -0400 Yes, it does. The 3D models of several of the tracks do not exactly match the lengths in the <track>.TXT files, so your times/speeds do not correspond to what you think they should. I'm trying to get a list together of how long ICR2 thinks each track is so that we can put it in the README.TXT for DOS 1.1 and Windows 95/Macintosh 1.0... Rick Genter Technical Lead, IndyCar Racing II Sierra On-Line, Inc. -- **************************** Michael E. Carver ************************* Upside out, or inside down...False alarm the only game in town. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./. [- < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

My point was that they don't use the track length (right or wrong) to get the lap time. The lap time is measured using your CPU's timer. The lap speeds are computed from the measured time using an arbitrary track length. It is clear that the track length used by Papyrus in ICR2 is different than the length used in real life (by CART, or whoever). That is why the lap speed reported by ICR2 is different than you would see in real life (for a lap with the same lap time). It is also different than the value they used in ICR1 even though the physical models of the tracks are identical between ICR1 and ICR2. As far as I can tell (and I've spent a lot of time working on this to get EDITRPY to report the 'right' lap speeds) ICR2 uses the same track length when converting the times recorded in the RECORDS.TXT file as it does when computing your lap speeds from your measured lap times. The net: all of the results are skewed.

Quoted text (22 lines)

>This question is based on Rick' following >reply which appeared earlier in this thread: >Newsgroups: rec.autos.simulators >Subject: Re: ICR2: Nazareth Timing Bug? >Date: 29 Apr 1996 19:31:10 -0400 >E. Carver) writes: >>Does this indicate that the time/scoring in the simulation is also >>wrong? Does this have something to do with the fact that the track in >>real life is actually shorter than 1-mile? >>Rick, can you shine your infinte wisdom and knowledge on this? >Yes, it does. The 3D models of several of the tracks do not exactly match >the lengths in the <track>.TXT files, so your times/speeds do not >correspond to what you think they should.

It's worse than you might think from this. The values in the <track>.TXT files are some nominal values (probably the ones used in real life). The physical models (i.e. the size of the track that you actually see and experience when driving the sim) represent the track in what I call Papyrus units (they are about 1.3 cm). In ICR1 these units were pretty consistent from track to track. (i.e. always about 1.30043 cm) I computed the 1.30043 cm based on the track length that you can compute by taking the lap time and lap speed from an ICR1 results file (or the records.txt file in ICR2). In ICR2, the tracks are physically modelled exactly the same as in ICR1 (i.e. they contain exactly the same number of Papyrus' units) but the number used to compute lap speed from lap time is now different and causes the logical size of the Papyrus' units to vary quite a bit. I don't think that these changes are inherently 'right' or 'wrong' as the track length is arbitrary anyway. (how do you measure the length of a track with a finite width anyway?) -- Mike Corrigan