as collected and (very little) formatted by addie walti
The start of a thread is on top right below the title
Practice works but not race!?!
Heights-problem in TE 1.8.3
Heights (+The Complete Heights solution)
Clermont-Ferrand and Strange CC line
phenomenon
Question (track through local city)
Bad font character /grid menu bug
black horizon
NEW: Command 0xB2
NEW: Command 0xB6
Internal Object Names
JAM editing - untextured colours
NEW: Command 0xB7
NEW: Command 0xCC
NEW: Other commands
pictures please
0xd0 values???
Car direction after leaving pitlane?
Detail levels in object descriptions
Reserved\hardwired offsets
cc-car coaching news (+0xd0)
complex objects
0xd0 - no more doupt
0xc5 - unk a5: figured out!
black horizon II
0x9A and 0xAC de-unke
Camera distances in TE display
object problems
newbie camera question (pixeling)
Another newbie camera question (freezing)
Adjusting start position
frustration (mapped texture does not show
up)
altering internal objects scale
Gaps in fencing
0xc5 fully de-Unked ?!
Posted by Mikael Olsson from 195.67.208.243:
I'm working on an old short CART track right now and have just finished the cc-line.
Everything works fine while doing practice laps on my own
but, when I was going to make the first quickrace-check-the-cc's test,
the game locked up completely while loading the track. Can someone give me a hint
of
what I may have done wrong?
Posted by Malcolm Mitchell from
195.147.246.146:
Keep up the good work, Mikael! I added the other
tracks you released to GP2HIST. Those shall be, too,
if there is a place for them.
Sorry, I can't help with your problem - but I'm having a
similar problem with loads of released tracks - obviously
nothing to do with track editing, as they work on
everyone elses system, but GP2 just stays on the track
map pic. Any help, anyone?
Cheers,
Malcolm Mitchell
Posted by µartijn from 195.96.98.222:
This is almost certainly caused by too many JAM-files, or to be correct, too many
kBs of JAMfiles. So you'd better remove a unused JAMfile from the list, and try again.
Chances are, it works.
Reason is that there's a larger crowdtexture being loaded for races than for practise
(the empty stands) thus you get just past the limit in races.
Posted by addie from 194.191.82.13:
martijn, any body
do you know the exact limit (figures) for the jamfiles ?
Posted by µartijn from 195.96.98.222:
No. How can I measure that? The TE doesn't have a "calcualte total JAMspace
used" button, has it?
Besides, I'm not entirely sure whether the "preloaded" JAMfiles are of
any influence as well.
Mikael, please drop us a note if your problem is cured in the meantime.
Posted by Mikael Olsson from 195.67.208.243:
Well, there must be something else I guess.
The only jams I'm using so far is the dproad.jam, grassverge.jam
and a one jamfile for the fences. I didn't get that
far that I had begun with the graphics.
Otherwise your suggestion sounded correct.
Posted by addie from 194.191.82.13:
the height-calculations in the track-data-table in TE 1.8.3 seem to be not y2k compliant.
at least they do not work somehow !? or did i miss something ?
Posted by Paul Hoad from 195.92.194.19:
Addie the height thing was my fault do you remember there was some discussion over
our method of determining height
I tried to make the changes but it broke the height readings
I've tried to put it back now!
lets hope it works again!
If anyone does know the proper
mathematical method for determining the height I would be interested in getting this
part right!
perhaps the values are for
the derivative of gradient
which would be (rate of change of gradient!)
Paul
Posted by Iso-Hannula from 195.197.160.42:
>Addie the height thing was my fault do you remember there was some
>discussion over our method of determining height
>I tried to make the changes but it broke the height readings
I feel responsible for this. I made a lot of research of track heights. And I found
that that height calculation is just same as horizontal curves in track. There are
length of sector and this "curvature" (angle in your box) in data. When
you myltiply this angle-value with length of sector you get an angle. 65536 corresponds
to 360 degrees. Ok?
Then we simply replace height for angle. angle-height. Now we can calculate vertical
"curves". And 65536 corresponds to 360 degrees. At least this gradient
is simple to calculate?
I think that I gave you my piece of code, which calculates the heights. Isn't it
clear enought.. I has been disappeared from this forum, but Addie may have it.
These two methods (yours and mine) give nearly same values in proportion. But the
main benefit is that my method gives gradient in degrees and height in meters. At
least for me it is easier to understand than unitless numbers as 4000 or -200.
I found the code:
---
Variables:
l=length
b=delta height
m=gradient
g=cumulative gradient
a=cumulative altitude
---
g=track start height (delta);
a=0;
for(i=0;i=current sector;i++) {
if(b!=0) {
m=b*l*45/8192;
a+=2*l*180/PI/m*Sin(m/2)*Sin(m/2+g);
g+=m;
}
else a+=l*ksin(g);
}
---
I explain this a bit.
Variable names as just same as in your editor (table). First two values listed are
individual for every sector. Third (m) is calculated from first two and last two
(a,g) are used to store cumulative gradient/altitude.
Track start height is in track config section.
So you have to calculate this for EVERY cell. First we calculate it for the first
cell. Current sector is so 0 and loop is calculated once.
We have to put some values in g and a at start. g is found at track config section
but cumulative altitude has to be put to 0 (or if you have some other value).
Then we loop from the first sector to the current sector:
We have to check if b is zero. If it is and we calculate m=0 then the next formula
gives "divided by zero". That's why we need that.
Inside if-sentence:
First we calculate m (similiar to your GRADIENT). We get the change of gradient (in
degrees). 45/8192 is the conversion factor (same as 360/65536).
The next formula is the most complex. I gave some explanation of it before and I
can't remember it longer. But you HAVE TO believe me. There is constant PI which
is 3.1415926. And Sin-function which uses DEGREES. Nothing tricky.
And finally we add m to the cumulative gradient. If m is negative then g is decreased
otherwise increased.
When the loop is over the current cumulative gradient is in variable g (in degrees)
and current cumulative altitude is in variable a (in tracklengthunits). If you want
to print altitude as meters, multiply it with 4.8768. But not before the loop is
over.
I have heard that you have made the TrackEditor 1.8.3 by Visual C++. My code is simple
C and as far as I know this piece of code should work in your program as such. Just
replace the variables.
Posted by Paul Hoad from 212.2.17.129:
I think this need some looking into possibly a new view that shows the profile
as this method will give the
"Brow of the hill" effect that
can be seem by GP2
I'll try to look into this aswell
Paul
Posted by addie from 194.191.82.13:
paul, with “brow of the hill” you mean the “huge ramp” ?
paul, vaino, all, i guess its a matter of units, or better: a matter of the scale
of units, thats missing yet.
in the track config section we also have the “track start z” value. we have to understand
how the units of the “track start z” value and the cumulative altitude value of the
formula of vaino correspond. probably its a simple multiplikation. if we know THIS,
and if we apply the same multiplikation to the cumulative altitude value (and if
we have set the cum alt at t0 to the value of “track start z”), we probably will
find some plus/minus 32768 value at the position of the “huge ramp”. any bells ringing
?
two more ideas:
-if the formula of vaino is correct (i dont doupt it) it should be possible to make
loops !?
i already tried about two years ago, but maybe i was not brave enough. any volunteer
?
-up to now all trackeditor programs have drawn flat projections of the tracklayout
in their track-view-windows. but if we have a tracksector with a big gradient, in
reality the projection of it on the flat should be SHORTER than the actual length
of the tracksector (cosinus) !? no doupt.
i just wonder how its done in gp2, which is (dont forget !) our reference here ?
when looking at the original tracks, i come to the conclusion, gp2 works also simply
with the sectorlengths in the projections, as do the editorprograms so far. i made
experiments of the pretty weird kind on this, and they all confirmed. i wonder whether
its really like this, or my experiments simply were not weird enough (again).
vaino, you proved to be more spirited in creating extreme experiments to show limits
:)
(btw: dont get fooled by the overlap of the ends of the track in the original tracks.
there IS an overlap by 1 unit. i checked this by mapping textures on the road)
i hope its useful information
addie
Posted by Iso-Hannula from 195.197.160.42:
Well, I explored this theme a little bit.
I finetuned before found limits +/- 150 meters. I found that (when start z=0) limit
is 156.12 (tolerance 0.14). In meters. When we divide this by 4.8768 (meters-tracklengthunit)
it is nearly 32. So there it is!
Possible altitudes are +/- 32 tracklengthunits! And when we compare this with possible
start z values (+/- 32768), we get that one tracklengthunit corresponds to 1024 GP2-space-units.
I tried this further more... I put 1024 to Start Z -value and found that it is 151.2
meters when "huge bump" limit was exceeded.
Maximum height difference in GP2-tracks is 312 meters!
I think there is now enough evidence. Everyone can try this with my editor. First
red value is gradient and second is altitude. Cumulative-values, gradient in degrees
and altitude in meters.
Posted by Iso-Hannula from 195.197.160.42:
Now we can add this height calculation in "Sanity check"-method, and we
won't see those "huge ramps" any more.
btw: Loop is impossible.
Posted by addie from 194.191.82.13:
vaino, well done !
is there a technical reason why loops are not possible ? or is there simply somehow
an artificial limit for the cumulative gradient (as it seemed to me in my tests),
e.g. some 90 degrees ?
Posted by addie from 194.191.82.13:
vaino, do you also have an idea about the “projection”-subject in my former-posting
?
Posted by µartijn from 212.64.16.32:
I personally would find it pretty strange that GP2 would use tracklengths of
5.2 meters when there's a sloped piece of track (which is what you're implying, Addie,
if I get you correct).
Remember that usually there's as much track going up as there is going back down
again, so these things are likely to even out over a track. Unless you make a oval-like
track that goes level one way, and big dip and rise the way back. But then still
, the effect would be hard to notice, as the start and finish get connected anyway.
The best place to notice this would be the pitlane. But again, not when you have
a nice straight pitlane. You need a pitlane that returns to the track at a 90-degree
angle to see the effects.
And I remember a track (Clermond-Ferrand) with large gradient-changes and a 90-degreepitlane
that was really messy (were you able to fix that, Addie?)
As far as seems reasonable to me, loops are impossible because the gradient value
gives the amount of rise you get over a certain distance, and even if you make that
very, very large, it still won't turn backwards. The values is like an tangens value,
and even when you take the inverse tangens of a very large value, it won't never
get beyond 90degrees into the sky. For a loop, you need more than that.
Just my two Eurocents.
Posted by addie from 194.191.82.13:
vaino, you mentioned “65535 corresponds to 360 degrees”, but there are no loops !?
could you simply replace the Sinus-function by Tangens-functions in your formula
for a test ?
for the relevant range of values Sin and Tan are pretty similar ...
Posted by Iso-Hannula from 130.233.249.79:
It WOULD. But it wont. That's the fact.
Everyone can try what kind of track is made when put height*length of sector is above
16384. I won't do anything. I have found that only gradients between -8000 and 8000
are practical, -45 - 45 degrees. If you use more, it would be too sharp and car "jumps",
when crossing it.
---
I believe that GP2 uses flat base. The main evidence for this is that CC-line doensn't
move when altering heights. Because track and cc-line are independent from each other,
it track length won't change when using heights.
But in other side, heights are calculated with same system as curves, so it should
shorten sectors, when using heights.
Addie, you can try this, with your "mapping textures on the road" -track.
Make it go long way to one way, sharp corner, and anothen long section and back.
I mean just like Golden Gate -track (by Matti). On the other side use much heights
and other side no heights. If s/f line is still at same place, GP2-world is flat,
just like in our editors.
---
Sin-Tan. Which one Sinus is changed to Tangent? Well, I'll try it.
Posted by Paul Hoad from 212.2.17.129:
Often wondered about this the top-down view of the track
editor could well be wrong becuase of shorting of the
sectors due to height changes...
Do height changes make a difference to CC line?
Paul
Posted by Iso-Hannula from 195.197.160.42:
No
Posted by Bob Culver from 192.246.108.36:
I read Martijns message regarding the Clermont pit lane. It is much cleaner now Martijn
so I was able to repair it after consultation with Addie. I am well into scenery
having discovered some additional reference material.
A strange thing happened. I have been away for two weeks (making sure Y2K didn't
paralyze our company) and took my laptop with the TE (1.80 which functions like a
non registered version on my laptop). I worked on Clermont quite bit, only modifying
scenery ribbon values. When I got back home, I loaded the final version from my laptop
back on my PC and discovered that the cc line about 1/2 way round was not correct
anymore. I have tediously checked every track section and cc line section, and none
are changed. In the TE, the version from my laptop appears identical to a previous
version with the cc line that is good.
I have several theories for this.
1. Possibly scenery commands are tied to the cc line....I figured that this was highly
unlikely, but thought I would propose it as one potential culprit.
2. Pentium floating point error. My PC at home is a Pentium 1 233 mhz mmx and my
laptop is a P2 400 mhz. Maybe there is a slight difference.
3. Is there some sort of a difference in a registered versus unregistered version.
4. Maybe I missed something like a track width that was accidently changed, but I
don't think so.
Paul, if you care to investigate, I can send you both tracks.
Posted by Paul hoad from 212.2.17.129:
You can rule out 3 for sure!
I suggest making the track available for others to look at an perhaps a gif of the
track on both screens
Paul
Posted by 230artijn from 195.96.98.222:
you can rule out 4 too, trackkwidth doesnt make adifference.
Posted by 230artijn from 195.96.98.222:
Bob, did you perhaps make a difference to the LAST tracksection (like lengthen it
for the pitlane..)? That sometimes messes up the CCline badly.
Another VERY tricky thing is this: you enter a value in the TE for the angle of a
corner, like 2.2. When you then save the track, and reload it, perhaps change it
or set it again, sometimes the angle get changed to (like) 2.194532758563653759.
When you re-enter a value in this box again, the roundoff sometimes works slightly
differently.
This is especially true and difficult to find when you're changing a track that's
in part "original", as you don't know whether Geoff entered 2.2 in his
angle-box, or 2.195.
I think that a close examinuation of the exported trackdata might reveal a slight
inconsistency.
Could you perhaps tell what you had to change on Clermond's pitlane? Was it just
trial-and-error? What did you change? (pitlane length, or the walls?)
BTW scenery is, AFAIK not tied with CCline. I've made a lot of scenery, even from
scratsch, that didn't affect the CCline. (then again, some of them weren't too good
to begin with anyway, I've been told...)
Posted by Bob Culver from 192.246.108.33:
This may be the answer. I did alter the final turn radius very slightly, but it is
not the last track section, but is 3-4 segments prior to the last one. I was not
finished with the cc line, and still had several turns to go and the section modified
was well after the portion where the cc line was complete. I was able to change one
cc line segment radius by 120 units, and the cc line is now fine.
It is still strange that the display in the TE was the same.
Posted by jason hope from 209.104.76.93:
hi,
once, i was experimenting with the cc-line, even though i never actually made one.
When i extended a track section by one unit, the whole cc-line was screwed up. So
Bob, i think you are right with what you said.
Posted by addie from 194.191.82.13:
230artijn, are you sure you can rule out 4 ?
theoretically i agree, but (gp2-) practically i’m not that sure.
however, if you had the cc-line at the border of your track, and then made the track
more narrow, the cc-line probably gets affected ...
Posted by µartijn from 195.96.98.222:
Well, the CCline certainly is not affected when you *widen* the track. I've done
that (succesfully) a few times in the past. As to narrowing the track, so the CCline
stays on the grey stuff, I'm moderately certain it is OK to do. It's like the inverse
operation of the one above. (that is no sound agument with GP2, I know)
When you narrow it so the CCline gets on the grass, or even past the fences, you
might have a problem.
But haven't you had any experience with the roundoff error I describe above? I've
had it a few times.
Posted by Paul Hoad from 212.2.17.129:
The Round Off error is probably becuase angles are
expressed in decimal not floating point within 0-0xFFFF
which mean there are only 65535 descrete steps to a circle....
rounding will occur I possible
show the angle as you might?
expect it to be and not as it will be when its written out!
slapped wrists for me then!
Paul
Posted by addie from 194.191.82.13:
i got trapped by the roundoff “error” several times in the past and i always wished
to be able to insert directly the gp2-value (0..65535), as i’m not afraid of big
figures. same for all other arguments. i dont mind calculations for user-friendlyness,
but i prefer full control ...
in the meantime i suggest to close and re-open the track from time to time when working
at the layout and CERTAINLY before starting with the cc-line. though i would suggest
to make the cc-line at the very end anyway.
Posted by Malcolm Mitchell from 195.147.246.146:
Happy new year all!
Well the heights and track widths doesn't make any
difference to the cc-line. I've changed both without
destroying lines. I've never changed the width so much
that the line is on the grass, but I would've thought
you can just move the cc-line back onto the grass?
Bob, can't you just recover one of the backups that the
TE makes? (though they've probably been replaced now!)
Cheers,
Malcolm Mitchell
Posted by Bob Culver from 159.37.7.57:
I worked on the track for almost 2 weeks on a laptop without being able to test drive.
So in a sense I modifyed quite a bit without current back ups. I could go to my version
just prior to working with the track on the laptop, but the rest of the changes are
fine, and it would take more time to back and re-do those changes. I suppose there
were some risks in doing this, but I was only working on scenery ribbons...no commands,
no textures...no cc line changes....no track changes..(well oops I think I changed
the last turn slightly). But even so, I have changed track sections after the good
cc line in the past without problem. And, the cc line was not a disaster, just changed
enough to know something had happened.
I have repaired the cc line already. My point is to try and see if a connection can
be made to help Paul solve the cc line distortion problem.
Posted by Fat Rat from 207.194.18.101:
Hi all
Seems like were starting to move backwards here . Heights , CC line and Location
codes . Sounds like the old 1.51. days . Not necessarily a complaint , more of an
observation .
CC line , corruption , distortion and stability . I would have to disagree with much
of this last discussion on CC lines
Now this info is NOT 100 percent applicable . Like much in GP2 there are more exceptions
than rules .
A lot of this depends on the stability of the track . Yes with SOME tracks you can
make these types of changes without drastically effecting an existing CC line .
But on the other hand the following have effected a CC line . Heights , track width
,banking , scenery and verge widths . All CAN effect a CC line .
Now I’ve experienced both sides of all the above , I’ve completely reworked an entire
track with the CC line surviving . Including very dramatic changes .
But on the other hand I’ve made very small minor changes (In only one area) and had
to redo the CC line . Just recently I lost a CC line from scenery .
I received the file from Addie , made a copy played with the heights . ( no problem
) Was try to make more accurate & get rid of the black horizon problem .
So in one copy I zeroed all scenery , reworked the heights to where I liked them
. Saved that copy
(Redone heights & zeroed scenery) . Ok then I imported the table data into a
copy of the original , looked great .
Then I raced it . The CC line was out at the esses . I went back to the copy with
zeroed scenery . Same heights , original CC line and zeroed scenery . The CC line
is fine in the essses .
Never could build a copy with these heights , original CC line and scenery . So it
was not just the new heights , but in combination of the zeroing of the scenery .
The conclusion being , much like your discovering the tolerance limit regarding the
heights . There are the same type of tolerances for CC line stability , What they
are . I don’t know
BTW : Watch for viewing cmds changing the placement , At least where the objects
"appear " to be placed on the track . In the first Van Indy , I had a hotel
get puled all the way from a corner close to the tunnel entry . To across the road
just after the pit exit , Dragged it all the way across the infield .
Have fun
Keep looking
Les
Posted by addie from 194.191.82.13:
les, may "then i imported the table data into a copy of the original" caused
the problem ?
Posted by Iso-Hannula from 195.197.160.42:
Sorry, what I have said before. I claimed that track and cc-line are independent
from each other. Now I found that they are not. Track affects to the cc-line. I don't
know how, yet.
But I noticed, if curve is nearer inside corner the total angle is less than editor
shows. Only if cc-line goes along center-line of track, curve is in GP2 as I have
thought. I'm examining.
Posted by Sensible Joe from 194.125.173.241:
Any chance of designing a track through your local city - Dublin would be nice?
Posted by addie from 194.191.82.13:
sure :)
Posted by Andrew D from 209.78.50.118:
I was thinking about doing a track around the streets that i live on. Still might
do it once i finish the 2 tracks that i am working on.
Cheers
AKD
Posted by 230artijn from 195.96.98.222:
I'm almost done.
First, I have to make tonns of money. Then, I move to Monaco. Then, I'm done :-)
Posted by Fat Rat from 207.194.25.143:
To Addie & all
I was surprised recently ,that Addie seemed unaware of this bug ,.The bug I mean
.
Is just before the race , in the starting grid menu . All the garbled letters , characters
and numbers all over this menu .
Then if you try to scroll you can get the bad print character or font or whatever
. sometimes you have to " wipe " away the corruption to get the OK button
. That bug .
Has been talk about alot , the consensus seems to be with the "Naming of the
tracks" The difference in the number of characters with the new name compared
to the original . This is only one very small part of it .
This does effect , no doubt about it .
I’ve written before that this is also effected by the controller calibration , the
"season file" as a whole . So the total effect of all other 15 tracks residing
within one season .
Now to my main point , when developing tracks . Editing while in the same slot ,
same season , ( maybe same controller cal. ) this does change on boot up & sometimes
I re calibrate once in a while . Otherwise a "Controlled " experiment .
I find that if I check this start grid menu problem from time to time while doing
a track .
Either to test a cc line or view scenery, lap times whatever reason I’am the cc cars
in race conditions . I see that the degree of the corruption varies a great deal
and during specific phases of development .
Say while doing the CC line it will change alot . maybe all most none with no cc
line to a single diagonal line with half a cc line , to none functional when rounding
the last turn . the back to nearly none when done .
an example .
Or without any objects to verses finished , before during & after scenery . etc..etc.
I actually use this as a barometer of how the track will perform when finished or
even whether or not it will function at all . I try to have a reduced amount of corruption
version as the final released version .
In other words I’am about to release , if have a few different versions with minimal
changes , then the deciding factor will be which one has the least amount of this
problem . Again this may change with slot choice , seasons , window vs Dos , how
well my controller is calibrated .
So like my last post , no written in stone rules . Just general editing & usage
occurrences.
"The truth is out there"
Angent F Mulder
Have Les
Posted by Bob Culver from 204.151.114.9:
The first garbled menus I recall seeing were definately due to the Instant Access
track pack.
Posted by addie from 194.191.82.13:
black horizon problem
maybe its old news for some; but at least for les and me it isnt:
the texture id 32 is the default texture for the gp2 world !
whatever texture you take and change its id to 32 will be the default texture for
the “space” below the horizon, below everything ...
normally there is a file grasverg.jam and/or verg280.jam in the tracks jam-list which
includes a texture with id 32. if you remove these jams from the list without replacing
by some substitute, you get “the black horizon”
i hope its useful information
addie
Posted by Paul Hoad from 212.2.17.129:
Missing a jam of id 32 from the list is now a test in the sanity check ready for
next release (1.8.5)
Paul
Posted by Fat Rat from 209.53.102.50:
Hi Addie.
Great , one question , anyone know the location code for the world .
Will try renaming another jam id to 32 . See if this will texture the world or if
there is something specific about that texture ID and the oridginal jam .
Finally the black cloud has lifted from the horizon
THanx Les
Posted by 230artijn from 212.64.17.165:
While you're at it, could you also please find the way to "scale" the horizon?
It would be great to have some large mountains in the surroundings, but the defualt
horizon is way too small for that.
(btw I really need to download another Alt-key. Anyone know a good site?)
Posted by addie from 194.191.82.13:
les, i already did change the id of an innocent advert to id 32 to get it mapped
“on the world” - thats how i found id 32 is the default id ! i doupt the existence
of a location code for the world, because we already have a default-id for it.
Posted by Fat Rat from 207.194.25.204:
Morning Addie
A loc code other than banks 18&19 ???
A small correction or clairification to Addie's 1st post .
Also the jam in gamejams it self called " landscape.jam"
also carries this default texture ID
THanx Les
Posted by John Verheijen from 212.64.25.123:
What about id 32 in the monaco track?
There it's called flat1_.jam
Posted by John Verheijen from 212.64.25.123:
And all of the tracks have a double id 32,
except Monaco, Silverstone and Monza.
John
Posted by addie from 194.191.82.13:
no loc code for “the world”. at least i dont see any sense in this.
there just has to be a texture with id = 32 in one of the jams in the jams-list of
a track. the name of the jam-file does not matter. only the id of the included textures
is important.
Posted by Iso-Hannula from 195.197.160.42:
I made a little research about unused track commands.
0xB2 (178) is not used in original tracks and I think that is reason, why those commands
is not explored. At least within the last year.
0xB2 has 2 arguments. I don't know what the first argument makes (maybe nothing as
usual).
I found that second argument a2 has an affection. It has slitted in bits as 0xB0.
But I noticed that only first two bits are used.
Bit 1: turns off the left boundary line.
Bit 2: turns off the right boundary line.
This means that value
0 has no effect,
1 turns left line off,
2 turns right line off and
3 turns both lines off.
It's a pity, that you can't edit this command yet. But I have added it in my editor
and I'll try to publish a new version asap. With old editor it can be added and edited
too, but the number of arguments is wrong and it causes only mess. But with hexa-editor
you can edit it, just add e.g. command B0 (which has two arguments) in TE and then
with hexaeditor change commandnumber and argument-values.
Posted by µartijn from 195.96.98.222:
Great! That sounds like a fun command!!
Posted by addie from 194.191.82.13:
congratulation !
and 0x8c (140), 0x8d (141), 0x93 (147), 0x9c (156), 0x9d (157), 0xae (174), 0xb1
(177) and 0xb3 (179), 0xb6 (182), 0xb7 (183), 0xcc (204) ?
Posted by Paul Hoad from 212.2.17.129:
Excellent find how did you discover the extra command?
is there any merit in including additonal commands
such as 0xb1 (what might that turn off?)
1.8.5 contains editing of this
Paul
Posted by addie from 194.191.82.13:
0xb2 - is it a switch to turn the lines off and on again, or is it just to switch
them off for the whole track ?
Posted by Iso-Hannula from 195.197.160.42:
Just off. And it affect to the whole track, also pitlane.
Posted by Bob Culver from 206.173.161.215:
I tried this command. Much promise for us classic track builders. Eliminate the big
white line, and can paint feeble excuse for a line like in the old days. But, a curious
problem on my track. The sections of the pitlane "outside" (either before
of after the pitlane fences) still have yellow lines, and the appear distorted. I
will try on several different tracks to see if this is unique to this track (C-F
which has a strange pitlane anyway) or if it is consistent when using the OxB2. I
used the command on TS-0, and used 3 per your instructions. I also tried a seperate
command in TS-0 of the pitlane, but there was no difference.
Posted by Bob Culver from 206.173.161.215:
Confirmed...all tracks including original end up with the outside pitlane sections
with distorted yellow lines. Maybe one of the other unk commands eliminates them?
Posted by Martijn Haans from 145.85.27.250:
Here's a question:
The 0xB2 command is now discovered to turn the boundarylines off. Shouldn't there
be a command to change their colour too?
Maybe a stupid question, but since it's possible with other trackmarkings...
Posted by Iso-Hannula from 195.197.160.42:
I made research about command 0xB6. It is/was unknown.
Results:
2 arguments.
a1: not used
a2: pitlane start angle
I tried this command first at track (t01) and then at first sector in pitlane (p00).
There were no visible difference. I found that positive low values turn pitlane start
angle to left and negative to right. My pit was on the right side.
I found that if used values above +/- 300 angle was decreasing! I haven't yet tried
this with "real" track. I tried it with my test track and when pitlane
start angle was changed GP2-engine twists track so that end of pitlane connects to
the track.
That's what I know up to now.
Posted by Fat Rat from 207.194.18.211:
Hi all
must of missed something , I can't find any reference to a 0xb6, even as an unk .
What is the cmd #
THanx Les
PS.
I've found the effect a long time ago , thought is was just a hardwired pitlane start
angle
Posted by Rob Huffer from 202.137.80.194:
Is there any way to permanently rename an internal object in the TE. Currently, if
I alter anything on an internal object it becomes and unknown object. I can rename
it in the TE but the next time I open the track it becomes unknown again.
Posted by John Verheijen from 212.64.25.123:
I know that you can see the changed names in version 1.7.6
The later versions don't show the new names.
But if you open the track in version 1.7.6 you see that the names are changed.
But from version 1.7.7 the new names don't show up.
Maybe you can check this out Paul.
John
Posted by Paul Hoad from 212.2.17.129:
A bug in the name writing code cause tracks not to load.
I removed it as I couldn't find the bug
I'll try to revisit some of this code soon
Paul
Posted by Mal Ross from 195.92.194.15:
Hi all,
This is really just a request for any information and/or suspicions you may have
about the meaning and use of the two "Untextured colours" found in every
texture. I'm almost certain that the current meanings assigned to them in the current
JE are wrong. Rather than being colours for transparent and non-transparent textures,
I think they might simply be the two most-often used colours in the texture.
I've been looking through a number of the JAMs that came with the original game and
they seem to support this idea. However, the thing that really puzzles me is when
does one get to see the second of these two colours in the game? The first of the
two (the one currently named "Solid" in the jam tree)can clearly be seen
in the game by just turning off textures. But when does the second colour get used?
Perhaps only when the texture is applied to certain types of surface? Perhaps only
on certain types of object?
If anyone has any information they think might be useful, I'd be very interested
to hear of it. If you have any supporting evidence for your theories, that would
be great, too. As it stands, this aspect of the editor is quite misleading and I
want to correct it.
Thanks,
Mal.
Posted by Paul Hoad from 194.201.70.97:
How about their color if texture were turn off in graphics options menu
Paul
Posted by µartijn from 195.96.98.222:
"The first of the two (the one currently named "Solid" in the jam
tree)can clearly be seen in the game by just turning off textures."
I second that. The second is perhaps used in the mirrors? Or perhaps not at all?
Perhaps it's also nice, Mall, to include somehow in the JAMeditor a list of indices
that have a special meaning in GP2. Like
164: gravel
32: sub-horizon
33: asphalt
197-203: always textured when on ribbons (did you know that?)
Any more I forgot here? Horizon?
Posted by Mal Ross from 195.238.164.184:
"The second is perhaps used in the mirrors? Or perhaps not at all?"
Well, it's not seen in the mirrors - I've tried that. I get the feeling that, as
you suggest, it might not be used at all. I suppose it may have been something that
just didn't get implemented before the game was released.
As for your suggestions on the 'special' texture IDs, that sounds like a good idea.
However, I don't want to get your hopes up too much, as I wasn't really intending
to do much more work on the JE.
Mal.
Posted by addie from 194.191.82.13:
martijn, could you explain the 197-203- subject a bit more ? you mean in the gfx
setup you set “ribbons untextured” and the textures id 197 - 203 show up anyway ?
Posted by µartijn from 195.96.98.222:
Correct, this is because these indices are used for the trees, and would look pretty
ugly without texturing.
When you would use this indices however on a bank or verge or whatever, it would
be possible to switch off the texture for that location.
Posted by Fat Rat from 209.53.102.41:
Hi All
It's one of the number of stock rerseverd Id' ranges in anyone track jam set ,
IE 26 -36 is standard ads , billboard objects , D& F&trees & Id2 id range
, Fences & tyre bariers Etc .
T_monles .
You will find a range for most common buildings . It varies bit . SOmetimes they
ran out of canvas space & had to place an Id's on the next jam , or space left
over on another , etc,etc, Pit building especially follow this .
As for the list it's been made many times , I'd consider them on the un useable list
. TE
Or rename the list default assignments , ???
the usual 113 114 , 15 16 17 , 35 35 , 2 , 5 6 7 8 . ETc
When I work a track , I try and keep all these groupings in tact , SO when doing
my jams ,
I put all my grass texture onto standard grass jams ,
Ads onto ad jams , tress onto tree jams I don't use them for catch fencing ads ,
Building textures onto building jams .
I still use only one editor's jam folder, I'am trying to build a libuary of totally
intercahngeable jams , objects , on standard assignments .
SO I can reuse the same gpo's & jams in all my tracks . Then be able to rewrite
jams at will , without having to retexture all my standard objects in all tracks
.
Addie as far as any ID showing up without an assignment, there no consistencey ,
Like some of the preload jams do some don't roadsigns or Ftress
DProad doesn't either does the sky , for some strange reason , leave it out , You
have a very quick night track .
CU
Les
Posted by addie from 194.191.82.13:
les, i’m sorry i cant follow you. “...as far as any ID showing up without an
assignment, there no consistencey “
??
what assignement ?
“DProad doesn't either does the sky , for some strange reason , leave it out , You
have a very quick night track .”
in the meaning of the conversation between martijn and me, sky DOES for sure. if
you go to the gfx setup of gp2 and disable skytexture, then skytexture IS disabled
and does not show up.
so there must be a misunderstanding somewhere. les ?
and the night track (i assume you mean bern-grauholz, nightriders version) is just
a palette trick. its about the regular grauholz with some (local-)palette trick ...
Posted by Fat Rat from 207.194.18.208:
HI All
When I mean an assignment. I mean either a jam that is loaded into the jam tree in
TE . ( Not a preload ) but one that is in the tree by choice .
Or a scenery difintion or a 188 cmd . Something that shows up in the TE which is
not a hard wired code.
This is why I used the ski as an example . it's not in the preload list , and there
is no scenery definition for it.
If you don't have it in the jam tree , the game will have no sky texutre to map,(
by hard wire ) even if the ski texture is switched on you get a black ski .
Just like when no # 32 texture present. Both of these texture may have no assignment,
but if present will automaticly appear in the game on it's hardwired location.
In the test track , texture 32 does have 2 assignments . 2 scenery deffinitions to
banks 18 19 . but there is no banks built . Texture 32 shows up mapped onto something
( the world ) So you could take the 2 definitions and this texture will still be
mapped if present . (without any assignment)
Obviously these 2 examles would not invole any objects.
What I ment about consistency . refers mostly to the preload list , You would think
that much like roadsigns , stands crowds , dproad , and ski . would all be in the
preload list .
But only roadsigns are in . So I don't even have to have roadsigns in the jam tree.
but the textures are available in the game, But I need to have the clouds in the
tree to be available in the game .
You would think that any track would have ski & groud and roadsigns , but GP2
only thinks that Roadsigns are to be loaded .
Again some jams & textures are available in the game to default locations , without
being in the jam tree , While other more obvious standard textures & locations
are not available even when in the preload list ( D&Ftrees , cliumps bushes)
And still other more important textures are not even in the preload list , even thought
they ( Have to) be present for the track to work and have hard wired ID assignments
( defaults )
CU
Les
Posted by Iso-Hannula from 195.197.160.42:
Command 0xB7:
2 arguments.
a1: not used (?)
a2: pitlane start height (gradient)
This height value is very strong. Value 10 gives about 20 degrees. I don't know more
yet.
Posted by Iso-Hannula from 195.197.160.42:
Command 0xCC:
3 arguments.
a1: unk (nothing)
a2: unk
a3: distance to horizon OR horizon scale factor
So a3 "zooms" horizon. I found that the default value (no 0xcc commands
on track) is between 600-650. It's hard to know exact value. Maybe 640.
Low values make horizon smaller and high bigger. If used 0, there is no horizon.
And 1280 (or near) dublicates the size of horizon.
Posted by µartijn from 195.96.98.222:
Isn't that what we had hoped for!! Some nice snow-covered mountains in the distance.
Now, you have to stop Unk-chasing, Iso-Hannula, or I'll have to redo all of my tracks!!
Posted by Iso-Hannula from 195.197.160.42:
Commands 0x8C and 0x8D:
2 arguments.
I didn't notice any effect, but the number of arguments is 2. Not 1 as said in cmdlib.
I believe what FA has said (in cmdlib),
"there are in fact nothing (just a plain return [in the code])"
I haven't seen in the code, but I have just tried it in track. With 1 args, track
is crashed, when loading, but with 2 args is works fine.
Command 0x93:
2 arguments.
Effect is ?. I think it has same kind of effect as 0x90, 0x91, 0x92, 0x94 or 0x95.
Because all those are unk. Probably it is connected to 0x92.
In cmdlib is said about 0x92: "possible scenery". I tested this cmd with
"no-scenery" track, so I can't say. But it is possible, too.
Commands 0x9C and 0x9D:
1 argument.
I didn't notice any effect. I think that those two commands are used in the pitlane
because cmds around it are. Maybe first for entrance and second for exit of pitlane?
Or one for left side pit and other for the right side?
Command 0xA5:
1 argument.
In cmdlib: "this sets a bytevalue within gp2.exe" (FA).
What is this bytevalue? Well maybe it sets some bytevalue, but does it have effect
on the track?
Command 0xAE:
Totally mystery! I couldn't find the number of arguments. First it seemed that it
has 2 arguments but no, 7 worked, but it made the track heights messed. I think that
this command has sometimes been, but it is now totally out of use.
Commands 0xB1 and 0xB3:
2 arguments.
I thought that they have same kind of effect as 0xB2, but I didn't notice any effect.
I used it with poor track (no scenery, no track markings, not many objects), so all
effects may not be seen. But I believe that both have some effect!
Commands above 0xE0:
It has been said that there are no commands. But I tested:
Commands 0xE1, 0xE2, 0xE3, 0xE4 and 0xE5 are valid. With 1 argument. But at least
they have no visible effect. But cmds above 0xE5 are not valid. I tried those with
args# up to 4, but GP2 crashed every time. So I think that 0xE5 is the very last
command that is described in gp2.exe. 0xE1 - 0xE5 are described, but it is totally
different matter, does it have meaning.
Command 0xFF
is used (as said in cmdlib) to mark the end of data. It has (as known) 1 argument
which is 255 when data is at end. Some kind of "closing command".
Posted by Bob Culver from 192.246.108.35:
I have a theory concerning the 0x94 and 0x95 commands; and possibly the others
in the sequence.
The CC's find their way around the track by the cc line. Yet, cc's pass each other
and fly off the road, so they are not always on the cc line. CC's in the pit lane
are another example. Paul has been struggling with the cc line, because it is tied
in with the track. THERE MUST BE A REASON.
My Theory. There is likely a default distance that the cc's can wander away from
the cc line and still be on the track. This must also be tied into the track width.
Most (I don't know if all) of the original tracks have many 0x94 and 0x95 commands.
Possibly these redefine the distance that the cc can wander from the cc line. I have
noticed that tracks created with the TE where these commands (and possibly some of
the others) are removed, that the cc's seem to fly off of the road at a much higher
rate than the original circuits. I may be wrong, but there has to be something that
lets the cc's off of the line (which is noticed on banking and curbs that they hit
when they are off of the line) but keeps them on the track. The fact that all of
these commands can be removed leads me beleive that there must be a default, but
the higher rate of cc crashes (which is really evident on C-F which has more than
50 corners) leads me to this conclusion.
Posted by Richard Selby from 195.92.197.40:
Same idea as Bob, but maybe one/two for pit lane? I remember Rio (?) being a pain
in races which involved cc-cars pitting, as they came off at the final corner and
crashed.
Just an idea someone might like to try.
Posted by jason hope from 209.104.76.93:
could somebody direst me towards pictures of circuit gilles villeneuve from 1980
to 1982 please?
thanks,
Jason
Posted by Andrew D from 209.233.55.203:
Try the FORIX site, they have a lot of pictures. Search for the circuit and then
the year, its pretty easy to navigate, but that probably the best place i can think
of.
http://www.forix.com/asp/f1.asp?lang=english
Cheers
AKD
Posted by William Dale Jr from 203.29.142.131:
On the subject of pictures, does anyone have any good ones of the Adelaide GP Track
or of Longford?
Posted by Fat Rat from 207.194.18.133:
Hi All
Been reading the discusions ,
I agree that there is something controling the CC off the start grid , But I don't
think this is it .
I've looked at couple MP track for this cmd ,
07 & 12
12 being the base for Kent Hills & 07 is the base for the Dart track which is
the base for Westwood.
Both tracks have these cmds spread through out the track .
with a wide range of values for each arg :
4,1795,0
8,2,0
7,1024,7
7,16364,0
0,16896,2048
and in TS 55 of 07 we have 3 of these cmds in 1 section . with these values .
1,-1,-1
2,-1,-1
3,-1,-1.
In 12 (monza) TS 61 there are 2 in one section
19,-1,-1
22,-1,-1
Both of these track sections are at the end of long straight sections , heavy breaking
& down shifting areas , most other appearences of this cmd with the values 1st
listed are at corners ,
Maybe a kink in a straight away , or a small bend and not needing any appearent reason
to downshift .
So it's likely a cc corner & breaking and downshifting cmd .
Thoughts ?
Les
Posted by Fat Rat from 207.194.25.103:
Hi All
Boy I was looking at the wrong tracks for this cmd .
CHeck out 01 TS 42 & 100 . and 02 TS 29 . It has 9 0xd0 in sequence .
And NOT ONLY downshifting breaking areas , but also coming out of corners accelerating
areas.
CU
Les
Posted by Bob P from 24.67.94.91:
Here is something I have noticed while working on this one track of mine lately.
There is a rather tight corner very close to the S/F, and even closer to the end
of the pitlane. The pitlane is on the left. What happens is the car is forced to
stay left for a while after rejoining the track. It causes the cars trouble when
trying to corner, as they want to stay left; and the corner is a right-hand corner.
Is there a way to make the car "join" the cc-line sooner after it leaves
the pitlane?
I have already moved the pitlane a fair bit. Originally I had it rejoin after the
corner in question, but then there is a large sweeping corner just after that, and
it caused the car to go straight before joining the corner, nearly hitting the right
side wall.
I guess then, what really seems to happen, is the car is forced to stay straight
for a while after leaving the end of the pitlane. Is there a way of shortening the
distance it wants/needs to do this?
Or should I just move my pitlane to rejoin at a different place?
Bob P
Posted by µartijn from 195.96.98.222:
You may try to use a different SLOT number (f1ct16 instead of f1ct05, or whatever).
CCar behaviour in/out of the pit seems to be related to the slot number.
Please try it, and report whether it makes any difference, and which slot#s failed/were
useful for you.
Posted by Bob P from 24.67.94.91:
You're right Martijn, the slots made the difference. Even though I was testing the
track in its original slot, it needed to be elsewhere to suit my needs. I found that
it worked, to suit my track, in slots 7, 12, 14, and 16; almost worked (that is the
CC-car joined the line in the middle of the first corner) in slots 1, 4, 5, 6, 8,
9, 11, and 15; and it completely missed the corner, almost hitting the fence in slots
2 and 10, and almost (oh so close) made it in slot 13.
I probably should have known about this, it isn't like I have never read the forum
before... oh well. Thanks for reminding me.
This also means I can use either of my pit set ups...
Bob P
Posted by Fat Rat from 207.194.18.133:
Hi All
I saw the 148 detail level code in TE 1.86 .
But it now has a small bug , sometimes when you 1st open this dialog box , the numeric
code and the text label don't always match . Not just with the new 148 , but also
with other GP2 original codes.
Once you hilight & select. the codes & names will match up again . Other
values I've seen are 3(house),128(marshall bl flag),130(crowd), 132,(marshall&arrow
sgn)148*(Pit crew),192(shadow).
I'd imagine 192 is for objects inside the track markings ??
CU
Les
Posted by Paul Hoad from 194.201.70.97:
Certainly all shadows at SilverStone and Japan
have 192 as their level
interesting to know if
we could make other objects
that could be used as floor markings
perhaps we could add patches of water,oil etc as objects rather than as texture modifications
Paul
Posted by Fat Rat from 207.194.18.94:
Hi All
Reserved\hardwired offsets or Id1’s in GP2’s object and defs. lists
The object list starts at 17 because 0-16 are reserved for the 0-16 of the defs.
list , most of the common GP2 objects .
I take it the object list size or offset ( whatever ) starts at 17 and the startlight
offset config, merely sets what number the lights have to be for the switch to work,
then beyond that is open again , till you run out of total space ??
Now in the 0-16 in the defs. list are all ( but one ) GP2 defined ID1 objects , By
this I mean Like Ftrees objects , Objects that are used in one of the 1st 17 selections
in the ID1 drop down box and an ID2.
Remember 0-16 , I bet you could rearrange the order of these objects by editing the
parameters in the object definitions ID1 & ID2 ,
(oneday) and would find much like the start lights , that the marshalls & flagmen
must be at specific offsets in this list too , for the animations to work ??? .
Hey guys in doing research for this posting I found an octagonal gpo with a roof
. HEY HEY .
The Westwood roundhouse should now have a real roof on it , I think it’s upside down
right now . But that’s should be no problem .
Though I haven’t touched any of my projects for almost 2 weeks now . and all of a
sudden I’ve 4 going at the same time, Been tied up doing unk chasing , TE testing
and advanced object management , editing discussions .
I’ll have to get back to work on some of my own projects again , I don’t really mind
but it seems I can not manage to both at the same time.
Some food for thought .
In the 0-16 defs list.
Meter signs are 13 GP2 defined
Arrow signs are 1 GP2 defined
Pit Crew are 4 Gp2 defined
Black Flag are 6 GP2 defined
Blue flag are 7 GP2 defined .
And we know some of the 5 GP2 definitions
I think one of these in the 1st 17 of the defs. list,points to Gpo ID1 17 , maybe
not 17 but one GPO’s in the object list (Not the st lights)
HAve fun
Les
Posted by addie from 194.191.82.13:
hello
i’m afraid 0xd0 definitely has nothing to do with cc-cars nor lines. several sources
confirmed my suspicion its rather some scenery cmd (yet to de-unk).
nevertheless i 100% share the oppinion, there have to be some track specific, even
track section specific additional info for the cc-cars, beside the cc-line.
as you may imagine, cc-car coaching was for sure already necessary in f1gp. thanks
to paul hoad we can have a look at those tracks of f1gp and there we see we have
track commands from 0x80 up to about 0xac. (no 0xd0 yet.)
so i inspected original tracks of gp2 and f1gp in order to find possible cmds and
rules for them. now i have the strong suspicion 0x94 and 0x95 are cc-car coach commands
!
these cmds look like setting up how the cc-cars do act on both side of the cc-line.
maybe they define how strong the cc-cars are supposed to follow the cc-line, something
like that. low values for a2 would mean strong, high values mean lazy. common values
seem to be 1 to 16. 0x94 is for left side, 0x95 for right side of cc-line. at least
when looking at the original-tracks, and where and how those cmds are applied, these
thoughts seem to make sense (to me).
then i made tests with the notorious 1st corner of bern-bremgarten. i inserted 0x94
and 0x95 with args 1 in several distances before the corner in order to force some
“lining up” of the cc-cars before they make the corner. to make it short: they did
not really line up, but nevertheless they seemed to have become somehow more careful
or at least less fragile ! believe it or not, the number of heavy crashes decreased
significantely ! although there still were airbornes from time to time. (hard to
100% avoid in that corner :)
i only made about a dozen starts with regular and new bern-bremgarten each, because
it already was late in the night. so more tests will be necessary before these thought
may be really confirmed. any volunteer ?
(btw beware: a2=0 hangs gp2!)
more: looking at the original tracks and making tests with monaco (mirabeau), adelaide
(hairpin) and bern-bremgarten (1st corner) leaded me to the oppinion cmd 0x92 could
be another cc-coach-cmd. my impression is pretty vague, but nevertheless it seems
obvious. with a 0x92-effect, the cc-cars seem to keep more distance to each other.
it could be viewed in the adelaide hairpin and in the 1st corner of bern-bremgarten
again. arguments: a1: offset (as usual); a2: effect-distance; more tests were necessary.
(again) any volunteer ? you may want to make screenshots and compare. also high mounted
onboard cams are advantegous.
between 0x92 and 0x94/95, there is yet 0x93, not used in original tracks, but who
knows ?
i’m aware these descriptions are pretty vague after all. to me it looks obvious although
i cant confirm 100%. it lays in the nature of the subject. the AI of gp2 makes the
cc-cars pretty independent and those cc-coach-cmds may just make a “rough” input.
nevertheless i hope, experiences of other people may confirm these thoughts and so
i hope its useful info.
addie
Posted by Paul Hoad from 194.201.70.97:
These commands have been present in too many of the
original tracks for them not
to be of some use!
I like your ideas about the commands and think that further experimentation
might prove this.
As an aside I often find
tracks where CC cars often
slow when they really don't
need to.. i.e corner some way
away
if you want to look at strange places for 0xd0 look
at t10 at imola!
Paul
Posted by Fat Rat from 207.194.25.172:
Well
I haven't seen any confrimation on anything .
It didn't change the scenery and did change the CC behavor .
I've removed all 0x94\95 in many tracks & made no disernalable dfiference to
CC's
CU LES
Posted by Bob Culver from 206.173.174.213:
Take a look at Spa. The 0x94/95 commands all have small values (1 or 2) at the beginning
of a corner, and larger values (usually 8) at the exit of the corner. I did try this
on several sections of Clermonts where the cc's always fly off the road, and it did
not seem to help. I am not giving up though, and will try this in slightly different
iterations.
Posted by addie from 194.191.82.13:
paul, you once mentioned, 0xd0 could prevent scenery-ribbons from flashing. looking
at t10 of imola could confirm this. (i did not test. just look at the track in the
TE). a2 of 0xd0 was said to be loc code type A (then i made it type D in the latest
cmd-lib, which is probably wrong!), so lets take type A. in t10 of imola a2 in most
0xd0 is 2048, looking at loc code type A gives “ribbon 4” which is the first to the
left. remove the 0xd0 in t10 and watch what happens to the forrest to the left in
tamburello when passing by. i looked at the two corresponding 0xb8 cmds in the TE
and noticed, ribbon 4 will be slightly “warped”, so it will tend to flash, as we
noticed earlier. maybe really 0xd0 prevents this !?
just guesses, as i dont have time to test in this very moment. any volunteer ?
addie
Posted by Bob Culver from 206.173.174.213:
I will test this. Now that Clermont is well into scenery, I have plenty of flashing
ribbons to tame. Hopefully this will help.
Posted by Fat Rat from 207.194.18.170:
Hi All
Some help for objects & number of cmds management , I noticed alot of tracks
, with Objects ( GP2 defined 5 ) ringing tracks and using 100’s of cmds to do this
.
Mainly objects like street lights , telepoles , flags etc. The same objects placed
over & over at equal distances around the track . I found it fairly easy to convert
a complex object . Complex objects being those objects in a bunch or group .
I changed a complex object , a group of 8 different trees . Into a row of 8 tele
poles , With using these types of objects you can place 80 poles with only 10, 128
cmds . Reducing by 90 % the number of 128 cmds needed to place telepoles .
Still working on how the no 2 objects at the same place in a TS , applies to these
complex objects . I think there is a little more latitude , in this area when dealing
with these complex objects .
As opposed to 2 gpo’s placed at the same spot in a TS .
CU
Les
Posted by addie from 194.191.82.13:
hello
0xd0 definitely is “scenery”-cmd. i’d call it “fix texture”-cmd, as it fixes, as
i guess, two ugly things at once. with a2 you select the location where you have
to fix a certain uglyness, with a3 you define the locations where you have to fix
another uglyness. the latter probably is the “flickering texture problem”, the first
looks like a “texture shift problem”. the “bad” news: it looks like we have ANOTHER
location code (type F; not yet fully discovered).
to see what i mean, do this:
a2) (the hint of paul was primary class!) take the original imola track f1ct03.dat
and prepare two versions. one untouched original, and on the other one do remove
all 0xd0 in t8-t10. then prepare a savegame where your car is positioned at the end
of the yellow pit lane marking. now drive both versions and keep your eyes open,
all textures on, etc. watch the forest to the RIGHT side in the tamburello corner.
this is the “texture shift problem”. (btw in the untouched version its not 100% fixed
anyway; norman was maybe a bit lazy here; good job anyway:)
a3) for this experiment (and others also) it is advantageous to have a high mounted
onboard-camera (z maybe 1000 or more) to have a good overview.
take the original estoril track f1ct13.dat and prepare two versions. one untouched
original, and on the other remove all 0xd0 in t29-t32. its the tight corner after
the fast infield straight. watch the outside of the corner, especially the (right)
bank. there its “flickering texture problem”.
and probably 0xc7 has a similar meaning but with other “uglynesses”.
i hope its useful info
addie
Posted by Bob Culver from 192.246.108.36:
Addie, could you be a bit more specific on what you mean by location. I have tried
this without success so far, so I am probably using the wrong values. I noticed the
sequence in Imola and also spa has the same A3 value, but incremental values for
A2....5, 10, 15.
Posted by addie from 194.191.82.13:
bob
i had not time to figure out the full location code type F yet. in imola i noticed
2048 is ribbon 1 (or maybe “first ribbon to the right”) and in estoril i noticed
4096 is right bank. when looking at more original tracks i noticed the whole unsigned-range
of values so far from 2 upto 65535 for a2 and a3. as a next try i’d suggest the latter
in both a2 and a3.
which location is affected in clermont ?
Posted by Bob Culver from 206.173.161.212:
The 0xd0 command is successfully taming my flashing ribbons. So far, I have only
been able to get the flashing right bank ribbons stabilized by using a series of
0xd0 commands as seen in Estoril and Imola.
The A1 value is the offset value. The number of 0xd0 commands required appears to
depend on how sharp the turn is. for Imola, the series increases by an A1 value of
5. So if you had a ribbon 30 segments in length, you would need 7 0xd0 commands spaced
by increments of 5. For Clermont I am repairing the outside of a fairly sharp turn
and have had to a have series of 0xd0 commands that increase by 1.
The A2 value seems to be (as best I can tell so far) related to the angle of the
ribbon to the track. I have used values from 128 to 16348 for this, and in my case,
the higher values seem to cause the top of the ribbon to become closer to the track
(so the ribbon becomes almost perpendicular for an instant). My ribbon at this point
is sloped more like 30 degrees, and a value of 128 seemed to do the trick.
Of course value A3 was set at 4096 which Addie has already determined is the right
bank. In one area, I was able to repair the right bank ribbon, but then ribbon #1
started flashing. I am adding more 0xd0 commands with a shorter A1 spacing, and it
seems to be working.
I am now searching for the other ribbon command. It would be logical to assume that
these are in the binary series that we are seeing for everything, however it is odd
that the right bank would be 4096. Perhaps This command is not needed for ribbons
such as roads, and verges, so those were not assigned and an entirely different sequence
was used.
I also have a lot of flashing fences, so I will try and determine if this works for
fences or if the 0xd1 command is for those.
Posted by Bob Culver from 206.173.161.116:
2048 is definately the left bank.
Posted by Bob Culver from 206.173.174.248:
Using the 0xd0 command to stabilize a right bank ribbon caused the number 1 ribbon
(location 11) to flash severely. Adding an 0xc3 command in this section solved the
problem. I have not discovered exactly how it works, or what the significance of
the values are (A1=0; A2=6; A3=6); but using the same values as found in a similar
circumstance in Spa solved the problem. I still have many locations with flashing
fences, so there is still a lot to be discovered about these commands.
So far, by using the 0xd0 command with an A3 value of 4096, the right bank ribbons
are stabilized as mentioned before. Similarly using 2048 stabilizes the left bank.
Many original circuits also use 6144 for the A3, which may be stabilizing both banks.
It also seems that the 0xc7 command may have an influence in this area as well. In
one case, I have added this command with similar values, and the ribbon seems to
be stabilized more consistently. Also, the A1 value is confirmed as the offset into
the sector. The number of 0xd0 commands required and spacing depends on the length
and degree of the turn.
Further research is required to fully understand these commands, and what the values
are specifically, but the purpose of these commands seems to be clear now.
Posted by Bob Culver from 206.173.161.151:
I have now been able to eliminate flashing fences using this command. Again, the
A1 value is the offset into the segment; A3 is the location. Right fence value is
-1 and the left fence is 1. At least those are the values I used to stop the flashing.
In both cases the A2 value was the same as A3 (-1 and 1 respectively).
As with the flashing bank repair discussed last week, a series of these commands
is needed. In many cases, stepping the A1 by increments of 1 are needed. So you may
need 4-6 of these in a row to do the trick. That is how it is done in the original
circuits, and i have now discovered that is does work. Clermont know has no flashing
fences, and only a couple of flashing banks that should be repaired soon.
I have also tried using the 0xc7 command for this, but it seems to have some other
purpose. Many of the values seen are consistent with the scenery location a values.
Assuming that this is correct, the values used seem to point toward a bug repair
usually found inside of a turn. I removed many from the original circuit during testing,
and did not notice a discernable difference.
However between the 0xd0 and the 0xc3 commands, just about all of my scenery bugs
have been eliminated. As best as I can tell, the 0xd0 seems to be some sort of ribbon
adjuster, but exactly how isn't totally clear.
Posted by Dan C. from 142.58.124.44:
I've been fooling around with the 0xc5 a bit and I found that the unk argument a5:
(the first of the 4 unks) works basically the reverse of a4: (using code type D).
What I mean is that a5 also uses Loc type D but it 'turns off' the places you want
to see instead of on. For example: You have a value of 244 in A4, which basically
turns everything on the other side. Now, if you have a value of 16 (road) in A5,
everything will be on except the road.
So, maybe it is just another way of turning off/on locations.
Dan C.
Posted by addie from 194.191.82.13:
dan
i’m glad to read you noticed an effect when changing a5. have you also tried to set
a4 to 228 (everything w/o road) and then set a5 to 16 ?
Posted by Dan C. from 142.58.213.83:
Not yet, but I will try.
My suspicion is probably the same as yours. Just another way to switch things on/off.
Posted by Dan C. from 142.58.124.1:
I tried the opposite i.e. trying to switch road 'on' with A5 when it was 'off' with
A4.
A5 is not able to switch anything on.
So the conclusion: A4 switches on, and A5 switches off whatever A4 switches on.
I don't know why the redundancy, but maybe the Microprose TE uses check boxes to
turn on/off the scenery, and this is just makes things simple in terms of calculations.
PS, what were the unks that were supposed to be like swivel arms of view? Were they
A6 and A7? I think Bob was looking into them a while back.
Dan C
Posted by addie from 194.191.82.13:
last night i checked the “subhorizon”-subject of fat rat a few postings ago. and
i’m happy to confirm it ! les, well done !!
so if you want a sane track as far as black horizon or black stripes at the horizon
are concerned, you simply have to include in your list of jams a texture with id
32 for the general underlay in the gp2 world, and a texture with id 116 (thanks again
les !) for covering possible black stripe between horizon and underlay.
i hope its useful info
Posted by Paul Hoad from 194.201.70.97:
I'll add Black Horizon II test into the Sanity check
Paul
Posted by addie from 194.191.82.13:
of course these textures are only necessary if there is free view to those areas
in your track. if your track is situated deep in the forest with trees allover, like
e.g. hockenheim or monza, then you do not need them textures. but if you see the
black horizon or black stripe, then you need them.
Posted by Paul Hoad from 194.201.70.97:
Well as the sanity check is there purley to hint at possible problems then anyone
seeing their track fail becuase of those test will
probably investigate them
as long as we document this then it should be clear to people why there is a problem
Paul Hoad
Posted by Olivier S. from 195.238.6.30:
Hi
These are what I have found about these commands:
1. 0x9A (known as "Left fence height change?"):
After making some tests, I have found that this command is not a normal Change Fence
Height (and A3 has nothing to do with a transition lenght) but should be renamed
"Define Custom Fence Height" or something like this.
Here is the explanation: this command allows to set a custom fence height size for
a certain height unit. This is a bit hard to explain so here is an example:
If you put a 0x9A command with A2 = 2 & A3 = 100, then when you put a command
0x98 further in the track with 2 as fence height, it will have actually 100 as height
size, which equals to 0,5 "normal" fence heights ! (1 normal fence height
is 200)
I could verify this by looking into F1GP tracks with the new editor (thanks Paul,
it's great, but the game crashes when I try to insert/delete a command) and you have
a perfect example of the use of this command in the Monaco F1GP track: as there was
no way to make a scenery like in GP2 in F1GP tracks, they used a combination of 0x9A
and 0x98 to create things like the Massenet Hotel (A3 of 0x9A = 1280 = 6.4 fence
height) and the big wall at the left after the Loews (A3 of 0x9A = 3200 = 16 fence
height). They could have used normal 0x98 with A2 = 6 and 16, but don't ask me why
they did that, neither why it's used in the GP2 Barcelona...
Note on A2 values of 0x9A:
It works like this:
- values from 1 to 8 to be used with 0x98
- values from 9 to 16 to be used with 0x99
- values from 17 to 24 to be used with 0x98
- values from 25 to 32 to be used with 0x99
etc.
Note that if you use values like 1/17/33/etc. for left fence or 9/25/41/etc. for
right fence (which all equal to 1) in one only command in the track, this will redefine
the default fence height for the whole track to the number specified in a3 (with
100 we could have 0,5 default fence height), but this won't work on a relative basis
(if you then put a number like 2 in a 0x98 without defining it with a 0x9A, it won't
calculate that it is (0x9A A3 * 2)).
but it seems also that values from 9 to 16 used with 0x98 will change the height
of the fence, but not following the custom height defined in 0x9A (it works like
9 is 1 fence heights, 10 is 2, etc.), and using values from 1 to 8 with 0x99 will
change the right fence height following normal fence heights.
Finally the transition lenght between old and new fence heights seems not to follow
the normal rules. (it seemed to me it's fixed, but I can't figure out what lenght
it is).
This is a rather strange command...
2. 0xAC
Command 0xAC is a colouring command from F1GP:
There are often two 0xAC in t0 of F1GP tracks. When they are two, the first controls
the grass colour and the second the tarmac colour. I don't know exactly how the arguments
work so I can't say why one controls grass/tarmac. I think it's related to colour
palette (I tried to set A3 or A5 to 255 and it gives nice green colours :-).
(btw F1GP colour palette as shown in some cars editors always seemed strange to me:
512 entries?)
This command has been obsoleted by the new 0xC9 but it is still in t0 of many GP2
tracks, although it doesn't works anymore, even if all the 0xC9 are removed.
Filou
Posted by addie from 194.191.82.13:
filou
so in some cases 0x9a has redundant meaning !? if you have a3 in 0x9a of 100 and
in 0x98/0x99 set the height to 4, then this is equal to have a3 in 0x9a of 400 and
the height in 0x98/0x99 of 1 ? could you notice maybe a difference in how the textures
get mapped afterwards ?
maybe a3 could be called “Define fence height multiplicator” ?
did i get it right: the “height multiplicator” can be redefined again allover the
track ?
Posted by Olivier S. from 194.78.242.114:
Hi
the 0x9A does not define the default fence height for use on a "multiplier"
basis. It's more a custom height: the value you set in A3 of 0x9A will be the effective
fence height when you set the same value in A2 of 0x98/98 as the A2 of 0x9A. This
is useful only if you want fence heights that are not integer (for example a height
of 1,5).
I have tried that thing you mention in your example but it doens't work on a "multiplier"
basis.
(if you set A2 & A3 of 0x9A at 1 and 100, as you say, and put a 0x98/99 with
4, it won't put 400 as fence height, but normal 4 fence height which correspond to
800)
Concerning the textures, I didn't find something special but I noticed that the transition
lenght between the two fence heights seems to be fixed to a certain value. I didn't
make extensive tests with this command, and the things I explained in my previous
message are everything I have found.
However, perhaps there's something relating to the textures, such as a method to
fix the "big height-fence distortion" bug seen in some tracks...
Filou
Posted by addie from 194.191.82.13:
filou
just to make sure i got it right: when i e.g. set 0x9a a2=2 and a3=65 then i get
with 0x98/99 the following heights: 1 gives 200, 2 gives 65, 3 gives 600, 4 gives
800 ?
you mentioned “Note that if you use values like 1/17/33/etc. for left fence or 9/25/41/etc.
for right fence (which all equal to 1) in one only command in the track, this will
redefine the default fence height for the whole track”
so, if there is a single 0x9a somewhere in the track defining some custom height,
this height is set for the whole track ? it cant be redefined again later in the
track ?
"Define Custom Fence Height" seems to be a good name !
addie
Posted by Olivier S. from 194.78.242.104:
Hi
You got it right.
For the "height 1" default height thing, I meant that a value of 1 in a
0x9A automatically changes the default height for the fences (if there are no 0x98/99
in the track) as it is always 1 in GP2, but you can put many 0x9A with the same A2
in one track, and the 0x98/99 will use the last (I think I didn't explained this
very well).
I think the best way of using this command is the one used in the original tracks:
insert the 0x9A just before using the 0x98/99
Filou
Posted by addie from 194.191.82.13:
i noticed it doesnt matter whether you insert 0x9a in the track or in the pit lane.
the new height is valid globally anyway. and you can set each height-index only once
per track. inserting 0x9a with e.g. a2=2 twice is useless. (but i could not figure
out a rule for which one of the two 0x9a will be valid)
but you can insert several 0x9a for several "height-indices".
Posted by Paul Hoad from 194.201.70.97:
does it matter if you use the index you defined in 0x9a in a 0x98/0x99 before you
actually get to the 0x9a that defines it!
Paul
Posted by Fat Rat from 207.194.18.206:
Hi Guys
Can you expand on the left right , coding ,
I was playing around with the unk1 on this , maybe a transitions length( trailing
I think ) I know I've fallen into a very nice long gradual transition before, What
happened was likely a 0xc9 was still in from the base track & I happened to set
a fence height to match .
But I could not sort out left right , or other values . And have seen other longer
transitions , even in my own tracks , but can't seem to control , move or replicate
them .
I was also looking mostly at left fence effects , wouldn'd make scence for only one
side & not the other .
Of course the transition effect I think follows the same indexes naming system
Thanx Les
Posted by Fat Rat from 207.194.18.206:
Hi Paul
A bit confusing , you are meaning, the oder in which the cmds are palced in the track
,
IE a 0x97/98 in ts 1 and a 0x9a cmd in ts 5 .
Will the cmd in TS 5 effects the height of the cmds in ts 1 ??
Or asking weither the values have to match in 0x9a & 0x98/0x99 cmds ??
THanx Les
Posted by addie from 194.191.82.13:
the “height value” of 0x98/99 actually is just an index to a table with the actual
height values. default figures are (as found by filou) index 1 is 200, index 2 is
400, index 3 is 600, etc. regular valid indices are 1 .. 8, if you set 9, you again
get the same as with setting 1. so 1, 9, 17 etc. is the same (see filous post). setting
0 is the same as setting 8.
now with 0x9a you simply replace the values in this table. globally. with a2 you
indicate which value to replace, with a3 you set the new value.
as for the question of les in an earlier post: its a bit tricky to explain. actually
there are two of them tables. one for left side (for 0x98) and one for right side
(for 0x99), but we just have one 0x9a “define custom heights” command. so we need
a dirty trick. remember index 1 is the same as index 9 as mentioned above ? here
comes the dirty trick. if you set in 0x9a a2 to 1 you set the custom height for index
1 in the left table, if you set in 0x9a a2 to 9, you set the custom height for index
1 in the right table. see again former posting of filou (all credit goes to him !)
les what trouble were you refering to, could you be more specific ?
Posted by Fat Rat from 207.194.18.153:
hi Addie
"les what trouble were you refering to, could you be more specific ?"
Well not really , was referring to the order of the indexes .
Just noting that in some cases GP2 has trouble sorting some stuff out. 2 identical
GPO's , some cmds have to be certin order in a TS .
Some of the way things are drawn . etc. ( very general stuff .)
Lastly , a 0x97/8 with a 0 value , did not work when I tried ( TE ) 1.72 likely .
I was trying for a 0 height . I think it crashed , it may have been because I had
no 0x9a definistion for a 0 index.
i'am not that concerned with "custom heights" of fences.
Transition length would be much more useful , even if just using standard heights
CU
Les
Posted by addie from 194.191.82.13:
transition length is determined by the predecessing track sector. if youi want a
transition length of 2, make the predecessing track sectors from a length of 2. (see
command library)
Posted by Bob P from 24.67.94.91:
Has anyone figured out how far cameras end up, in feet or metres, from the track
based on the distance from track? For the first time I am using an underlay bitmap
to not only build my track, but also to place cameras as realistically as possible.
The thing is, while I thought I had placed it atop a building near the track (that's
how it appeared in the TE), it was actually atop the fence, or thereabouts. At the
least, (to Paul) is it possible to have a more realistic camera placement shown in
the TE?
Posted by µartijn from 195.96.98.222:
The units are the same as the width of the track, i.e. 1024 units = 4.87 metres.
So a value of 2000 usually just gets you over the fence.
I agree that the display in the TE is far from perfect. Perhaps Paul used the same
values of the ribbons?
The ribbons have a very different scale, I don't know precisely, but I estimate about
256 gives the same distance from center (dfc) as a road with a width of 1024.
Obviously Iso-Hannulla knows these scales (and the relation with the walls) more
precisely, but I haven't seen the maths yet.
Posted by Paul Hoad from 195.92.194.19:
Perhaps you could send me
a) the underlay bitmap (plus any setting you use to place it)
b) the track
c) mark on the underlay image where the camras should be and where they appear
There are still some unknowns in the cameras
Paul
Posted by Jason Hope from 207.253.223.84:
hi all,
i've been putting new objects in montreal that replace the old one's. this is not
the problem.
When using TE 1.8.7, i put in an object, save and close and re open, the objects
are not in the same place they were in when i inserted them. Another wierd thing,
is that when i go to the objects on the track, they have changed deffinitions. for
example, where i put a flyover, a stand in now there.
any clues? could it be the editior. with 1.8.8, i always get problems, and an illegal
opp occurs.
Jason hope
Posted by Paul Hoad from 195.92.194.74:
Jason,
none of this stuff work properly yet!
Paul Hoad
Posted by Jason Hope from 209.104.76.93:
paul,
i am aware that this is not a perfected area in track editing, but how come i was
able to do it in previous editors without any problems?
basically, this is what i want to know. Sorry I was not clear on the previous posting.
Jason hope
Posted by Rob Huffer from 202.137.80.194:
Picking up on something Jason was saying. I'm having trouble with the 0x80 also.
When I try to insert an object, I highlight the track segement and right click the
mouse. I choose "Insert Track Command" from the pop-up menu and continue
on with the dialogue box. The TE will then go through the motions of inserting the
object, but then cause an illegal operation fault and crash out. The only way I've
found to insert objects is by copying existing objects in the track and pasting them
elsewhere. Then I change the object to the one I require. Is there a way of fixing
the command so no Illegal Op occurs? Or if not is there a less cumbersome way of
inserting objects.
Cheers Rob
Posted by Paul Hoad from 194.201.70.97:
Rob what you have said has lead me to some problems in
the code, I'm attempting to fix this
Paul
Posted by Rob Huffer from 202.137.80.194:
No worries Paul. I tried adding objects using the Object tool.(of all things) This
appeared to work fine.
Keep up the great work
Cheers
Rob
Posted by Fat Rat from 207.194.18.68:
Hi All
Been playing with the 0xcc cmd ,
Have noticed quite a difference in the pixeling of textures , when veiwed with different
cam veiws .
IE, the hor texture and background objects look fine with a fixed on board cam ,
But some of the trackside cams , showing the hor & object textures , zoomed in
a great deal,
really close & heaveyly pixelizd , Is this mearly a matter of the zoom factor
of the trackside cams ? as opposed to the fixed zoom factor with the on board cams
?
Will I be able to alter the track side cams , so they do not show such a pixelized
veiw ? Zooming in with the 0xcc cmd only makes this worse , looks great in any other
cam veiws.
I haven't done any cams on this track yet , but now obviously have some major cam
work to do
Thanx
Les
Posted by Mal Ross from 195.92.194.78:
Can anyone tell me if there is any way to force trackside cameras *not* to track
the cars as they drive past? You know how the trackside cameras sometimes freeze
their tracking when using the director mode (the Ins key) - is there any way to force
this?
Cheers,
Mal.
Posted by addie from 194.191.82.13:
mal
could you name the cameras where you noticed the freezing ?
maybe both phenomena (freeze and pixeling) could be somehow controlled by the remaining
unks in the cam data ?
Posted by Mal Ross from 195.238.164.184:
Well, one place on the original circuits that you often see it is at Hockenheim.
The camera at the start of the stadium section that looks back up the straight sometimes
doesn't track the cars around the corner. I *think* the game has to be in director
mode (Ins key) to see this, but I'm not sure.
Mal.
Posted by µartijn from 212.64.17.88:
Yes, only in "director mode" will any camera hold the view still.
Damn I like it when the director does that. Isn't it some "first lap only"
behaviour?
Posted by Dany Roscoe from 195.40.200.53:
Hi guys,
As a person knowing very little about track editing, this is my first contribution
to this list.
I would just like to ask you guys if you could explain to me how to move the cars
forward on the track at the beginning of the race. In other words adjust the positioning
of the cars on the starting grid.
Thanks for reading,
Danny.
Posted by Olivier S. from 195.238.6.31:
The cars are positioned just before the start of the first track sector.
To move the starting grid forward, you have to make the first track sectors shorter
and the last track sectors longer so it moves the starting line. But if you alter
this you must also adjust the CC Line Start Y value.
You can adjust all the start settings in the Track Config section in the tree.
Filou
Posted by Paul Hoad from 195.92.194.19:
Welcome Danny,
Its good to see some new blood.
You'll find the people on this list helpful and friendly no matter how trivial your
question might seem there isn't a single person here who wasn't at that stage at
some time.
So everyone know what its like to TE in the dark!
The more the merrier!
Paul Hoad
Posted by Jason Hope from 207.253.111.24:
okay, here we go.
I am in the middle of adding textures to certain ribbons on my track, but when i
go into the game, the texture does not appear on the ribbons. Actually, the texture
does not appear at all! Any clues as to what this could be. I have experience with
the texture command, but for some reason i can't seem to add texture to these ribbons.
Can it have something to do with the 0xc8 commands in t0 already having a texture
on this ribbon?
please,
Jason
Posted by µartijn from 195.96.120.202:
Texture commands do not "stick" when they are applied on a ribbon that
is not as long as the texture that you want to add to it.
Hrm?
in other words:
If you add a texture command to a ribbon, with a texture length (a2) of 35, while
this ribbon "stops" (with 0xb0) after 25 lengthunits, the entire texture
gets ignored.
This could be it, if not, please repost, and we'll open the box of tricks a little
wider.
Posted by Jason Hope from 207.253.205.176:
The texture lenght i put is at 191 tarck units. I'll have a look at it. Maybe
the length is too long. I'll split in up into smaller segments and see what that
does.
I'll post my results later today, or in about 25 to 30 minutes.
Jason Hope
Posted by jason hope from 207.253.223.36:
okay, i shortened the lenght of the area where i put the texture on, and it works.
I think very long ares where textures are applied to do not recognize the texture.
I tries putting the length to 110 units, and it didn't show up. I put it to 100 units,
and it worked.
Oh well, seem to know a bit more about this.
Jason
Posted by Fat Rat from 207.194.25.98:
Hi All
Any ideas on how to increase the scale ( size. Height ) of internal objects , ( GP2
defined 5 trees )
Been playing around with the unks1\2 , but still no disernable changes , in any form
.
Seen lots of different values & combinations
0/0
0/16
0/257
0/6425
1312/0
1312/257
1328/257
All seem common to the trees in the Mp tracks ,
I just can't seem to get the trees to grow tall enough, we grow them big here in
B.C.
I don't want any "flying trees " Stack 2 ontop of each other?
They seem a bit bugger when in a complex object group , rather than just on it's
own
Thanx
Les
Posted by addie from 194.191.82.13:
good idea les !
basically the id1=5 internal object simply shows the connected texture as given in
id2 (texture id +256 actually). so its size is given by the texture itsself. but
maybe there is a cmd to generally resize them, similar to the “resize horizon” cmd
?
anybody noticed some “bigger than usual” trees in original tracks ? if yes, in which
track ?
workaround for the meantime: make those trees with “adverts”. those objects can be
resized.
Posted by Adalberto from 62.10.71.127:
to alter the hight of the internal obj n° 5 you must use the jam editor and edit
in the unknows of the texture the idx_0a .
cheers
Adalberto
Posted by Fat Rat from 207.194.18.153:
Hi Guys
Thanx Adalberto , not ideal . but stil the best way yet.
I say not ideal , because since it involes editing the jam ID , It's a global change
.
IE. I can make a nice tall tree as a single tree , but when the same tree is contained
in a group , is Tall too .
i'd rather be able the size of each object by means of a def , So I can vary the
sizes of the trees in general .
Still if this is what's needed , it's still better than editing the jam graphic it
self , saves on jam space .
Again thanx
This should do the trick.
Les
Posted by Paul Josephson from 12.75.150.232:
Martijn (and anyone else who can help!),
I'd like to create gaps in fencing, but I haven't been able to figure out how you
did it in your Stuw Lake track (BTW, great track!!). To enlighten others, in t(7)
you changed the left fence track height from 6 that existed in prior track sectors
to 1 and the distance from track to left wall from 75 in t(6) to 25. After viewing
the track in the TE and changing the wall distance in t(6) to 25, I noticed you had
a small gap in the fencing. The texture you used through t(5) started in t(113) out
of a total of 121 and continued into t(6).
I'd like to do the same thing for a track I'm working on -- have a fence start from
a distance away from the track, move it closer, and be able to change the fence height
at the gap.
a.) Is some math required to figure how to create the gap and set the fence args
correctly or is it a question of luck and lots of testing of different fence arg
values?
b.) How did you get the fencing in t(6) to change from fencing on a dark grey rail
to a white rail with no fencing on top? Is the white rail some sort of default? I
didn't see a command in t(7) to change the texture, and the texture you used in t(8)
was a Mobil ad that didn't appear !!
Can you shed some light on how you did this? When I try it, I get a continuous ribbon
of fencing. It also looks funny when I change the fence height.
Thanks. Any help would be appreciated.
Paul
Posted by Martijn from 195.96.120.202:
Thanks for the compliments :-)
You can simply click the
"remove fence texture", that way, the fence becomes invisible. (it's still
there if you try to drive into it).
Take a note that when you insert a "change fence height" command, that
the distortion in the fence texture comes in BEFORE the actual command. So you have
to remove the texture just before this command.
About the texturing: the texture before the gap is "catchfence with armco",
and after the gap, the default texture gets applied because no other is specified.
The default texture is set with an 0xc8 in T(0), which isn't there, but GP2 uses
texID 112 as default incase there's no 0xc8.
Um, I hope to have answered your questions,
Martijn
Posted by david Richards from 202.12.71.11:
I had occasion to remove fences at various places on an already built track, and
to avoid having to shorten track sectors and insert new ones (ie reduce a curve of
10 units to 5 units and insert a new 5 unit curve with same angle) so I could use
the remove texture switch, I found space in a jam and created a transparent texture
(that funny green colour), and then applied it wherever it was needed.
This meant all I had to do was insert fence texture commands where gaps were wanted,
and adjust their length appropriately. no need to change track itself at all, and
it's then easy to put a gap in any time you like.
Posted by Fat Rat from 207.194.25.204:
Hi Dave
All should use care with mapping the transparent texture .
In Some cases this texture will show the sky behind where this texture is mapped.
Instead of whatever texture or objects etc. are behind this area .
A good example is with the fence texture , I have a transparent strip at the bottom
of the fence in between where the post are .
In the game I dont see the verge or bank behind the fence . I see a small strip of
sky . at the bottom of the fences ,
But on the other hand , I have at least one Nil texture ID in all my tracks ,
And do use this technic often , It's really handy for getting those last few gfx
gliches .
CU
Les
Posted by David Richards from 202.12.71.5:
Hasn't struck me so far - we did a farm fence for Bathurst '86 that works brilliantly,
and I also put in a pace car gfk that has a large area of transparency around it,
plus an area on the inside of the last corner.
I shall be wary however, now that you have pointed it out.
Regards to all
David
Posted by addie from 194.191.82.13:
a), b) KB and RS are the original input for roadsigns kerbs etc. all the groups of
arguments you find around KB and RS. actually the labelling is wrong. KB and RS are
original input, the rest is alternative, respectively interpreted for more comfort.
do change a roadsign or kerbinfo for seeing how RS and KB do change also. its a code.
that means, the dialog box translates the comfortable input into corresponding KB
and RS figures, and those figures finally get stored in the tracksector in the trackfile.
c) first you have to choose the “track tool” in the tools tool bar (thats the one
with the magnyfing glass in first place), after that “insert track sector” is no
longer greyed out. (same to pit sectors etc.)
i hope its useful info
addie
Posted by Paul Josephson from 12.75.150.54:
Thanks guys for your help -- a couple of newbie oversights on my part!! Your comments
spurred some other questions:
a.) Does anyone know what the KB is and its use (under Alternative Input in the Track
Change Dialog box)? The value changes when you click on Remove Textures for the left
and/or right walls and it appears to be changeable.
b.) The other Alternative Input, RS, changes when you click different Road Signs.
Anyone know what this is?
c.) How do you insert a new track section? I have TE v. 1.8.8 and the option is shaded
in the Track menu when I highlight an existing section.
Paul
Posted by Dan C. from 142.58.123.5:
Hi all,
I fiddled a bit with that 0xc5 command that I can't seem to get enough of. I think
Bob C. had found that there were 2 arguments that corresponded to the "swivel
arms" of view either left or right. If these are 0, then you can only see left/right
when facing forward.
This are A6: left arm of view
A8: right arm of view
What I found with A7 is that it seems to work the same as A5. This was a "switch
off Loc type D" It just switches off any location you put defined by Loc D.
I really don't know why you would need 2 of these arguments if they do the same thing.
So all the arguments of the command found:
A1: offset into sector
A2: start track location you want to see
A3: end track location you want to see
A4: switch on Loc type D.
A5: switch off Loc type D.
A6: left swivel arm of view
A7: switch off Loc type D
A8: right swivel arm of view
Hopefully this closes the book for this command.
Dan C.
Posted by µartijn from 195.96.120.202:
Not quite,.... for instance, I have a 0xc5 occasion where I run into the far-view
window almost perpendicular, and the scenery there flickers a lot. Which value of
A6-A8 should I use to prevent this as much as possible?
Posted by Dan C. from 142.58.213.36:
I'm not sure if the flickering is related to A6-A8. The whole view either turns off/on.
I have flickering in Monza banked in the S/F straight on the pit wall. I found that
the flickering was due to having the command span the last and first sections of
the track. When I omitted this wierd area, there was no flickering.
I think the flickering might not be fixable in some cases, like where the pit fence
joins the track fence. But the best I guess is 16384. Or maybe the new anti-flickering
command might help.
Dan C.
end of list