*****GP4 Track editing*****

@Xero: Beware, shiftangle belong to .dat file as every other data and should not be reseted to 0 but to the original value...You can tweak it to have a better cc-line display in 3DEditor but the shiftangle value is saved in the not, so if you do not revert the value to its original before saving, game will use your new tweaked shiftangle value.

@Maverick: If original ccline in 3deditor was far from perfect and you only made it looking perfect in 3deditor, changing radiuses then it's obvious the in-game cc-line will be a mess.

I don't know how I can explain this to you (and I thought you already knew it)...
Well, cc-line is perfect in game and this perfect in-game line is computed from values displayed in 3deditor, whatever its display in 3deditor.
So if you change ccline values in anyway (even to get it looking perfect in game) you're changing original perfect values and have great chances the in-game computed cc-line will not be perfect anymore...

Hope it is somewhat clearer than before ...

Lo2k Wrote:
-------------------------------------------------------
> @Maverick: If original ccline in 3deditor was far
> from perfect and you only made it looking perfect
> in 3deditor, changing radiuses then it's obvious
> the in-game cc-line will be a mess.
>
> I don't know how I can explain this to you (and I
> thought you already knew it)...
> Well, cc-line is perfect in game and this perfect
> in-game line is computed from values displayed in
> 3deditor, whatever its display in 3deditor.
> So if you change ccline values in anyway (even to
> get it looking perfect in game) you're changing
> original perfect values and have great chances the
> in-game computed cc-line will not be perfect
> anymore...
>
> Hope it is somewhat clearer than before ...

I see, but, when i just change the shifts, and compensate the bends with it, the result should be quite the same not? Only difference is that because no shift is used, 3deditor shows it correct. besides that, if i just start from scratch and use the same values, it will come out the same, but problably WILL work, then how is that possible? i know 3deditor has fualty display of ccline, but 2 cclines with the same values in 3deditor shouldn't differ ingame right?





Edited 1 time(s). Last edit at 02/08/2005 12:37PM by <Maverick>.

tobeast Wrote:
-------------------------------------------------------
> @erwin: I removed some of the pitlane sectors and
> added it new... but it is still not working.

be sure you add to the end or start. I only added new pitlane sectors at canada, that worked fine

It probably WILL NOT work.
What's important and reliable in 3DEDitor are raw data (the values themself), not the display wich is a somewhat a personnal approximation.
If values are the same between two tracks, then GP4 will read both track the same (if it does crash with one, it does crash with the other). If this rule is not respected, it means I made a mistake and 3DEditor somehow changes values at loading or saving without I know it and this would need to be fix quickly then.

Having a cc-line QUITE the same is not having the exact cc-line and as you now, any little change in cc-line could occur much changes a hundred sectors ahead...

Beware, shiftangle belong to .dat file as every other data and should not be reseted to 0 but to the original value...You can tweak it to have a better cc-line display in 3DEditor but the shiftangle value is saved in the not, so if you do not revert the value to its original before saving, game will use your new tweaked shiftangle value.

OK, now you've lost me! I was talking about the inital ccline sections ShiftAngle value... the one from where it changes the mess to you approximations (you have a table in the manual for each circuit). That is reset to 0, and does not belong to the .dat. I'm not talking about the shift values for each section.

I was also speaking about initial ccline sector shiftangle value, and I don't know where you heard this value had nothing to do with .dat...
It's not because I told you can change this value temporary (with values in the array given in the user doc) that it is not belonging to .dat.

Sorry for confusing you!... i've confused myself!!

I meant the modified value isn't used in the .dat, in-game. It's always reset to the default value, which is 0 for very circuit. With that in mind, in your algorithm to draw the ccline you must have to extract the shiftangle value in order to correct it. What's stopping you from using an external floating point value instead?

Sorry, you must be getting annoyed at me now, but do you understand what I mean?

Well, it's not 0 for every track as it's -6 for Sepang for example (s1ct02).
And nothing more than the guess it won't work is slowing me down but it won't stop me as I told p24 I will try to use a float to see if your idea could work.

No problem as long as we can finally agree on this point

I am deffo gonna learn this software-gonna get a printed manual first though, so school's IT dept are gonna kill me...
Can anybody suggest the best track to play with?

_______________________________________________________

Team Japan Owner - GPGNC

OK, agreed. I didn't realise Sepang was -6. It just so happened the circuits I did open were all 0!

@Harjinator: Try one of the tracks that has a perfect ccline from default... check the manual for a list, theres a few.

@Laurent: When editing the ccline, what does the value R1 stand for? Appears to be a flag of some sort. And how do I go about changing it? It seems to correspond to these kinks i've been getting.

And Monza has a Shiftangle of 1 too :P

R1 is one of the two raw values used to set Radius.
Has many other measures, GP4 uses two values to set a measure.

So relation formula is:
Curve1 Radius (in mm) = R1*65535+R2
Curve2 Radius (in mm) = R3*65535+R4

I just remind I havn't reply Maverick about creating single radius cc-line section.
Well, I think it's in the user guide but as I have a doubt...
Theoreticaly, Using two times the same radius will give the same result as having a single radius of the same value.
ie: Radius1 =1500 and Radius1=1500 and Radius2=1500 should give the same curve.
Reason is Radius1 and Radius2 set start and end radius of the arc, so using equal radiuses will give a circle arc, simple, no ?

Oh, and I added that floating point manual fix for shiftangle, fixed Melbourne's cc-line to be perfect visualy, then change some curves but keeping the perfect display, saved the track tried in game ...and GP4 crashed.
As I thought, matter is not only relying on initial angle, but also on another miss-understood thing in the cc-line interpretation (like shift value or rouding errors...).





Edited 1 time(s). Last edit at 02/09/2005 12:26PM by Lo2k.

tnx for the explaination lo2k, here goes....

so, took melbourne again, removed shifts, edited some bends, game crasshes on load.
save it, removed all cc's, and began rebuiling it as a 100% copy, from time to time i looked, and it all seemed to work ingame, last checked 3 turns befor end, looked fine, problem is, they dont follow it as nice as they should, alltough i can only assume the DAT sections in this origional track are made 100% correct that seemed a bit odd to me. anyways, i moved on, finished the track, didn't load ingame... so, as it did work before, i began deleting the last sector, test, delete sector, test, came to sector c47, when i deleted that one, track worked again, strange, soo.. i loaded the original crashing ccline, deleted the last few sector till c47 and it too loaded ingame. this what not at all what i suspected what would happen.
I originally thought, that if i had 2 the same cclines, one loading, and one not, you could see what the internal difference was, and how to fix it. but now there is one sector wich seems to be the cause of a track crashing, and i have no idea why, cause it's just a normal bend. so for your information i had a zip, containing all the cclines i made for melbourne, so maybe you can see whats wrong with that particulair ccline section, and maybe come up with something
here it is: [maverick.dynasoft.nl]

also, came across some length 1 ccline sections, you saw the stange highlight in an earlier post, now i saw that such a section is not drawn until there is a section after it.

maverick out.

i think you can better focus on the shifts iso removing them. Probably the are some offset values, focus points or error detections for the game, but which 3d editor uses as normal sectors and therefor treating them as curve and confuses the image of the track (like we humans know it).

erwin_78 Wrote:
-------------------------------------------------------
> i think you can better focus on the shifts iso
> removing them. Probably the are some offset
> values, focus points or error detections for the
> game, but which 3d editor uses as normal sectors
> and therefor treating them as curve and confuses
> the image of the track (like we humans know it).

hm, i'm not following you erwin..
the new one is 100% created by me, using no shifts at all, so, i think it really is a curve.. or did i misunderstand what you ment?

Oh, and I added that floating point manual fix for shiftangle, fixed Melbourne's cc-line to be perfect visualy, then change some curves but keeping the perfect display, saved the track tried in game ...and GP4 crashed.
As I thought, matter is not only relying on initial angle, but also on another miss-understood thing in the cc-line interpretation (like shift value or rouding errors...).


Yep, rounding errors would be a possibility, although these rounded values are stored in the dat, right? Wouldn't reloading the circuit then redraw the track with these rounded values? Or have you modified the dat to store floats, and the rounding errors come from the game engine?


R1 is one of the two raw values used to set Radius.
Has many other measures, GP4 uses two values to set a measure.

So relation formula is:
Curve1 Radius (in mm) = R1*65535+R2
Curve2 Radius (in mm) = R3*65535+R4


I see. Any known explanation for these kinks im getting? I'm sure you know what I mean.

@Maverick:

Lo2k here

Well, have a look at this shot.
That's your cc-line with 47th sector.
To know what happens, I tweaked shiftangle value (using -5) in order the 3deditor cc-line looks like what we experiment in game whithout the 47th sector.
As you can see, the only section where cc-line is no more smooth is the 47th sector and it then is obvious for me, that it is why GP4 doesn't work, but how will I explain you that ?

The matter with your track is that your artificialy made the cc-line looking perfect in 3DEditor.
But if you run a short race (without 47th sector), you will quickly notice how cars are starting to run off-road little by little all along the track.
As this is the way GP4 interprets the cc-line, the best way to see what's wrong is to simulate the cc-line as you saw it in game and thus as it should be displayed in 3DEDitor without tweaking if 3DEditor was wysiwyg.
After having trying several values, -5 seems to approximate what we experience in game.
When you're looking at 37th sector, you can clearly see that this sector is the first one having an accident.

When 3DEditor encounters an anomaly, it does not crash but compute a wrong value, causing the sharp corner, but GP4 does not compute a wrong value, it does crash.
And that's why 37th sector is causing you crashes.
So using the -5 tweak shiftangle value, you can preview approximately how will be the cc-line in game and will reduce for you risks it crashes the game.


@Xero: .dat files are only storing integer data, none is a floating point value.
The float value I used was only used in 3DEditor to compute a finest display, it doesn't change anything to the .dat values. Only the changes I did to curves were saved in the .dat.
What kind of explanation do you need ?
.dat only store integer values between 0 and 65535, so to bypass this limitation, they store values with two integer ones and once the .dat has been read, game engine create a longest integer from the two "short" integers using formula above.

Lo2k Wrote:
-------------------------------------------------------
> @Maverick:
>
> Lo2k here
> bla bla too long to quote.... :+

ok, understand what you mean.
But, how do you get the -5 value? it indeed looks like what i have ingame, but -4 isn't that strange either, and using -5 on the original dat with normal ccline doesn't make it much better (well a bit in the first half of the track, not at all at the end).. now something else. where the hell does this shiftvalue comes from? Cause it's not set in the ccline, as in my own version i deleted the cc sections, and rebuild all by myself, so if i create a totaly new ccline, why would i need shiftvalue, does this mean that maybe this value is "computed" within the dat sections? i mean, it's gotta be in there somewhere, like total sectors/bends=shiftangle, wich makes sure the ccline interacts with the dat.(just a stupid example, but you get that ) (by dat i mean the tracksections btw)

edit alot about shiftvalue/shiftx, i took a look, had some questions, maybe becasue of the sloppy design, (gp1 -> 2 -> 3 -> 4) shiftx is not what you think it is, as 0 is definitly not what it should be for some tracks, i thought, maybe if i edit this value i wont even notice it ingame, tried it, well did notice it, use -3 for brazil, wich is not right, but comes close, using real values (3.1 5.6 thats what you call them right?) sounds nice to me, but i noticed something that i cant explain.. maybe you can, on brazil, using a shiftx of 0 makes the display left of the straight at the end, but the cars go where they should considering where the tarmac is. now when i put in -3, the cars whent right of the final straight..but.. this was exactly where the display of the ccline in 3deditor was. do you understadn what i mean?
also, are shiftX and shiftangle the same thing? as maybe they are both in every track, but you have them mixed up?

new edit
Been looking at brazil again, setting shiftangle to -3. cc's folowed the (too wide at the end) line, editted the line to follow the track, they took it perfectly, but only when i kepted shiftangle at -3, reseting it to default (0) makes the cars not folow it right, and they now follow a line wich lies between 2 and 3 (cant get more specific with this 3deditor version as you know) is it maybe possible that shiftangle is altered when the ccline is altered? So it should be an auto calculated value when you change the ccline?






Edited 3 time(s). Last edit at 02/10/2005 08:49PM by <Maverick>.

<Maverick> Wrote:
-------------------------------------------------------
> hm, i'm not following you erwin..
> the new one is 100% created by me, using no shifts
> at all, so, i think it really is a curve.. or did
> i misunderstand what you ment?
>
>
I think laurent already explained now...at least if i'm getting the story right

jup, i see what you meant. you were right too :+