TRACK.TRK FILE Updated February 25, 1997 Info from Andre De'Boer Info from Chasman (And we thought 3do's were complicated !!!) The trk file is made up of 4 byte signed integers and can be broken into 4 parts. These parts are: 1) The header 2) Part 1 3) Part 2 4) Part 3 Each part seems to have a very unique purpose. The header will identify the file as a trk file and then define the remaining parts of the trk file. Part 1 gives the sector position and seems to define bankings, vertical and 3d movements. Part 2 relates to the track surface seems to define where some visual effects (smoke, dirt) are used by the sim and may also contain information on the grip levels of each different surface. Part 2 is probably the easiest part of the file to understand. Part 3 defines the sector size and position of walls and objects alongside the track. Papyrus uses two different positions. These are: 1. a centerpoint where sector positions are related. This point (on ovals) is in the middle of the infield. 2. a racing line is used that runs in the middle of the race track starting at the start/finish line. Part 3 still holds many mysteries. =================================================================== I WILL GIVE THE NEXT INFORMATION IN REGARDS TO THE ROCKING.TRK FILE =================================================================== THE HEADER: Byte 0 to 7 - File id. The values used here are identical in every trk file. Bytes 8 to 11 - Track length in 50th of an inch. A simple formula to calculate track size is: (hex value/((5280*12)*50)) Where 5280 is feet per mile 12 is inches per foot and 50 is 50th of an inch. The value to divide the hex value by will always be 31,680,000 For example a quarter mile would equal 80D97800 and a third mile would equal F521A100. Bytes 12 to 15 - Number of bytes multiplied by 32 used per sector in the first part of the file. For example 3x32 at Rockingham and 4x32 for Bristol. The higher the value used here, the more accurate the turns can be made. Bytes 16 to 19 - Number of sectors Bytes 20 to 23 - Length (in bytes) of part 2 Bytes 24 to 27 - Length (in bytes) of part 3 Bytes 28 to 67 - Don't know. A multitude of theories exist about these bytes. Here is what we know for certain: There are either 3 or 4 values used. If there are 3 values used the first number is always negative, the second number is always positive and the third number is always positive. The third number is also ALWAYS E093 0400 (or 300,000). Now the first number is also a large negative number (usually -300,000) but this varies at five tracks. The second number is also a large positive number but varies widely from track to track. Now if 4 values are used, the first number is always negative and the third and fourth number is always positive. The fourth number is always Eo93 0400 (or 300,000). The second number was thought to be always negative but this was blown when Michigan was looked at. Michigan uses a neg, pos, pos, pos. Again the numbers are always quite large with the first one being in the range of -300,000. I suspect that this last value used (E093 0400) might be used to tell the sim that something is ending or starting in the file. But I don't know. Also, Andre suspects that because of the large values used, that these are somehow set by humans and not calculated by computers. Now I did some experimenting with some of the bytes and here are the results: Halve 28 to 31 - places my car in the middle of the infield with imaginary boundaries all around that can not be crossed. If I attempt to cross the boundaries (they are invisible) my car gets bounced like its inside a pinball game. Double 28 to 31 - places my cars pit on the race track. Also places pits of other cars just to the right side of the pit wall (on ovals). Also my car rides higher (up to the top of the retaining wall), but when I hit other cars I hit them square. So it affects all other cars as well. Changing byte 28 alone - Did nothing. Although I did not test it for damage to other cars. An original thought I had was that this byte had something to do with the surface of the track, but I have pretty much threw that theory out. But, I do believe my car felt looser when I lowered the value and tighter when I raised it. But I am not certain. Byte 29 - This byte (I think) moves where the sim thinks the walls are. What I mean is that the 3do files draw the walls, but the trk file tells the sim where they are supposed to be. Therefore I believe the two files work together (but are still separate). An example. Change the byte at Rockingham to 73 and the walls move a half lane to the left. My car is pitted to the right of the other cars by a half car width. Now if you hit the inside pit wall (from pit lane) you will become a pin ball. Now hit the outside pit wall and the car will hang up on it slightly and kind of drive through it. It will get stuck there. Now the walls around the track itself are still drawn in the same place, but try and hit them. The car will hit the wall a full half car width before where the wall is actually drawn. What I concluded from this is that these bytes have something to do with where the sim thinks damage is to occur. It may also have something to do with how severe damage is when it does occur. But I am not sure of either. Bytes 30 and 31. These make the first value a negative number and cannot be altered. When I tried to change them to a positive number, I was placed outside of the racetrack and from the appearance of it I was maybe a mile or two away. As I drove toward the track (the sim let me get close) then it locked up and crashed the computer !!! I don't know what effect changing there negative value would have. Bytes 32 to 35 - Don't know Bytes 36 to 39 - Don't know Bytes 40 to 67 - Have a value of zero. Don't know of any significance here. Bytes 68 to 135 - Start of the sector information for part 3. Doubling the all values here does nothing. Changing just one value will crash the sim as it can no longer get the proper sector info. BYTE 135 is the end of the header. =========================================================================== PART 1 Part 1 starts at byte 136. Each sector is divided into value (byte 12) parts. The first 6 integers contain banking/vertical/3d movement information. At straight sectors, the last 2 integers give X/Y angle info as related to the center point. Turns use pre-last integer only. A positive value means a left turn and a negative value means a right turn. The last integer is always CCCC CCCC. Changing it does nothing. What I can do so far is remove the bankings. I am not (as of yet) able to alter the banks. I believe it has something to do with the x(1), y(1), x(2), y(2) at every sector. But my math sucks so I am having trouble creating the triangle. At Rockingham, the first part ends at byte 1767. per Bristol.trk file: We can identify 64 distinct sectors to the Bristol track. There are two possible ways this can be calculated: 1) Byte 12 (4) x Byte 16 (16) = 64 2) 2180 bytes (to end of Part 1) - 132 (header bytes) = 2048/32 = 64 I would tend to lean towards the first theory though. This needs to be checked out some more. The Bristol track is divided like this: sectors 1 to 4 - front straight starting at start/finish line Sectors 5 to 16 - Turn 1 Sectors 17 to 28 - Turn 2 Sectors 29 to 36 - Back Straight Sectors 37 to 48 - Turn 3 Sectors 49 to 60 - Turn 4 Sectors 61 to 64 - front straight ending at start/finish line Every 3rd and 4th sector have identical values. This means sectors 3 and 4 are identical, sectors 7 and 8 are identical, sectors 11 and 12 and so on. Byte 1 - Vertical Info Byte 2 - Vertical Info Byte 3 - Bankings Byte 4 - Bankings Byte 5 - 3d Movement (always triple of Byte 1) Byte 6 - 3d Movement (always double of Byte 2) Byte 7 - x/y axle info Byte 8 - x/y axle info ========================================================================== PART 2 Info comes in 3 integers. The first and second are positions at the track (as related to the start finish line). The third is the surface type (and from what I can tell also tells the sim what visual effect is to be used there [smoke/dirt]). I have noticed that often times bytes 1 and 2 are identical. I do not understand why, and must look further into this. The values I have seen so far are: 1E = Yellow lines 2E = Asphalt 36 = White Lines 06 = Grass 16 = Dirt 26 = Concrete I also believe that each of these has there own grip level. For example, I changed the Dover file to concrete and came up with the AI cars running slower. I changed my Expo Speedway to asphalt and the cars ran faster speeds (by around 1mph). I changed Arrowhead to dirt and the cars slowed dramatically. Now changing any of these values will only affect what the sim thinks is there. It will not actually alter the surface. That info is contained in the 3do file. What I mean is if you alter all asphalt (2E) to read as dirt (16), when you skid, you'll throw dirt on the asphalt surface drawn by the 3do. Now using Bristol as an example we can divide the track into subparts as follows: Byte 12 multiplied by Byte 16 = 64. Therefore we know that part 2 will have 64 separte parts to it. The file starts at the start/finish line and the first 4 parts take us to turn 1. Turn one is comprised of 12 parts, turn 2 of 12 parts, the back straight of 8 parts, turn 3 of 12 parts, turn 4 of 12 parts and finally the last half of the front straight of 4 parts. OR if we want to make it simple (number of sectors [byte 17] x 04 [byte 12]) I have checked it out at only Rockingham and Bristol and the formula works at both. I have not checked it out on all tracks. At Rockingham, the second part ends at byte 2595. ========================================================================= PART 3 Each sector is described in a similar way to part 2. A straight sector starts with a 01. A turn with a 02. After this follow 6 integers per sector. I don't have a clue what they are used for. Then 2 more integers and CCCC CCCC for turns and four more values for straights (I think they are related to the centerpoint). Then follows the sector number (related to byte 12). They start at 0 and add to each sector value (byte 12). At Rock they would be 0..3..6... Then again two integers that might be sector length (I'm not sure of their use). It may be something like this tho -- Integer2 = int1 + int2 of the previous sector. The next integer tells the number of walls per sector (2 for normal sectors and 3 for sectors with a pitwall). The next integer is either a 04 for left side walls or a 06 for right side walls. Then we have two more integers for the wall position and CCCC CCCC. This is repeated if there is a second or third wall. So each wall is 04 aa aa aa aa bb bb bb bb CC CC CC CC CC CC CC CC.