Forum Postings 1998 November

as collected and (very little) formatted by addie walti


The start of a thread is marked with 0-

"wrong file type" !?
Scenery 'movement'
importing objects
Just a thought on CMD 112
Scenery 'movement' (part 2)
Suggestion on the TE !
Detroit street circuit little bug help please!!:)
cc-line (cmd112+"t/w")
CC-Line (max number)
Underlay bitmap
Fuel supply
Help needed with JAM Editor
CC-Line Idea
unk hunters report (0xd4 and 0xd6 baged)


"wrong file type" !?

0-Ando from

Hi all,

I have a strange problem with my current track: when
loading the track in GP2, it says it is a 'wrong file
type'! An older version (only a few days older) still
works, and I can't remember having changed anything
else than the textures for some objects and some
slight changes to the shapes. I also changed the JAM
files, but this shouldn't cause the track not to load,
should it?

Did anyone experience similar problems? It would be
really cool if someone could help me. I will also look
into this again and will report my results.

many thanks!


SNQQPY.Dog from

Hi Ando

Have you been adding objects etc?? this usually occurs after you have been inserting too many cmds?

Try reducing the number (any not needed)that might help...hope so anyway ;o)

Robinio from

Sorry Ando, I'm finally replying to the correct message.

I've had this problem too sometimes, but I only had it when I changed something in the track with a Hex editor. Did you change anything with a Hex editor by any chance??
This is the only thing I can think of at the moment wich may be causing your problem.


Ando from

thanks for the reply, but unfotunately I didn't add any cmds! I have 617 trk cmds in both the working and the bad file. I
haven't added pit cmds either. :(

and I think 617 cmds shouldn't be the limit!? I already have removed all the cmds which aren't necessary at the very

anyway, thanks for your help.


Ando from

I didn't change anything with a hex-editor. I only used the TE and the JE! Not even the OE!

anyway, thanx for your reply.


Ando from


hi all,

I have fixed the problem. It was simply that I added one Internal Object. Seems like it was one too much. :)
I hope I can still add cmds though...


SNQQPY.Dog from

Hi Ando

Glad to hear you fixed it...objects eh? I wonder where I heard that one before?

Let us all know if the cmd number is still a problem and if so what it fails at?

Ando from

the number of cmds doesn't seem to be a problem yet. I have inserted several 0x80 cmds and the track works as usual. But when inserting another int. object the track doesn't load anymore. I currently have internal objects up to ID 71, #72 would crash the track.

now for Bob P and his TE bugfix summary:
My problem is that I still need many int. objects! So I tried the remove int. object function which shouldn't change the IDs o all the other int. objects, but it does! When removing say ID #30, it removes it and there are only ID #29 and then ID #31. 30 is gone and all the ones following it still have their old ID.
that's what it should be like. but when updating the view (F5), the int. object with ID #31 has ID #30 and all the ones following have another ID (-1), so I would have to change all the object descriptions.

It would be cool if it was possible to remove int. objects without having to change all the object descriptions. I hope I was clear enough, otherwise please tell me and I will try to explain it once again.


John Verheijen from

you can replace the Internal Objects.
So the other Internal Object still keep the original ID's.
Just click with the right mouse button on the Internal Object and choose Replace Internal Object.

Hope this solve your problems.
John Verheijen

Ando from

thanks for the tip! I never tried this function. :)

But as I just realized that the whole object part in my track has to be tidied up, I just removed all the int objects that aren't necessary. Now I want to remove the object descriptions that I don't need, but this doesn't seem to work. When right-clicking on one of them, I get the same window as if I clicked on a track cmd. I tried 'Remove Track Command', but the TE crashed everytime. :(

Is there a way to remove the object descriptions?
many thanks!


John Verheijen from

Why remove the Object Definitions???
just change the ID1 of the object definition.
just fill in the values you need and you have a new Object definition.
Or if you don't need another object definition try ctrl+x to delete the object.

John Verheijen

Scenery 'movement' (part 2)

0-Robinio said the following:

Hello folks,
It's me (again...)

Although I fiddled about with the scenery on that particular corner (thanks for the advice guys!), the scenery 'movement' never seemed to go away. It got better (most of it is gone), but it's not perfect yet.

Here's what I did up to now:
I inserted a 'scenery adjust left' command and another 0*b8 command. This didn't help a lot, untill I inserted a 'bridge scenery' command, with args of 4. With this command it cleared up a bit but the tree line is still moving a little bit up and down (or back and forth; I can't really tell).

Rite, does someone have a suggestion (again)?

Best wishes,

Sjon from

You moved the scenery back to 7000 not? Try moving it closer to the track, 2000 or so. I have no idea or it will help, I am just speculating here..

It could be 7000 is to high. Try building the scenery "on scale". for instance: instead of using the large tree line in t_monsp1.jam, t_monsp2.jam and t_monless.jam use the trees from t_monsp3.jam, this one contains a smaller tree line. With using a texture from t_monsp3.jam you can use a value like 2000 in your 0xb8 command and get the same effect as using a texture from t_monsp1.jam and 7000 in the 0xb8 command.

addie from

i dont know the z-values you used in the 0xb8 cmds. but maybe there are certain values that fit better to the game than others (e.g. 2048 instead of 2000; things like this). maybe you could check the original tracks and copy appropriate values from there ...

are there gradient changes in the mentioned section ? if yes, maybe breaking the existing track sections in smaller parts and inserting more 0xaf-0xb8 pairs could help ...

just my few cents

Paul Hoad from

It's just an idea I have no idea if it will work but how about using a height or distance form the track that is more of a computer number say


perhaps if there is division going on rounding errors might be making some problems, numbers that are divisable by 10 may not always be the best try a number that is divisible by 16

just an idea
Paul Hoad

Robinio said the following:

Regarding your message Sjon: I've had my scenery as close as 3000. But I'll try 2000 or even 1000. Hey, maybe I'll get lucky once! (I hope).

I'll also try Paul's advice: change the numbers so they're devidable by 16. (Thanks Paul).



Just a thought on CMD 112

0-Andrew D said the following:

I was wondering if anybody has tried to link it to the action the cars sometimes take underbraking for corners.
Keyboard players esspecially, if you notice when you are behind a cc car and you brake hard into a corner, how the car suddenly steps out and spins sometimes. I know that the cmd is after the corner, but could it be linked. I haen't had enough time to check this out, but if anyone has tried in the past, could you let me know

Ripping said the following:

Along the lines of what you are talking about, I noticed while I was running a Monaco race (original track) that in Rascasse (last corner) if you are very close behind a CC car going into this corner GP2 will put you on the outside of the CC car and inevitibly into the wall (Steering help on).
This seems a case of the CMD 112 affecting the human car and not the CC car.
I assume rascasse has a 112 cmd?

Andrew D said the following:

I checked that out, and it seems that the ony places at Monaco that have the 112 cmd are Ste Devote, Casino Sqr. Mirabeau and Portier. I could be wrong

addie from

my idea of the cmd 112: its simply two radius, parabola. if you compare the additional arguments to the regular radius arguments, it looks obvious. but i had not tested it up to now.
(i guess that was already mentioned before in the forum)


Scenery 'movement'

0- Robinio said the following:

Hello folks

Just a quick question here regarding the scenery.

I'm busy with a track now and I'm also doing the scenery. Normally I only have small problems wich can be solved easily, but now I've stumbled across a problem wich has driven me completly potty...

I've inserted a tree line (with a scenery command 0*b8 and a 0*af infront of that) on the left hand side of a sharp right corner. The 0*af command arg's are '-16384' and '16384' (in that order). In the args of the 0*b8 I've made sure the scenery starts well clear of the track (I've had it up to 7000!)

When I'm racing and approaching this corner the scenery kind of 'moves' back and forth and changes size a bit. Really strange. Does it have to do with the rotation of the bitmap on the ribbon, or am I completely looking in the wrong direction??

Thanks in advance, Robinio

Michaël 'NRG' Hompus from

You mean the scenery comes to the track, while it should be further away?
Well, we (DET) had the same problem with the chicane of the Nurgurgring '98, when setting the width of the 'scenery' at -16348 and 16348. The solution is to make this smaller, maybe 10000.
Greetinx Michaël 'NRG' Hompus

Sjon Stigter from

Robinio, I don't know what's causing your problem but I just wanted to correct the thing Michael said. The reason the scenery wend nuts at the Nurburgring was because I used values of -20348 and 20348 at the 0xaf command. This value worked good at straights and even worked fantastic on outside turns (it corrected the texture so it became less stretched). But on inside turns it went silly and came across the track. Sorry I cannot help you but I just wanted to correct Michael so you wouldn't be looking into the wrong direction :)
Sjon (DET)

Bob P said the following:

I had a similar problem with a track I am working on;
I solved it by adding a second (or more depending on track section length) set of scenery commands. Use the first parameter of the 0xaf, the offset (if your corner is say, ten units long, make this 5). Put the second 0xaf after the first ribbon structure command, then put the next ribbon structure command.

I'm no scenery expert, but I think this will solve your trouble.
Bob P

Mal Ross said the following:

Further to what Bob said, you could alternatively use extra 0xC0 commands to define the scenery on the left side (the outside)

of the corner instead of the extra 0xAF commands. This way, the inside of the corner won't be affected by the changes.


addie said the following:

maybe in addition to multiple scenery-cmd-pairs the cmd 0xba shortcut scenery could help ?! for details see chapter 3.5 of the scenery tutorial of martijn keizer.

in any case, be sure to have adapted the number of repetitions in the texture mapper cmd (a5 in 0xbc) for that area. if a texture area is streched like at the outside of the corner, it sometimes is necessary to increase this number.

i hope it helps

Martijn from

IF you have an exact parralell line of trees along the track, (that means the a2-a6 of 0xb8 and the 0xAF are EXACTLY the same, AND the trees still seem to come closer and further from the track, please check whether there is a "trackwidth change command". I *think* these cmd affect not only the trackwidth, but the overall perpendicular scale of the track (I KNOW distance to fences also changes because of trackwidthchange, but I'm not sure about scenery).

Robinio from

Regarding your message Sjon: I've had my scenery as
close as 3000. But I'll try 2000 or even 1000. Hey, maybe
I'll get lucky once! (I hope).

I'll also try Paul's advice: change the numbers so they're
devidable by 16. (Thanks Paul).


importing objects


0- yunisaz said the following:

can any help me with import/export of objects?

What I want to do is import all the objects from track A to track B, with all its x,y positions as they are on the origional do I do this?

The method I tried is to cut from the object view table and then paste on to the new track object view table, but the message i get is clip board is empty,

I`ve also tried exporting table data to a csv file, but have problems importing to the data on to the new track.
I might be doing this all wrong, so can any one point me in the right direction?


Fat Rat from

No problem .

#1 You have to do 1 object at a time(Saved GPO file) nothing do with any tables .
In the tree you highlight the internal object , then right click . choose export & save the gpo file .
Now you also have to go through that object to find all the texture ID# that object uses .

#2 you have to find the object definition & write down all of those values.
Then goto the new track , in the Object menus . Choose insert new internal object . then open the gpo file you saved , and it will be given the object # at the bottom of the list .

Now you must save the track , Now create a new object definition , again it will be the # at the bottom of the list choose the ID# of your imported GPO file , then the values you wrote down from the other track .
Save the track again .

Now you have to assign the jams with the right texture ID's , sometimes it's only 1 jam , other times it maybe 4 or 5 jams .
Now again save the track .

Last but not least . now use your new object definition ID into a track or pit section .

If the object definition is the same as the old one ( except for the internal object # ) this object should appear the same distances from center & height Etc. as in the old track .

Now remember that was only 1 object
Hope this helped
CU Les

Martijn from

you forgot to emphasize this procedure will sometimes/often crash the track completely, so be sure to have a zillion backups around.

Also sometimes the track just won't accept any additional objects after a certain point. :-( And, to make matters even harder, it seems you cannot export an altered object, but only an original one. Not sure about the last one, though.

Fat Rat from

Re your last point ( altered objects)

I have had no problems in this area . though I have run into problems importing identical(UnAltered)objects back into it's native track (Duplicates)

Seems to work better if I alter the object slightly ( which makes it an unknowm object ) then save it , import it .

GP2 seem to wonder why you would want 2 indentical objects in the same track , so if one object is altered this seems to be more acceptable to GP2.

Thanx Les

MartIJn from

Hey, That could be it!

I just exported an object and inserted it again, then tested if the track still worked (which it did not). I planned to make changes later, obviously.

I guess GP2 might indeed object (to make matters complicated :-) to two identical internal objects. Therefore change first, test later.


By the way, there is another thing concerning texturing objects, that I want to throw in the air.

1) I think that there's a code somewhere in the object-texturing section that sets the light-level of an object. Remember the starting-marshall from TunnelTrack? The flag seems to be a lot lighter than the marshall itself (which is another object). Maybe the starting light is set to be always brightest level (like the "light ribbons cmd")

2) Textures on non-square planes of objects can have two ttexturing modes: First is that the normal texture-shape is preserved, but the sides

of the texture that falls outside is cut-off. (like the grandstand-sides, I always wondered why there is no red part like in the JAMfile). Second is that the texture is distorted so that the square texture fits on the triangle plane.

This difference is very apparent on the different types of houses on the aforementioned TunnelTrack, where you can see this on the little triangle walls near the roof.


Paul Hoad from

I often suspected that some part of the object might point to an overal id for that object (perhaps the section WORD) you might like to try editing the gpo file with a text area so that this is different from the second object.

just a thought
Paul Hoad

Suggestion on the TE !

0-Daniel Ramos from


I think it would be nice to have in the object window
(that one we access when seeing a tree for example
and clicking on 'edit') a preview of the ADVERT
that will appear in the game.
let me try to be more specific in case I am not
being understood.
so far, we can see a preview of the bitmap
of a tree, but we can't see a preview of the
bitmap of an advert or side advert.
that would speed up a lot of people's work , at
least it would help me to make tracks faster.
and finally , the preview has to be exactly
what we are going to see on the track ( so
if ,in the object window, we switch the angle
making the advert show its back, therefore the new
bitmap will be shown) so we can have an idea
of which advert (campari, shell, ect) we can use
in ceratin parts of the track.

hope I was clear, although I don't have this feeling.
Paul, if you need me to be clarify that, let me know.


John Verheijen from

you can see the object in the internal object definition tree.
just click with your right mouse button on the object you want to see and choose 3D view.
then you see the object with the right textures.

Bob Culver from

But it would be faster if it popped up when you were selecting objects in the placement mode. It seems that an
enhancement like this might be simple for Paul to create.

Daniel Ramos from


My point was to see the object (advert) texture
in the object (or object definition) window in
a section tree. Why? because it is faster.
more convinient(is this speeled right?)
With the 3d view in the IOD tree, I can
only see the object lines(shape). even if I could see the
texture, still would be better to have a preview
in the object offset dialog window(Sorry for
too many names for the same thing :-)


Daniel Ramos from

(Paul, please read)
Bob Culver got the message. That is exactly what I was thinking of.
Thanks Bob. and like you said , (to Paul) this seems to be easy addition to the why not make this update...


Mal Ross from

Rather than pressuring Paul into responding, can all suggestions such as this one be sent to Bob P by email for the time being. Bob will then gather all comments together and Paul will be able to decide upon action to take then. :)


Bob P from

I was going to say that... although I did make note of all the comments, and stored them with your mail...

So remember folks, for the next few weeks, while thinking of what you would like from a future version of GP2 TE, write to me. I will not actually respond, rather I will summarize what people have to say and "report" to Paul Hoad.

A bit of "market research" you might call it :)
Bob P
address mail for this with subject GP2 or GP2 TE...

Detroit street circuit little bug help please!!:)

0-fabrice lagardere from

Creating detroit street circuit 84/89, layout and ccline are ok now.
For pits, i just have a small bug: a strange green texture just at pits entry on each verge (not on the road, so this is not a problem with scenery which i remove to "0"). Every cmd seems ok though, i don't understand. Does anybody have an idea?
Thanks for your help

Andrew D from

It could be a texture on the surface, or the view into the pits could be wrong.
I am not really sure, but if you go through Addie's pit tutorial step by step, that should help

addie from

i'm afraid the pitlane tutorial wont help you here. once helped me with a similar problem in the bremgarten track. the cmd 0xaf in the appropriate track section was set to 16384 (for rightside pits) and he set it to 24345 (o.s.s; see the bremgarten track for the exact value). this solved the problem, although we didnt understood why :)

maybe it helps


0-addie said the following:


cmd 112

its probably not news. i made my tests with the cmd 112 cc-line sectors and came to the conclusion, that the two 0x70-only-unks really are the 2nd radius. the regular radius arguments describe the radius at the beginning of the sector. the radius as given by the two unks describe the radius AT THE END of the sector. the line between beginning and end of sector has a transition radius, similar to a sector of an ellipse. if watching the originaltracks and imagine the parabolas at the appropriate sectors, it becomes obvious. a very good example is f1ct16.dat, adelaide.

another ‘proove’ of this is to set the regular radius in a cmd112 cc-line sector to 0 (straight) and also set the two unks to zero: you guessed it, it becomes a straight sector. i checked that.

last but not least: to transform a cmd112-sector to a regular cmd80 sector, just copy the values of the regular radius to the two unks. theoretically. practically, it doesnt work. the second radius seems to have to be bigger about 1000 than the regular radius (smaller 1000 if turning to the left), else the cc-line get messed up. thats what i found in the few tests i did here.

‘tighter/wider’ - argument

as you may know, the length unit of a cc-line sector is the same as with the track-sector, 16 feet, 4.87m. some of you may have had problems with this big grid when developping a reasonable cc-line. so did i. i always wondered why we have to deal with such a large unit here. the answer ? we dont have to actually ! we can be as precise as we wish, because we have the ‘tighter/wider’ - argument !

maybe we should call it “offset”-argument. my tests didnt allow me to come to a detailed conclusion, but as far as i saw, values between about +/- 300 do SHIFT the COMPLETE cc-line sector within +/- 1 length-unit ! bigger figures start to give strange and stranger results. in original tracks we see a range of maybe 9 to 288 as a value of this argument. (but i checked negative values also, and they work in the expected way.)

i didnt test this argument with cmd112 sectors, nore with straights, but i guess it also works here.

and, these two ideas also partly explain some strange things in the TE when showing the cc-line in the track-view. the first becomes especially obvious in original-adelaide. the 2nd is much more subtle.

happy cc-line editing

Paul Hoad from

Then perhaps this tighter wider value should somehow be added to the length value before the calculations are made, this might explain why a corner seems to go round much too far sometimes....
so if we can determine the units I'll be happy to try it out in the editor

length = length + (somescale*)(unks)

we would need to deremine somescale as of course length is in 16 feet units what is unks in?
Paul Hoad

Paul Hoad said the following:

What is the largest +ve and -ve number anyone has every seen for this tighter/wider value I have 242 at estoril
Paul Hoad

addie from

i looked at every original track: the largest value i found was 288 but i forgot where :) and no negatives.

as far as i saw the shift is always STRAIGHT. that means, the angle at the exit of the cc-line sector remains the same. if you give a positive value, its like inserting a little straight before the sector. if you give a negative value, its like cutting a bit off of the previous sector.

first i thought about 1 length unit = 256 "tighter/wider" units, but then a value 255 doesnt make sense. and there are a few values 255 in the original tracks. so maybe its 1 length unit = 512 "t/w" units ? (i dont know very good the english length system, so there is maybe a unit that makes more sense)

on the other hand, values about 500 already start to give strange results ...

Paul Hoad from

well this value is a WORD so it could be 0 - 65535 but it sounds like its not being used that large ever....
Paul Hoad

Michaël 'NRG' Hompus from

Hi, I found the tighter/wider options, so I want to explain somethings I saw:

as Addie said:
values about 500 already start to give strange results

this is because when the cc-line hits the side of the drivable sector (between the walls), so when the cc- line hits the wall, the cc-line comes back with the degree (I hope this is good English)
For example, when the cc-line goes off-road to the wall with a degree of 45, then it will come out of the wall also 45 degrees but now the other way (mirror) and so when it comes at the other side at the wall it will again mirror to 45 degrees the other way.

Off course the cc-line is not a straight line, so that's why you get those strange effects, but if you want to test, take a straight pice of track, with the walls very close to the road (banks:2) then be sure the cc-line doesn't hit the wall before this straight section, then make the cc-line hit the wall at the begin of the straight section, end then it will become to cross the road, till there is a turn or a cc-cmd.

as Addie said: (again)
values about 500 already start to give strange results

This is because at that section, or: the cc-line hits the wall (and mirror's). or: because you make the cc-line, by making it longer, so wider, take a turn of more then 90 degrees.

Maybe 512=90 degrees because a turn of 80 degrees also hit the wall it could be that that's why the cc-line already act strange below 500.

I think you have to count this value as an extra radius so having a radius of 10 degrees, plus counting the thighter/wider of 512as90 degrees, it would be:
10+90=100 degrees, and a very strange acting cc-line :-)

I hope you can make something about my point.

Greetinx Michaël 'NRG' Hompus

addie from

whatever figure +/- 300 you enter as “t/w”-value in a cmd80 cc-line sector, it DOES NOT change the angle at the exit of the sector. (btw: i made my tests in the 2nd chicane of hungaroring, around 2nd split. there you have a cc-line sector with a “t/w” value of 259, and enough verge-space. but first you have to “neutralize” the following cmd112 sector by setting the radius and the unks to zero).

so the “t/w”-value seems to be a simple straight offset of the BEGINNING of sector.
(i wonder why “t/w”-value should be an add-on to the regular radius ?! if you want to increase the radius then you could do that by increasing its value. precise enough.)

and: with “t/w”-values greater than say 1000 the cc-line-sector goes crazy even WITHOUT touching the fence.


Paul Hoad from

I'm getting confused here... perhaps some clarity....

What are we trying to say.

a) The unknowns of the cc line affects the cc line (simple enough!)
b) Previously we determined that these values effect the "sharpness" or a corner.
c) Now Addie is sharing his opinion. about what this does..
d) I have a number of questions arising from what you've seen addie.

If I take a 90 degree corner and put a value of say 100 in the unk what effect does this have on the corner? do I go round more or less that 90 degrees


If I take a 90 degree corner and put a value of say 200 in the unk what effect does this have on the corner? do I go round more or less that 90 degrees?

As I understood what you where saying is that becuase length is in 16 feet units sometime this is not accurate enough for the length of a section (forget radius for the time being!)

so Addie is suggesting (I think?) that the unks? could be a value that is added to the length to effect the calculations once the radius is fixed! this will have an effect on the corner! so if I'm correct then you would expect for the value of the unk to be some fraction of 16 ft hence there must be some scaling value on this unk to get it into some fractions of a single track length (16ft)

ok! I think this is where we are. If anyone else can shed any light on this value I'd be happy to try it out in the editor

addie said the following:

-if you take a cc-line sector with a 90degree corner and put a value of 100 in the unk, the corner is still a 90 degree corner, but starts a little further. by inserting a value 100, you insert a little straight BEFORE the beginning of the mentioned corner. i dont know HOW LITTLE the piece of cc-line is in detail, but i guess, some 500 will equals one cc-line length unit ?! but as i mentioned before, i havent done many tests. (the“discovering” of how the cmd112 cc-line sectors work is much more important to me. btw: yesterday i succesfully included the first of these parabolica-cc-line sectors in the cc-line of my actual track. it worked absolutely as expected)

-if you insert a value 200, the OFFSET of the beginning of the corner is shifted double the distance.
-thats right, a length unit of 16 feet does not let you be as precise as you wish to be sometimes.
-now we were only talking about the “tight/wider” unk. and the functionality of the cmd112 unks, could that be included in the TE ? that would be very useful. (but i’m afraid that could be a complicated one to implement ?!)


addie said the following:

ehm, sorry
-just to be sure you get me right here. you insert the value 100 to the "tighter/wider" value...

(the unks of the cmd112 are a different story...)

addie from

in the meantime i found: it was timmo (i'm sorry, i dont have the e-mail address anymore) in august who brought up the cmd112 cc-line sectors being sectors with transition radius in the forum.

here is what timmo posted (i hope you dont mind seeing it again, timmo?)

timmo said the following:

Summary of theory...

CMD 80 (0x50) describes a circular curve (constant radius)
CMD 112 (0x80) describes a transition curve (variable radius).
the first radius (like in cmd80) is the radius of the first subsection of the sector the second radius ( displayed in the 0x70 only boxes ) is the radius of the last subsection of the sector.

Change of radius for each subsection is (endRadius - startRadius) / (Length -1)

Looking at the Hungororing (f1ct10), you may notice
1: CMD 112 (0x70) generally follows a CMD 80 (0x50)
2: The graphic of the CCLine is (pretty much) OK until the first CMD 112

now look at the CMD 112's a little more closely. It occurred to me that if the CMD 80's describe a circular curve (constant radius), maybe the CMD 112 is a different type... In fact, maybe the CMD 112 is a 'Transition' curve, with a start radius given a 'Radius', and an ending radius given by the 'Direction 0x70 only' parameters.
For example, the first hairpin has the following CCline

Index 3 Length 21 Radius 12630
Index 4 Length 23 Radius 12630 0x70 only? params are (sign/Scale) 0 and (radius) 15700

So maybe CCline index 4 starts with a radius of 12630, and transitions to a final radius of 15700, with each subsection having a slightly different radius

startRadius = 12630;
for each subsection from 0 to 22 do
Radius = startRadius + subsection*(15.700-12.630)/22;
theta = theta + 1/Radius; // direction

Then each subsection can be treated as a circular curve. Maybe this is accurate enough? maybe not?
So I broke the cmd112's into lots of cmd80's, each length 1, each with a slightly different radius calculated from the above formula
The resulting display in the TE is very encouraging

1: the CCline still deviates from the track, but notice there is still one more unk for both cmd80 and cmd112, an it does seem associated with the remaining deviation. Maybe its a fixup?

2: What exactly is the sign/scale relationship with radius and 'Radius Scale' in TE

I came up with: realRadius = signScale * 65535 + Radius ?

This gives me values very close to those in TE, with exception of original CC sector 14 where radius is 21144 and signScale is -4 , I calculate 240996, TE has 306535, a difference of 65539?

NB: I couldn't get a value of 240996 entered into TE's Radius Scale box (is this a bug?, or my wrong assumption?)

3: I only looked at f1ct10. I think it should not take very long to change the TE so it draws the cmd112's using this idea.
4: TE suggestion. The Offset to CCline Data info is missing from the Track Offsets treeview

Other ideas ...
This structure would support a CC car 'look ahead' idea.

If we put a CMD 112 going INTO a bend, will they brake later?

I also guess that CCLine UNK3 and UNK4 could be a sign/Scale and radius.
Monaco is a right hander (2,34576),
Jerez a Left hander (-9!,55360)

I will send the mod'd f1ct10.dat to Auke Haarsma and Paul Hoad.
Maybe Auke, you can post an image, or the file? at

Paul_Hoad from

Well, your right addie this might be difficult to add in to see what addie means goto to


addie from

for implementing the cmd112 cc-line sectors. maybe you could take the approach of timmo (see the other posting) and divide the sector into pieces (maybe half length units) with different, but constant radius ?! it would not be perfect, but it would be a big advantage to the actual solution ?!


0-laurent said the following:

Is one limited in the number of cc-line?

addie from

especially for curved cc-line sectors !
i dont remember the exact number, but you have to sum the curved cc-line sectors and the curved pit lane sectors (no joke!), and the number should not be greater than about 70 (?) the max number of cc-line sectors (curved+straight) is probably at 256 (?)


Underlay bitmap

0-Bob P said the following:

I am just wondering if there is a specific bitmap size that one should use? I want to put a trackmap as the bitmap (what else?)... I load the bitmap, but nothing comes up.

Is it a size thing, number of colours thing?
Bob P

Paul Hoad from

There might be a number of colors thing I'd go for about 256 colors if I were you I'm not 100% sure though.

you have to have the bitmap button down that the one to the right of the world looks like two circuits
now to move and size the image goto misc config in the tree

by double clickin on the UnderLayBitmapX etc you can move the image around. the size of the image is upto you the track editor will stretch it to fit what you tell it to in the width and height section.

if it doesn't show up try another bmp format!
my backdrop image which is 450x525 and 24 bits perpixel bmp certainly works
Paul Hoad

David Richards from

I wondered about this too, until Ando told me what to do. At the bottom of the track tree, you see misc.config. go there and you see entries for width,height and x,y position. Double click on these and adjust them until they meet with your needs.
Good luck


Fuel supply

0-Klee Dobra said the following:

A question to all editors,

Is there a way, once a new track has been created, to make an alteration inside the edit project?
Here is the problem: Several of the new tracks, when race length is altered with gp2edit to say 25% or 39%, will not provide enough fuel for the cc cars to finish; and, when they pit for fuel late in the race, something goes wrong and they all retire. If the amount of fuel could be increased this would not happen. Or, perhaps there is another solution that I've not considered.

Thanks in advance for your help.
Klee Dobra

Ian Hill said the following:

If you have Track Editor you can change the fuel load by loading the track file and editing the "CC Setup" dialog box. The box includes a "Fuel Load" box and also a button to calculate the approximate correct amount of fuel for a lap. I don't know how this works so it may not be accurate for some extreme tracks eg flat-out ovals etc. Just increase this number if the cars use all their fuel too soon.

BTW The reason cars retire even after they pit is because the GP2 program thinks they should have the right amount of fuel on board given their pit strategy, so just changes the wheels. This is probably because the programmers did not expect new tracks to be built and knew the fuel load was accurate on the 16 original tracks.

Hope this helps.
Ian Hill

Filou said the following:

Hi !
In TrackEditor, go to Pit Stop Strategy in the Pitlane menu, and put in the number of laps you've put in GP2Edit. Then adjust the pit stops. This will affect the CC Cars Pit stops. Then you must try to increase the amount of Fuel in the CC Cars Setup section in the Edit menu. As you have increased number of laps, you will have to use "Trial and error".

Klee Dobra from

Hay Ian & Filou...
Thanks for the assistance, I'm off to give them a try-I'll let you know!
BTW. Ian, glad you have someone working on your banked Monza. It's a great track. You did a great job getting it put together, I hope those adjusting it can make it as realistic as possible.
Thanks again,


Help needed with JAM Editor

0-Filou said the following:

Hi !
Working on my track (a realistic Melbourne 98 on which I have already spend some months without any success ... what track editing is difficult for normal people ! :-), I first tried to make totally new JAMs using the JAM Builder coming with Paul's JE. The JAMs that were produced by this program were totally wrong ! They worked when I was loading them in the JE but as soon as I changed something (such as transparency etc ...) they got wrong, and they froze GP2 when loading the track. I was in deep despair of making my track ...
I decided to use originals JAMs and change their properties with the JE. I reorganize the textures, created the JAMs and all were ok. But when I loaded the graphics (Import Bitmap option) they looked right in the JE but wrong in the TE and in the game ! It seems the JE screw up the colours when importing bitmaps !
I need help on how to import correctly the bitmaps. I know other people have already do that (such as in SNQQPY's Imola) and I wonder how to make this correctly.

Please help me !
Thanks in advance

Ando from


creating your own JAMs and graphics with special sizes or colours isn't as easy as you might think it is. :(

As I had to experience there is a stupid colour range for each JAM ID which can't be changed (yet!?). It defines how many colours may be used in the ID.

If your graphic consists of say 100 different colours, and the colour range is only 70, the graphic will be messed up and partly transparent as it doesn't support that number of different colours.

btw: you must not import the bitmaps with the JAM-editor because the option doesn't work perfectly, especially the colour range is a big problem there. Here is what I always do, but this isn't perfect at all:

I create my own bitmap and import it into a JAM file using GP2Jam. Sometimes it says that an area has too many colours, then you edit your bitmap so that it has the right number of colours (you only need to change that special area of the bitmap that is given by GP2Jam!). Try again... when the bitmap is imported, load it into the JAM-editor and start to change th IDs and maybe also the sizes, but that's another problem. when changing the sizes of an ID, problems may occur as well. they are really strange because I don't see a decent reason for that. It's the same if you use too many graphics for an ID.

maybe someone has a better solution?!
hope this helps.


Filou from

Hi !

First, thanks Ando but I already know about the colours ! It simply seemed bizarre to me that the Import function didn't work well in the JE
because it looks very simple in other programs like GP2Edit r GP2Jam. But I have found another solution: I exported the bitmaps with
GP2Edit and found that it respects new JAMs IDs and IDs sizes ! So this first problem is fixed. Now I've got another problem (I think I'll
suicide myself before finishing this f****** Melbourne track ... :-): when I put a catch fencing graphic on a wall in the track, the fence
part of the wall is totally weird. Explanation: the lower part (the 'wall') is ok but the fence on te higher part is divided into 2 graphics
that are exactly the same. To help you understanding my problem, I've made these 2 screenshots, showing the fence problem:

Here are some infos about this:

- The JAM's IDs are 128x96, some based on the T_monspx.jam, some on the pavement.jam and some on ftrees.jam, so there are all
different IDs !

- The wall properties in the TE are all right, the rotations are right, the lenght is 1, repeat 1 and the wall hieght is 3, ut I've tried other
values with the same effect.

- I have the same problem with all my different fences graphics !

I really don't understand this trange thing, because I've already seen fences graphics having IDs sizes of the same size, sometimes bigger,
in some tracks (such as in SNQQPY's Imola) and I don't understand why my track has this problem. Has anyone already experiened this ?

Any suggestion would be helpful ... I'm planing to create a wonderful track and I can't because of these successive problems ... It's very
disappointing ...:-(

Once again, hanks in advance


CC-Line Idea

Paul Hoad from

If computer can be used to get the Shuttle off the ground,
Plot the path of Halley's comet,
Control a Bot in Quake
I'm sure they can be used to determine a driveable
racing line. in fact there used to be this
competition on the net that allowed developers
to come up with algorithims for determining the
best racing strateregy on a set course the idea
way then to race all the car against each other and see
who came out the winner but I can't remember
what it was called.

As I've said before if we could detemine the format
of the cc line then this would not be a problem
there are a few basic rules that can be used to
get a reasonable driving line round a circuit anyway.
optimizing the line would then become the art of the
guru and not the getting the basic line down in the
first place.

Paul Hoad

Bob Culver said the following:

Actually it is possible for computers to calculate cc lines. Anyone who recalls some of the formulas put forth by Gary Sandine, and
visited the CC line project page when these formulas and graphs were displayed can attest to that. Using calculus formulas, it is even
possible to calculate a line through a chicane, multiple radius or complicated series of turns. The problem preventing something like
that from being implemented is the current lack of total understanding of the relationship of how GP2 calculates the cc line versus the
track. Ponk worked at length trying to solve this to no avail (yet).

Martijn said the following:

This doesn't work, IMHO, let me tell you why

The hotlap file contains the INPUT of the driver, and then this input is played again as if it was normal-game mode. So there is no X-Y
reference at all. That also means that there is a very complex relation between the driver's input and the position on the track, just
think about skidding, drivng over a curb, the "reduce with speed" option, using a keyboard or a wheel, etc. Basically, I think this will
be as hard as recreating the entire game (unfortunately).

This is also the reason a hotlap (or an instant-replay) sometimes produces weird results; because of some round-off a near-cllision
suddenly becomes a collision, and then the whole driver's inputs after that become totally unrelated to the current positon of the car.

But I still think there is *a* way to plot the CCline correctly in the editor. I just don't know how.



I believe this has been investigated! Using the GP2LAP program, Rene Smit has been able to record
a drivingline and he can plot it onto a trackmap.

However, the problem remains exactly the same since a bunch of (x,y) coordinates is pretty
useless as long as the exact format of CC-line isn't known. GP2 doesn't know how to handle the
(x,y), so you still have to transform them to the right CC commands. If I'm right :-)

For more details you should contact Frank Ahnert (the man behind the GP2LAP program). Mail:

alfa from

Its a good idea. I thought of it myself a few months back. The idea being to let the editor create a
"line down the middle" CCLine.
You drive that yourself, and save it as a hotlap.
The editor then reads in the hotlap and creates a new CCLine. Repeat until perfect.
I didnt bother posting the idea though... for the obvious reasons.


said the following:

I suggest you both take a trip here
I'm sure if you would like to contribute, Michael would be only to pleased to hear from you!

Ian Hill said the following:

Great idea! The telemetry-based CC-line generator I mean. I haven't heard of anyone else
suggesting it, and I guess it could be theoretically possible - but it would be difficult without
knowing exactly the commands GP2 uses for CC-lines. I believe there's a project somewhere
dedicated to solving the CC-line mystery.

Ian Hill

John K said the following:

Ian's exactly right. Computers can't make decisions regarding certain racing lines from corner to
corner. The circuit I'm about to release right now has an abundance of corner combinations,
providing for different racing lines. A computer program would have to decide which line is
fastest, etc. Racing lines are currently something that only a human driver can find first.

Which brings me to my idea:

A telemetry-based CC-line generator. I don't know if anyone has thought of this before. If so,
please forgive me. Once you create your track and erase the CC-line, you drive the track at full
speed, normally. Then you save your telemetry data or hotlap and have a program read the file,
generate CC-line data from it, and export that data to the track file.

Or something that works similarly.

Ian Hill said the following:

Probably not, it's easy enough to make a CC-line down the middle of the road, but for a good
CC-line you need to move from the outside of a corner to the inside and back again to get the best
speed, and lines are even more complicated in close combinations of corners. I doubt a program
could work out all this itself. Besides, the way GP2 handles cc-lines is still not entirely
understood as you can see from the way the Track Editor can't show it properly. The only way is
by trial-and-error, aided by experience.

Ian Hill

0-Tom C said the following:

I have an idea, people say they can not create them (including me)
would it be possible to create a program that records what you do
in the editor and then make the appropriate changes in the cc-line

Tom C


unk hunters report (0xd4 and 0xd6 baged)

addie from

another two unks chased down (at least thats what i guess) ...

here is how they will look like in the next update of the cmd-lib:

cmd 0xd4 (212) View All Pit Lane From Entry, 1 arg

a1: Offset Into Sector

This cmd works similar to cmd 0xd3, 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 entry "through" the pitlane to the exit. Thats probably why this cmd is used but there.

cmd 0xd6 (214) View All Pit Lane From Exit, 1 arg

a1: Offset Into Sector

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 probably why this cmd is used but there.

happy editing