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
Scenery
revealed Unk command that switches
scenery quake - 0xaf(175) 0xc0(192) 0xc1(193)
Fences
split time commands?
Please help (gravel trap problem)
Bob P from 24.64.2.35:
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
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
babbel
Martijn from 130.161.124.18:
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... :-)
Martijn
0-Mal Ross from 193.237.112.166:
Until it appears on the CCLP pages (http://www.grandprix2.com/cclp/), 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.
Cheers,
Mal.
Bob P from 24.64.2.36:
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 194.191.82.13:
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 ?!
addie
Mal Ross from 193.237.112.166:
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?
Mal.
0-Jason hope from 206.172.146.161:
hi
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.
Help
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)
David
Paul Hoad from 194.222.192.203:
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 205.188.196.22:
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 206.172.133.70:
divide by 0 SOLVED MY PROBLEM
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 194.222.192.203:
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 152.163.201.196:
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.
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 62.216.1.101:
SiS chips are NOT compatible with GP2...
As for your GPL problem goto www.voodoo2.com and download the latest drivers.
MiXer
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 ?
Thanks
Malcolm Mitchell from 194.168.120.67:
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 :-(
Cheers,
Malcolm Mitchell
Bob Culver from 153.35.224.193:
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.
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,
Robin
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!
{M}
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 ...
addie
John K from 205.188.193.38:
Martijn,
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. ;)
0-Mal Ross from 193.237.112.166:
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 http://www.humford.demon.co.uk/ (it's
only about 17kb).
Cheers,
Mal.
Bob Culver from 153.35.201.177:
Try placing the camera in the tracksection with the view into pitlane command
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 ?
GC
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 207.34.182.17:
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.
Thanks,
GC
addie from 194.191.82.13:
hello
the bern-grauholz track includes (among other things) 272 track sectors (maybe thats
why TE 1.7.4 crashes when trying to load? however 1.7.3.172 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
addie
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 194.168.58.61:
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)
David
0-by addie from 194.191.82.13:
i havent yet posted a detailed explanation of the 0xc5 (and 0xc6) cmd simply because
i dont have it :)
honestly.
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 :)
addie
(once more thanks to babbel for turning my interest to 0xc5!)
by Fat Rat from 24.113.17.7:
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
Les
addie from 194.191.82.13:
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 ?!
addie
John K from 152.166.97.124:
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 207.253.117.155:
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.
Thanks
Jason hope
0-Dan from 207.34.182.67:
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.
Dan
addie said the following:
can you say which track-sector(s) it was in the suzuka track ?
addie
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
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.
Dan
------------------------------------------------------------
0-addie from 194.191.82.13:
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")
hello
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
addie
Mal Ross from 193.237.112.166:
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 194.191.82.13:
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
addie
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 194.191.82.13:
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.
addie
0-yunisaz said the following:
Has any one discovered the commands for the intermediate splits?
yunus
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 194.191.82.13:
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 195.193.225.79:
it wasn't 1/3 , 2/3 , it had something to do with track segments but I can't remember
what :)
0-Bart Vandevelde said the following:
Hello
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)
Thanks!!!
Bart
addie from 194.191.82.13:
hello
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
addie
Fat Rat from 24.113.17.7:
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