Forum Postings 1998 December

as collected and (very little) formatted by addie walti


The start of a thread is marked with 0-

Jam Creation
Track grip commands
Starting a cc-line at an angle
divide by 0 (PLEASE)
Also, my new PC...Not so lucky :-((

Help with Starting Lights
Close encounter with the 3rd kind...=)
Problem with scenery intruding into pitlane
track command limit - track loading
cmd 0xc5/0xc6 - all i have

revealed Unk command that switches
scenery quake - 0xaf(175) 0xc0(192) 0xc1(193)
split time commands?

Please help (gravel trap problem)


Jam Creation

Bob P from

Hi all,

I am wondering if there is a limit on the number of jam id's within one jamfile? I have been working on some (and trying to condense several into one) but now the track in question crashes. The jam I suspect is causing the problem has 24 jam ids in it. Is this likely the cause of the crash? (The track was fine until this jam was added).

BTW, I must say that the jambuild seems to work quite well now I have tried it!

Bob P

Track grip commands

0-David Hosking said the following:

Could someone tell me how to go about changing the track grip for wet races etc. I know there was some discussion a while back about this,
but I can't remember what was said.

babbel said the following:

insert 0xdd in ts0 and after that 0xd2 a1 = 0 and a2 = track grip level . to get it to work you have to insert 0xdd FIRST and then 0xd2 otherwise
it won't work


Martijn from

furthermore: a gripvalue of 16384 is "normal", 11000 is already almost undrivable slippery, and 23000 makes sure your car goes through every
corner on two wheels because of the grip (you spin anyway... :-)



Starting a cc-line at an angle

0-Mal Ross from

Until it appears on the CCLP pages (, I'll post this info on the forum...

It seems that CC StartX, Unknown3 and Unknown4 define a 'hidden' cc-section that comes before cc-section 0. StartX defines the length of the cc-section, Unknown3 defines the 'sign/scale', and Unknown4 defines the radius. The StartY still affects where this 'hidden' cc-section starts in relation to the centre of the track, of course. Cc-section 0 then begins at the end of the 'hidden' cc-section and at the final angle of that section.

BTW, the 'hidden' cc-section doesn't actually affect the way the computer cars drive - it is purely for defining the starting point and starting angle of the first proper cc-section.

Note, I don't want to take the credit for this - all I've done is confirm Ponk's (and Paul's?) hypothesis, which is already on the CCLP pages.



Bob P from

I noticed that myself, some time ago (I thought I made a post to that effect?... oh well it was months ago now) and I was trying to make a track out of Monaco.
There is a good case to notice this effect.

I never thought of it as a hidden section--but that makes plenty of sense--I just figured it was a start angle for the first CC segment.

Bob P

addie from

what i found so far is that setting the starting angle by the help of unk3 and unk4 only works in a predictable way if startX is set to 1 and startX/high) to the default 208 ?!

setting startX to 0 hangs gp2.exe when loading the track. values greater than 1 seems to have not much of effect anymore ?!


Mal Ross from

Remember that the 'hidden' section is still behaving like a normal cc-section, so a length of 0 (from StartX) *will* make GP2 crash.

As for larger values not having much effect, I've not observed that before. The track on which I tested my theory had a StartX value of 5 and was behaved entirely predicatably. Maybe your values were causing some value to wrap around?



divide by 0 (PLEASE)

0-Jason hope from

Guys I'm having a little trouble with my track. I go around halfway, and GP2 exits and this message appears. All I did to my track was replace a jam file.
Jason hope

Dave"SnQQpy.Dog" said the following:

Hello Jason,
You say you get to a particular section on the track where GP2 crashes.
Check the t# sections around this area and look in particular for kerbs and other cmds with ZERO values in them, I'm not referring to the 1st argument, replace the zero's that you find!
Hope this helps :o)

Paul Hoad from

I'm sure its not this but check it still fits in the world!
Also you could put the track on a web page where we can see it and one of us will have a look at it for you!
Paul Hoad

John K from

I too have a similar problem that just started last night. Not a Divide by 0, it just crashes out to Win95 when loading the track. Yesterday I deleted an internal object, and after that my problems started happening.

Sucks too, because I've been getting lazy on my backups lately. A lot of work to do again.

jason hope from


well, as it turned out, I had two identical jam files that had different names. This could have been the problem, as the track was confused as to which jam file to use. Paul, can't you insert something into the TE that automatically checks and warns you right away if you have a problem with conflicting jams?
Just a suggestion!

Thanks guys
Jason hope

Paul Hoad from

Deleting internal objects.... I rather work for the UN clearing land mines....

The internal objects have offsets into memory locations its really difficult to be sure that theses are not supposed to be sequential in memory. I found by trial and error that deleting all but the last object can be fatal, not always though, I also found that replacing an object with a larger object can have the same effect.

Paul Hoad

John K from

Thanks Paul.

Seems like everyday I learn something new. Today's morals of the story are 1) make more backups!, and 2) don't delete internal objects!

Life's a learning process. =) Back to work.


Also, my new PC...Not so lucky :-(((

0-Jocelyn said the following:

Hi Guys!
(a little bit off-topic, but it's worth a try...)
Like Malcolm, I just got a new pc :-)
Trouble is, the damn thing won't allow me to play in SVGA, the choice is greyed out & unavailable...
It's a p2-350 w/ 8m 3d AGP onboard (made by SIS), 128 ram (+ Voodoo2) ...
Also have a problem with GPL (demo for now): part of the track & scenery is black, totally black, except for some hay bales, or an occasional track sector...
Anyone has a fix or at least an idea on the problem?
Someone mentionned something about VESA not fully supported by AGP chips...
Could that be it? If so, how do I fix it?
Thanks in advance,
I can't wait for GP2 full details AND a decent fps!

MiXer from

SiS chips are NOT compatible with GP2...
As for your GPL problem goto and download the latest drivers.


Help with Starting Lights

0-Dan said the following:

I am having a problem with the staring lights not working.
I imported a different light object from another track, and now they do not change to start the race.
Does anyone have any suggestions ?


Malcolm Mitchell from

Put your original ones back on, and then re-export the dodgy one, and then hope it works :-)
You may have a corrupt file though :-(

Malcolm Mitchell

Bob Culver from

The starting light sequence involves jams 15, 16, & 17 in roadsgn.jam. Jam 15 is the illuminated red light, Jam 17 is a non illuminated light (that eiter covers the red or green) and jam # 16 is the illuminated green light. Some of the modified starting lights have tried to emulate the current FIA starting technique of having all red lights switch off to start the race. In this case, jam #16 is done as a "non illuminated" light. Check your custom jam to make sure that it is configured correctly.


Close encounter with the 3rd kind...=)

0-John K said the following:

Yes, that's right, UFB's do exist... unless someone can disprove it.
What's a UFB, you ask? An Unidentified Flying Bush. It's a unique and amusing little problem I've encountered whilst in the final stages of doing scenery and object touchups.

About halfway around my track, hovering above an edited, imported object, lurks an ominous sign that we are not alone in the GP2 universe. Indeed there is intelligent (plant) life out there. But all I really want to know is, did this bush come to conquer my circuit or what?

Where the hell did it really come from? Has anyone else had past encounters with UFBs or the like?
I swear I have no bush object placed anywhere in my track. And I'm not going insane. I was tested just the other day.
(And this isn't any light reflection in the window)

Robin said the following:

Hey, I also had an UFB visit my track, and I could not figure out where the bloody hell it came from or (even more important) how to remove it. As you can see UFB are very intelligent, coz the command can't been seen (sometimes) in the TE.
It's time they brought me to their leader, so I can confront him with this madness...
Beam me up Scotty!
Best (x-mas) wishes,

Martijn said the following:

Some objects INCLUDE a tree. Like the center of the TunnelTrack-castle (based on some Adelaide-building). You won't see this tree in the TE-object view , because the codes for it are still unknown (like in the "bunch of trees" objects). So experiment with it, find it out and report, please!


addie said the following:

i also had an UFB in the grauholz track when i was playing with the cmd 0xc5. my questions:
-shows the UFB up somewhere the track is near another part of the track (or even crossing?) ?
-are there cmd 0xc5 and 0xc6 included in the track ?

if both answers are yes, you could give it a try and remove the mentioned cmds (but make a save backup of your track first :)

chances are low, but maybe it helps ...

John K from


I was not aware that the Tunnel Track had a castle in it, but mine also has a castle, *and* I used an Adelaide building. And it is this building to which the UFB is "attacking".

However, what's interesting is that the bush changed height without me doing anything to the object. Previously, it was at the base of the castle object which was at a height of about 2500. But now it's ascended to about 10000-12000 or so without any known or logical cause.

If I can't somehow lower it back down, or eliminate it, then I'll have to get creative and just slap a flying saucer texture and leave it there for my own amusement. ;)


Problem with scenery intruding into pitlane

0-Mal Ross from

Hi there,
I've got a problem in one of my tracks that I've not been able to resolve. When viewed from external cameras, it can be seen that scenery is overlapping my pitlane. However, I've got all scenery in that area turned off. As an extra measure, it's all reduced to a height of zero in the 0xb8 commands. Even Martijn couldn't figure out what was going on. Can anyone help?

The track is Alderley and is available from (it's only about 17kb).


Bob Culver from

Try placing the camera in the tracksection with the view into pitlane command


track command limit - track loading

greg GC said the following:

Does anyone know if there is a limit to the number of total commands and track sections you can put into a track ?

I am having a problem adding scenery commands and objects. The track is a bit over 7 km, and is now 170 sections.

The cc-line is done and about 80% of scenery & objects and the track works fine. But when I add any more scenery textures and commands/objects, the game does not recognize the track file.
To get around this, I have merge some track sections to reduce the number of total sections. Also deleting some objects allows me to add more commands.

I am assuming there is some upper limit to the amount of info allowed for a track. Has anyone else run into this problem before?

Or is there a way of allowing more commands ?


John K said the following:

Well, at 170 sections you still have about 90 or more to go before you run into problems (if indeed there is a limit). But as Addie mentions in his TE summary of his Bern-Grauholz track, the assumed limit is beyond 256.

As for the commands, the other guys around here will have to answer that. However, I recently experienced trouble on my track when adding more and more scenery commands. The T0 scenery zeroed itself in the game, but it all still loaded. I did not pursue this problem further, because it was very late at night.

You state that your track length is a bit more than 7 km? Is that purely the track, or the track+pits? If you track+pits length gets up into the 7.8 km range, you begin running into problems.

Greg GC from

The total length is about 7.2 track + pits.
But I don't think length is the problem.
Originally I had 210 sections and that seemed fine at first.
I'm down to 160 now.
So it may be the number of commands.


addie from

the bern-grauholz track includes (among other things) 272 track sectors (maybe thats why TE 1.7.4 crashes when trying to load? however works fine).

the limit for the number of scenery-cmds (0xb8) seems to be 128. in the bremgarten track i experienced, when inserting one more 0xb8, the last one before s/f disappeared in the game, but the track still loaded and ran.

martijn keizer once mentioned there is also a limit for the number of cmd 0xbc (texture mapper) and there is a limit of number of object definitions or objects.

i guess most of these limits work independant from each other.

last but not least you may want to check other TE versions first whether they eventually do load the track.

maybe it helps

if you find an answer, please post it in the forum!

Bob Culver said the following:

My latest track will also be testing the bounds of command limitations. Sor far I have 209 track sections with lots of scenery and texture commands. By the way Addie, I love your new track, and that is remarkable how the Oxc5 command works. Are you going to explain soon?

Dave"SnQQpy.Dog" from

I think you will find that the problem is associated with the number of cmds!

That is all cmds, this includes pit+track.

The way to test this on your own individual tracks is;
get to a point where the track loads OK - this will be easy because you will have numerous version saves (wont you?)
then at the point where the track stops with a reference like 'unkown file type'
remove any uneeded cmd 0xd0 for instance! Having done this then try inserting the cmd that produced the problem in the first place! voila! (we hope) :o)

Now check the track stats in TED and look at the cmd used number, this will now be the limit for your particular track.

If the next question is what should this be, the answer is it varies from track to track but I believe it to be related to overall file size, that is at run time!

Hope this helps :o)



cmd 0xc5/0xc6 - all i have

0-by addie from

i havent yet posted a detailed explanation of the 0xc5 (and 0xc6) cmd simply because i dont have it :)

anyway, the basics are (explained on the Bern-Grauholz-Track; for orientation, see track map included in the package):

You need a pair of 0xc6 and 0xc5. they are inserted in the same track sector. In the Bern-Grauholz-Track they are in t20 in the last part of the Paul Hoad Bend.

-with cmd 0xc6 you define a "far sight area". its arguments are:
a1: offset into sector (as usual)
a2: length of this area in the grauholz track the track section when exiting Paul Hoad Bend - passing Gate Berntor - entering GAZ!-corner is defined as far sight area.

-with 0xc5 you define the "far sight". You define the section of the track that should be visible as long as you are within the "far sight area" defined by 0xc6.
Now comes the part i dont understand completely yet, the arguments. The reason is, there seem to be several versions of the cmd 0xc5 around (no kidding). They seem to have different meanings of some of the arguments and even different number of arguments. The switch for the number of arguments is to be found in the track config section, where you also find the pit-side-switch.
Now i just can explain the arguments as used in the Bern-Grauholz-Track (may differ in tracks with bases other than f1ct08.dat; and may differ from possibly other applications of 0xc5).
a1: the offset into sector (again).
a2 and a3: define the track section to be visible. you give the beginning and the ending of the range. You give the distance to s/f for both arguments. In the Bern-Grauholz-Track the section where you are ON the Gate Berntor is defined as “far sight”-section.
a4: kind of location code (probably B). It defines which parts of the “far away” track-section should be drawn.

Thats how its done in the Bern-Grauholz track. But if you look at some original tracks, my explanations dont make sense anymore. Thats why i guess there are several “versions” of the 0xc5 around.
If you want to include a “crossing” like its done in Bern-Grauholz you have to carefully choose the base. My explanations so far seem to work for f1ct08 and f1ct03. For making your choice you may want to have a look at the 0xc5 cmds included in your candidats. If they look “similar” to those in f1ct08 and f1ct03 they may work in a similar way.

Some further remarks:

please note the difference between track section and track-sector (see glossary of cmd-lib).

The “far sight” shows up only in cockpit view forward. Mirrors and tv-cams seems to not work. At least i the Bern-Grauholz-Track. Maybe some of the other “versions” of the cmd 0xc5 cover these also.

The “Arrangement” of the“far sight” is pretty tricky sometimes, because the view is covered by everything but the sky and the background of the track section where you actually are with your car.

And beware: you have to expect bad crashes of game and TE sometimes when trying to remove or insert cmd 0xc5 cmds (i did simply copy/paste of the cmd in my track). So be sure to have a backup of your track in save place before entering the jungle.

If you find some further explanations, please let me know.

And the included hotlap is still to beat :)

(once more thanks to babbel for turning my interest to 0xc5!)

by Fat Rat from

Dr Addie Livingston I presume

Stepping out of jungle gloom.
I though I'd paired one of these prior . Around the same time the show pits through cmds were coming out .

I had no idea what it was .But I thought I'd mentioned & posted in reply to S Dog . that 198 had a brother , Same time I mentioned the 206 cmd .

I'd also like to remind MK , re his remaks about no other unk's effecting any views etc,Posts to this effect ca cause delays or set backs in development & exploration

Addie , any ideas on wheither or not this might over ride or effect any part of the dreaded 90 degree viewing switch ??

As you know I wrestled with the veiws on the Andretti hairpin on Laguna Seca . Actually I did manage veiws of both sides of the switch back . Plus a veiw back into the pitlane & buildings . But it was not useable because it would pop up all of a sudden , or you would have to spin or drive section backwards for it work right

This problem was more directly related to rear or past veiw rather than an approaching sections. Could these CMD's work backwards as well as forewards ???

I will do some R&D , but NO TIME till new years .
But I will be sending out some xmas mail.

Merry Xmas All

addie from

hello les (and all)

my idea of cmd 0xc6 (198) is, its an “enabler” for other cmds. it “opens a window”. dont ask me why this “window” isnt open all the time (probably because of cpu-load).

for the 90 degree switch. i didnt make any experiments here. i just looked at spa once, la source, where you have a delicate problem with hairpin AND pits. its done there (as good as it gets, i guess).

but i have to have another look with the latest recoveries in scenery-questions (to be published in a few minutes) in mind.

as for the view question. cmd 0xc5 (197) seems to be a multi-talent. at least if you look at its arguments and applications which seem to meet my former describtions only partly from time to time. so maybe it actually could solve problems like you described ?!


John K from

I believe the answer to the 90-deg switch is YES, it will work. We experimented in my track with a section like you described, and I got it to work (8-arg 0xc5, for Spa). The trouble was that the location code/detail code of a4 (I believe). The banks didn't show up, but the rest did.

This was all tried after toying with Viewing Distances to no avail.



0-Jason hope from

I've just been re doing ALL the scenery for Montreal, and in some places there are flashes accross the screen. What can be done?

Second. How do I stop the type of folding effect that occurs when I go from a flat scenery directly to a tree type scenery. quite ugly you think. I tried turning off the ribbons, but I really did not see any chenge.

Third. When I put multiple sceney commands in a track section, does the order have to be from furthest to closest to the beginning of the track section, or vice versa?

I would appriciate this quite a bit.
Jason hope


revealed Unk command that switches

0-Dan from

It seems that there may be a Unk command that switches the ribbons around.
Or rearranges/rotates them. I was adding some scenery to a track and I was wondering why ribbon 3 was acting like ribbon 4, and same for the other side.

I then began removing all of the Unk command before the section and the scenery behaved normally. The problem is that I cannot pinpoint which one, since I removed so many Unk commands.

Does anyone know if this command has been found yet?
The best I can do is list the ones I removed and hopefully, someone can work it out.

Then again, why would anyone use this command ? Look in the Suzuka file.

addie said the following:

can you say which track-sector(s) it was in the suzuka track ?

Dan said the following:

It will take a day to figure it out, since at the time, I had added many sections to the Suzuka track all over the place, and it no longer looks like anything close to Suzuka.

I have to look into my backup files. I'll get back soon.
It could also be that it may be a combination of Unk commands.


Dan said the following:

I figured that I also had deleted some scenery commands too.
So I was actually wrong when I assumed that an Unk command was doing it.

It turns out that it is the Oxba command.
This is the Bridge Scenery command with an unknown argument. For some reason, when deleting all the Oxba commands before the area, it fixed the problem.

I read that Oxba can shortcut the ribbons on some sectors, but for some reason, it had flipped and distorted th ribbon textures completely.

The order and the values of the commands are in Suzuka track. I don't know why the command does this.


scenery quake - 0xaf(175) 0xc0(192) 0xc1(193)


0-addie from

cmd 0xaf (175), 0xc0 (192), 0xc1 (193)
(always paired up with cmd 0xb8(184))

i guess we have to revise our understanding of the arguments of the mentioned cmds. the first argument is still the offset into the sector, but the other arguments seem to be an ANGLE instead of a scaling-value.

imagine the scenery ribbons being attached to swivel arms aside the track. these swivel arms seem to be fixed on the intersection of the “center-line” of the track and the position given by the offset-argument. we have a swivel arm to the left and a swivel arm to the right. the arms probably swivel on a horizontal plane parallel to the “gp2-world” (and not the plane of the track).

the form (position of fixation-points for scenery-ribbons) of the swivelarms are defined by cmd 0xb8
(184). the scenery-ribbons then are spreaded within the four appropriate fixation-points of two neighboring swivel-arms.

the arguments now define the angle of the arm to the track. the range of the value is 0..65535, 360 degrees.

0: track direction
16384: perpendular to the right
32768: against track direction
49152 (or -16384): perpendular to the left

0xaf(175) includes two swivelarms, one for the left side, one for the right side. theoreticaly you could use both on the same side. practically this will not work, because of the bank-ribbon which remains attached to “its” swivel arm. you may want to use one arm for the left and one for the right side, as is done in general up to now. in the same sense you may want to use the 0xc0(192)-arm for the left, and the 0xc1(193)-arm for the right side.

if you would like some images illustrating this, dont hesitate to drop me a line...

(here is the "letter")


thanks for the interest. please find the images attached.

afshots.jpg shows some screenshots of the very same clipping of a track with three pairs 0xaf(175)/0xb8(184) (three swivel-arms) as you will recognize easily. the car sits perpendular to the track, looking to the right side of the track. the middle arm is swiveled. top image: value 16384 perpendular; middle image value 20384 arm swiveled back (against track direction); bottom image: value 12384 arm swiveled forward (in track direction). the turning-centre of the arm is somewhere in the middle of the track in front of the car (a little bit to the left of the car).
. afshots.jpg:)

the second image, afsketch.jpg, includes a sketch where i try to illustrate my descriptions.

merry christmas to all

Mal Ross from

Whoooah! This a pretty major revelation. How did you come to find this out? I take it you've done some pretty thorough testing seeing as it's such a difference to the previous understanding of these commands? (Note: I don't doubt you! :)

Would you be able to put the images on the web somewhere, rather than emailing them to loads of people? If not, could you send them to me and I'll put them on my own web-site.

Cheers, Mal.

addie from

i always wondered about the sense in making a difference between a “span” (or scale) value of e.g. about 15000 and 16000, as can be seen in the original tracks. (btw: i’m sure everything in gp2 makes its sense. and i’m also sure most of the solutions for the remaining mysteries are closer, simpler than most of us expect)

i was dealing with a track in general, and 0xaf’s in particular, as it struck my like a lightening (every value like 16384 looks like a 90 degrees angle value to me at first). then i made a quick experiment, et voilà. (if you know what to look for its much easier to find.) the former interpretation of the arguments is not that wrong neither if you make a sketch of the swivel arm and look at it, so nobody is to blame at all.

Mal, thanks for the offer ! the images are on their way to you. i dont have no homepage, so far.

(now i’m pretty sure some of the remaining unks do manipulate the swivel arms in further ways. look at the original tracks ! and please let me know if you find something)

merry christmas



0-Laurent said the following:

In the track section 1, I always have the distance from the fences left and right side which remains to
zero. Only in the game is zero...Why ?

addie from

you have to go to the track-tree. track-config/track-sections.
here you find “Begin Left Bank” and Begin Right Bank”. thats what you probably are looking for.


split time commands?

0-yunisaz said the following:

Has any one discovered the commands for the intermediate splits?


David Hosking said the following:

There are no commands for this, the spilttimes are at 1/3 and 2/3 distance around the circuit and cannot be changed

addie from

david is right as far as i know. although its not exactly 1/3 and 2/3 all the time. there is still an unknown part here. so if you e.g. want to place split-time-lines on the track you have to do some trial and error yet for an exact placement.

babbel from

it wasn't 1/3 , 2/3 , it had something to do with track segments but I can't remember what :)


Please help (gravel trap problem)

0-Bart Vandevelde said the following:


I'm working on a personal track, but when I add a gravel trap to a track section and I go check it out in GP2, it's tarmac. Is there some sort of command to solve this problem?
(track is build on Monza)



addie from


basically a gravel trap is added by mapping a texture to the desired zone. this is done with the help of the cmd 0xbc (188). one of the arguments of this cmd is the jam-id (texture id), see the command-library (available from the tutorials section of the TE-homepage or directly from the author) for the details.

there is a certain id for the gravel trap (164, if i’m not completely wrong). a texture mapped on a verge with the id 164 ACTS like a gravel-trap whatever bitmap it includes. tarmac usually is id 33. any texture with the id 33 acts like tarmac if mapped on a verge.

so you could go to the appropriate track sector and look out for a cmd 0xbc(188) and check its arguments. probably you simply had to replace the id 33 by an id 164 ...

i hope it helps

Fat Rat from

Well Bart

Addie is certinly correct with his info on the 188 cmd .
But I too am currently doing a Monza based track and it too has a stretch of unexplained tarmac also .
But it is not located on a verge but rather a bank .
1st ribbon outside the fences , rightside just past the pit out . But I had no problems anywhere on the verges .

So if it is near the same place let me know .
Thanx Les