Forum Postings 2000 January

as collected and (very little) formatted by addie walti


Threads

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 ?!

end of file


Index

Practice works but not race!?!

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.


Index

Heights-problem in TE 1.8.3

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.


Index

Heights (+The Complete Heights solution)

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




Index

Clermont-Ferrand and Strange CC line phenomenon

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.



Index

Question (track through local city)

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 :-)


Index

Bad font character /grid menu bug ??

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.



Index

black horizon

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.


Index

NEW: Command 0xB2

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...




Index

NEW: Command 0xB6

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



Index

Internal Object Names

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




Index

JAM editing - untextured colours

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




Index

NEW: Command 0xB7

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.



Index

NEW: Command 0xCC

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!!



Index

NEW: Other commands

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.



Index

pictures please


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?


Index

0xd0 values???

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


Index

Car direction after leaving pitlane?

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





Index

Detail levels in object descriptions

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


Index

Reserved\hardwired offsets

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


Index

cc-car coaching news (+0xd0)

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.


Index

complex objects

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


Index

0xd0 - no more doupt

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.



Index

0xc5 - unk a5: figured out!

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


Index

black horizon II

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


Index

0x9A and 0xAC de-unked

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)




Index

Camera distances in TE display

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


Index

object problems

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


Index

newbie camera question (pixeling)


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


Index

Another newbie camera question (freezing)

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?


Index

Adjusting start position

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


Index

frustration (mapped texture does not show up)

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


Index

altering internal objects scale

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




Index

Gaps in fencing

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


0xc5 fully de-Unked ?!

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.






Index

end of list