back to TEIC home
last update october 16, 2001
on this page please find descriptions of common trackediting problems and their discussion. as gp2 and gp3 are pretty similar both are covered here. but (unfortunately) the list is far from complete.
this list only features problems you may have to face when trying to load and drive the track in gpX. problems with trackeditor programs are not covered.
any contribution is very welcome !
track does not load(freeze)
track does not load (GP3: fall back to windows desktop)(updated! oct 16. 2001)
track does not load: "wrong file type"(updated! oct 16. 2001)
track works in practice but crashes in race
gpX crash: "Divide by
gpX crash: "attempt to print outside message buffer"
gfx-bug: floating line
gfx-bug: grey ghostline on track
gfx-bug: ghost pit lane
gfx-bug: Tunnel effect
gfx-bug: warping textures
gfx-bug: scenery bleeds into track and driving is freezed for a few seconds
gfx-bug: scenery flashing
gfx-bug: starting light does not work
gfx-bug: empty pit lane at entry
gfx-bug: empty road somewhere near pit lane entry
"venetian blind corruption"
This list would not have bee possible to make without the many contributions of the following people (alphabetical order):
Frank Ahnert, Paul K Arnall, Marcel "babbel" Boorsbom, Ando Bosch, Dan Chinnapen, Bob Culver, Andrew Daley, Les "Fat Rat" Danyluk, Glen Durden aka "alfa", Roland "Romeo" Ehnstrom, Dennis Grebe, Paul Hoad, Michael 'NRG' Hompus, Vaino Iso-Hannula, Paul J. Josephson, Martijn Keizer, John K, Peter L Kessler, Brett Knuchel aka "Knuckels", Graeme Nash, Obi Offiah, Robin de Paus, Nic "Swervin' Irvin'" Prins, Bob Pearson, David Richards, Mal Ross, Dave S aka "SNQQPY.DOG", Oliver Saussez aka "Filou", John Verheijen, "wire", Philip "Woody" Woodward, Adalberto Zapparoli and those people I possibly forgot to list (sorry in advance!)
After selecting the track in the sim, gpX freezes and the track does not load.
This may have several reasons. The most popular ones in GP2 were (chances are good its the same for GP3):
1 - track too long. be sure to keep the cumulative
length of track+pit lane below about 1597 track length units. For GP3 its 1648 units,
and GP3.exe falls back to windows desktop when the track is too long.
2 - too many curved cc-line + pit lane sectors. Here we have a limit of some 70 (precise figure will follow)
3 - (too many jams, too much jam size ?)
4 - GP3: if cc-line is scrambled "enough". If you converted a gp2 track by copying the track, pit lane and cc-line values, and it freezes at loading. you may want to check again the figures of the cc-lines. Keep your eyes on the "tighter/wider" values also !
5 -in track cmd "0xe9 texture mapping" there may be an value =0 in a9 (argument 9) (thanks dennis!)
6 - if cmd 0x87 (Connect Pit Lane End) is in pit lane instead of track
7 - track tree / track config section / cc-line sections / start X=0 (but it HAS to be >0) new
- more may follow ...
your current track in developement does not load in gp3.exe (fall back to windows)
note - big part of reasons for gp3 crashing to windows desktop are now identified and logged gpXpatch of SDI (get it from http://www.xs4all.nl/~rsdi/ and be sure to have checked "log assertions" on the screen of gpXpatch.
1 - be sure to consider theses figures for a slot specific lower track length limit (for gp3 1998)
1 mel 881, 2 int 857, 3 arg 685, 4 imo 987, 5 bar 885, 6 mco 669, 7 gil 864, 8
mag 790, 9 sil 1011, 10 a1 798- 800, 11 hoc 1234, 12 hun 741, 13 spa 1395, 14 mza
1129, 15 nur 923, 16 suz 948
its not really a length limit, but it acts like one.
note: this problem will be logged by gpXpatch as "bump table too long o.s.s."
for working around this limit you can work witth the so called "magic-data". lookout for a tool called cmagic and its documentation for more info. cmagic can be found on SDIs page @ http://www.xs4all.nl/~rsdi/
2 - the upper track length limit is1648 units, and GP3.exe falls back to windows desktop if the track is too long. (GP2 freezes).
3 - i also could resolve this problems once by "removing all roadsigns", though i dont know yet what was the specific problem. maybe more than one roadsign at the same place ? more probable: some problem with "bridged fences" (definitely "bridged fences" problem! see gpXpatch assertions log) ... updated
4 - happened to me when i had two track cmds 0xee at the very same place ...
5 - "speed limiter on"-cmd 0x96 in same pit lane sector as "pit lane fences begin"-cmd 0x9f ...
6 - if you have a swivelarm without scenery-definition, which means if you have a track cmd 0xc0, 0xc1 or 0xaf without a cmd 0xee following. this may happen in particular after using the "remove scenery"-function in the TE, which seems to miss to remove cmds 0xc0 and 0xc1. (thanks dennis grebe!)
7 - (yet to confirm) having softwarejams in the place of hardwarejams. if you accidently copy your softwarejams into the hardwarejams directory.
8 - having trackcmds 0xe1 and 0xe2 (fence extension on / off) at the very same position (DFS). to determine whether two such cmds are at the same look at the DFS (distance from start) of the tracksector where the cmd is inserted PLUS the argument "offset into sector" of that cmd.
but it does not crash if you have "on" without "off" or vice versa.
9 - if in cmd 0x9e (Pit Lane End Length) arg1 of greater than rest of pit lane length. (thanks dennis grebe!)
10 - pit lane cmds 0x88 OR 0x89 has to be there. beware: they could go lost in gp2 to gp3 convertion. (thanks john verheijen!)
11 - "untextured kerb colors" in track config sections. if you changed them, you may want to change them back for a try. in pauls TE the implementation of these parameters is not complete, so you may want to better not touch them without explicite testing afterwards. in vaino iso-hannulas TE its more complete. (but i wonder whether its worth to bother the untextured colors anyway)
12 - if in cmd 0xbd (Light Source Position) arg3 (angle above horizon) equals 0. (thanks dennis grebe!)
13 - (crash after starting lights) if you have a custom texture ID beyond 1792 (thanks david schneider!)
14 - mess with pit lane entry and exit checkboxes. see pit lane guide for instructions.
15 - the total length of the jips can't be over 1000 (thanks hernán! will be reported by gpXpatch assertions log also?!).
16 - in one case i had to throw away all pit lane scenery. pit lane scenery is basically possible, but i couldnt find the specific reason for the crash in time.
17 - if an object-setup points to an inexistant object-shape-id (gp3 crashes at the very end of trackloading, right before the cockpit would show up) new
- more may follow ...
After selecting the track in the sim, You get a message box saying "Wrong File Type" and the track does not load.
This occurs if the trackfile is too big. For GP2 the limit is exactly 62000 bytes,
one more and bang !
In GP3 its 140000 and in gp3-2000 it's 200000. (thanks SDI!)
The track works properly in practice mode but crashes when you want to make a race.
The track probably includes too much jam-size. In races there gets an additional jam called crowd4.jam loaded and this may be too much then. So you had to remove some (unused) jams of yours.
When loading the track or while driving it gpX crashes and you get faced to a message saying "Divide by Zero".
As the ancient romans were used to say "nomen est omen", the message already is half the ticket to the solution: We had a division by zero. This means we somewhere have a value=0 in an arg, where a value different from 0 is expected. And then, as the mathematiciens among us know well, dividing by 0 is not defined in our world, so poor PCs do not know better than to crash.
Now where are we expected to give non-zero values in every case and we didnt ?
The most popular are:
- texture mapping cmd 0xbc, texture length (here you get the crash, as soon as
the texture gets mapped. this maybe at the beginning or also halfway around the track
- kerps defining cmd 0xca/cb (here you get the crash as soon as you touch the kerb)
- in general: 0 dimension values may cause a problem; ids and offsets probably not.
- more may follow ...
at a certain point of driving the track gpX.exe crashes and shows the message above allover the screen.
i came along this once so far. there i identified an imported object as the source of the trouble. as it was the very last object in the list, i simply could remove it again. for safe removing of objects, do clear all links in obj-setups before.
When you see it, you will recognise it. Its a floating line starting somewhere around the border of the image leading into the "helmet of the driver".
(image temporary removed)
When driving it may "rotating" around in the image.
In GP2 this may happen if you do switch on/off ribbons at places different from swivel arms. More specific: Do ONLY insert cmds 0xb0, 0xb9 and 0xd9 at the same position (tracksector AND offset) as a 0xaf/0xb8, 0xc0/0xb8 or 0xc1/0xb8 pairs. (see original tracks for reference). NEVER have it alone. For GP3 it may be the same but there the functionality is inserted with different cmds. See cmdlib.
On some parts of the track you notice a (grey) line that is also moving when you drive on it. Similar as above but this time the line stays no the tarmac.
1 - Once the problem was a command Ox8a near the end of the track, that specifies some track markings. In the cmd 0x8a you have to give an argument a2 to set up the marking type. Regular values are 3 (yellow line), 8 (grey line) and some more. If this arg is set to 0 (ghost line) it causes unwanted dark grey "floating" "lines" every here and there on the track.
2 - In another case in gp3 unadequate values of the "pit lane end length"-cmd 0x9e turned out to be the cause. It looked like this:
(image temporary removed)
and could be observed on the track and when leaving the pits. The remaining length of the pit lane was some 5 and a1 of cmd 0x9e was set to 10 (it should have been set to 3 at max in this case).
In the near after the pit lane end you notice a strange piece "pit lane" (tarmac with yellow borderlines) "floating" on the track until the first corner.
This may occurs if the cmd 0x9e in the pit lane is set to long. In one of the last pit lane sectors you have a cmd 0x9e which lets you set up the viewable rest of the pit lane. This value HAS to be at least 2 SMALLER than the length of the actual rest of the pit lane. If it is equal or longer, the system hangs or shows this strange “moving line” or other nasty things happen i do not want to remember anymore ...
Driving around the track You notice strange kind of "tunnels" in corners mostly, "folded" from the outside of the corner.
(bad example(image temporary removed)
Those "tunnels" happen if the scenery structure is not yet satisfactory. There are swivel arms missing. Basically scenery ribbons are spreaded in a direct way from one swivel arm to the next. There exist cmds to let the ribbons go along the track, but thats only the 2nd solution. At first You may want to insert more swivel arms.
In the following raw sketch you may see the basic idea.
(image temporary removed)
When driving along a fence, You notice the texture on the fence is kind of warping as You drive.
This may have several reasons.
The most common is inapropriate rotation values in the texture mapping cmd. To avoid distortions try the following values: 3 (0 degrees), 19 (90 degrees), 35 (...), 51, 67, etc.).
The problem also could be in the general alignement of the scenery. Here You could try to fix with cmds 0xd0 stabilize scenery. Maybe also 0xc2, 0xc3 and 0xc7. See cmdlib for the details. Do insert them at the section where the flashing occurs.
On a certain part of the track driving seems to freeze for a moment (few seconds) and scenery bleeds into half of your view. See following example.
(image temporary removed)
This may happen if view distances are set up to far. I came along this problem on a very short track with very big view distances. Setting them to short distances or removing them also removed the bug.
When driving along,, You notice parts of the scenery ahead is flashing from time to time.
The general alignement of the scenery causes problems for the gfx-engines when deciding what to paint and what not to paint. You could try to support the engine with cmds 0xd0 stabilize scenery. Maybe also 0xc2, 0xc3 and 0xc7. See cmdlib for the details. Do insert them at the section where the flashing occurs.
The starting light is "frozen" or does not work properly. e.g switches to red but never switches to green.
GP2 needs to know "the offset" to the starting light object. This means you have to insert this offset in the track config section. How this offset is figured out and all the other details can be found in a workshop on this subject in the workshop section of these pages.
approaching the pit entry, the latter is empty, not visible.
(image temporary removed)
(the same may happen at the exit also.)
1 - watch out in the cmd-lib for the cmds 0xd3 and 0xd5, they BOTH have to be at the appropriate positions ON THE TRACK (not in the pit lane).
2 - if those two cmds ARE in position and the pit lane is still not visible, watch out for cmds 0xd7 and 0xd8 and remove them. do only insert them if you need them.
driving on the track you all of a sudden drive "in emptyness". this happens near the pit lane entry and lasts for some 10-50 track length units.
1 - watch out for a cmd 0x9c. john verheijen figured some connection between the argument of this cmd and the occurence of the described problem. you may want to look in original tracks for other values for 0x9c. In case you find out more about what is cmd 0x9c for, please notify the author.
testdriving the track under developement, all of a sudden you notice white mice allover the place (on the track), quiting driving does not help.
you probably worked too long with your track and need some sleep (>10 hours). maybe also changing the coffee brand to a lighter type may help (though for a short while only). never switch to booze or worse now, else bad headache may show up next to the mice soon.
if you perform a track sanity check in paul hoads TE you get a message "venetian blind corruption" and now you wonder whats wrong with the track and how to fix it.
some time ago, david richards gave the name to a phenomena that could be observed in grandprix2: "I have a strange distortion on the latest track - thin stripes across the screen like venetian blinds". once you had them you only could get rid of them by quiting gp2 and launching it again.
the source for the thin stripes across the screen was: the pit-exit and/or -entry was too close to the s/f line. pit-entry and pit-exit have to have a certain minimum distance from the start-end of the track. this minimum distance is about 5-10 length units and depends on the slot where the track is plugged in. with pit-entry and -exit i mean the position where the “two worlds” were connected by the cmd-triples (0xa1, 0xa2, 0x9f) resp. (0xa3, 0xa4, 0xa0)
in grandprix3 i never came along those thin stripes so far, so i guess there is no more venetian blind corruption. but the TE still reports if the pit lane entry or exit is "too close" to the start-end of the track. in grandprix3 this may cause emptyness in the very last part of the track.
to fix it you could try to "shift away" the pit entry/exit. as the very limit seems to depend on the slot, it may depend on some piece of the magic-data also, but this is just a guess.
gfx-bug: pit lane armco bleeding into track
0xd6 View All Pit Lane From Exit, 1 arg
f1ct12 only? only once
a1: Offset Into Sector; typical values:15
This cmd works similar to cmd 0xd5, but with unlimited view distance. As soon as you pass this cmd, all pit lane is visible. f1ct12 (Monza) is the only original track where you see from the exit "through" the pitlane to the entry. Thats why this cmd is used but there. If you use this cmd at the exit, you also have to use cmd 0xd4 at the entrance, et vice versa.
You may experience gfx-trouble (e.g. pit lane armco bleeding in regular track) if you use these cmds in pit lanes that are not all-straight.
black horizon / subhorizon
(image temporary removed)
0-Derek (email@example.com) said the following:
I'm having trouble with the horizons on a track I'm working on. The problem is that in sections there
is a blank space halfway between the ribbons and the horizon texture, I've checked that all ribbons
have textures attatched to them, and also that the distance to horizon is 16384, I've run out of ideas,
any help appreciated.
PLK (firstname.lastname@example.org) said the following:
The problem you are having is a long-recognised one. The Monaco22.jam file supplies the texture that
fits in between the landscape and the horizon. It's texture ID is 116. Make sure you have this jam in
the track, or a replacement ID 116 jam, and your space should disappear.
Derek from 18.104.22.168:
Jam inserted, problem solved. Thank you.
when replaying the in tv cam view, the image freezes for a while when you pass the s/f-line
most probably there are cameras with invalid position (dfs) and or "next camera" switches. both have to be in range of the track length.
object bleeding through armco (fiorano bridge)
(image temporary removed)
(lower picture after shifting the bridge away from the position where the road sign sits)
car flying (camera position)
desert land before s/f line - pit entrance too close to s/f line
0-Jason hope (email@example.com) said the following:
I want to know why sometimes, a camera temporeraly freezes before going on to the next one. Could it be that they are too closely placed,or could it be something so simple that even a chimp named bozo could figure out?
Dave"SnQQpy.Dog" (firstname.lastname@example.org) from 22.214.171.124:
You can find the answer to your problem in a little known tutorial on the subject of cameras @
or you can download the whole thing @
Its actually because you set the value to high.. (sorry Martin)something to do with the view extending beyond the edge of the viewable world. I haven't ever been able to calculate the exact limit, Paul and I looked at this a while ago and couldn't find an exact formula!
Anyway I suspect your value for the offending camera view ahead or behind is probably over 200 try reducing this value to 200 or less at this location, that should do it.
Incidentally a zero value I believe defaults to a setting of 64. Paul & my calculations appear to support this! :o)
Hope this helps
0-Fat Rat (email@example.com) from 126.96.36.199:
Looks like the largest firuge I have on my HD is the MP Monaco at 830464
Mp Spa at 816896
My newest at 816640
Mp Monza at 803072
MP Imola at 801536
Van Indy at 808960
Laguna Sunset at 790864
Ultima Around 75000
Addie's Berm in the 700000
0-Robert (firstname.lastname@example.org) from 188.8.131.52:
it seems that my track works perfectly... in the practice option.
everytime i want a qiuckrace or a non-championship race the game crashes while loading the track.
but NOT with the practice option
what is this???
µartijn from 184.108.40.206:
I think you used a JAMfile too many. Try not-loading one (unimportant) JAMfile and see if it works then.
If not, please come back here. If it works, please report also :-)
Robert from 220.127.116.11:
i did just as you said and it works perfectly
Cars (lotus.jam, jordan.jam, etc.) 531-544
pc-extra1.jam 669, 670, 676, 679
pc-extra2.jam 681, 682, 677, 668, 403
mpush.jam 411-415, 404
pitprop1.jam 431, 671
pitprop2.jam 426, 427
pcjack.jam 674, 675, 680, 683, 684
rcr2b.jam (same as rcr2)
flagcheq.jam #386, 389, 394, 397
flags1.jam #395, 396, 398-401
chequ1.jam #387, 388, 390-393
Posted by Bob Culver from 18.104.22.168:
I also discovered that if the sections specified in the Oxc5 and Oxc6 commands overlap, when you are in the overlap section, nothing shows up, not even objects! What I am referring to is in the Oxc6 commandd, the values define the distance that the Oxc5 is inacted. The Oxc5 defines the distance from the S/F line. So, if those two sections overlap, that is where everything shuts off. For people using tracks with oxc5 and Oxc6 commands such as Imola and Spa, if you leave these commands in, it could cause these sort of problems if you are substantially revising the track. I also experimented with multiple Oxc5/Oxc6 combinations. What happens is the last command is the one recognised.
Posted by Dan C from 22.214.171.124:
For multiple arguments, you mean:
0xC5, 0xC5, 0xC5, 0xC6 in order. I found that the last one works too, but only for objects, I think. So, an object would not show up unless it was in the last C5. In Monza, trying to fix the view of the S/F straight, I have to split it into 2 commands, since there is a problem of using 1 command to go past the start and end of the track. Since the pit building is defined in the last sector of track and corresponds to the first C5, the building does not show up.
For the overlap, you mean when C6 value lies within the values for a2: and a3: of 0xC5?
Posted by Bob Culver from 126.96.36.199:
Yes. Since the A2 of the Oxc6 command determines the distance from the point of the command that the Oxc5 section defined is visible; if the area defined by the Oxc5 is within that distance, then that is the point where everything shuts off. Since the Oxc5 defines the section as distance from the S/F line, it is not so obvious until you actually drive.
Bob Culver (email@example.com) from 188.8.131.52:
I believe that the slot that you actually load the track into makes a difference on what the overall
length limit is. There are also probably other variables that have not yet been uncovered. I am
working on a track that is 7.31 km + pit lane of .48 = total length of 7.7931. It runs ok in some
slots, but crashes 1/2 way through the game in other slots. Also, I have found that if I make a track
that is just 1 track section shorter than a track that does not load, that an invisible wall is
encountered when exiting pit road. Similar to the "great wall" effect that you get when your heights
are way off. Very starnge, but it is definately caused by the track length. So, a track of 7.83 might
be possible, but if you load the track in a different slot, it might not work...or, try loading it up
with objects, or other memory eaters, and other side effects are likely.
0-Jeff Renaud (firstname.lastname@example.org) said the following:
My track is ready and everything is fine, but how can I delete the walls that are in the pitlane's way?
Thanx to take some time to answer me
addie (email@example.com) from 184.108.40.206:
are the approproate checkboxes “remove texture” checked in the appropriate tracksectors ?
(see pit lane tutorial for the details)
i hope it helps