Track editing progress notes

[checkpoint10]

I have a habit of wanting to check my work in game all the time, so I went ahead and automated this. It is fun to sit back and watch this, basically with a combination of Python and batch files, it does the following:

1) Open DOSBox and run SG2TRK and TRK23D. Quit DOSBox
2) Python script to correct the colors in the .3D file (I have a separate file that has the correct color header)
3) Open DOSBox and run 3D23DO and then OPE
4) The only manual thing I must do: Load the TSD file and save.
==At this point I probably would also need to load all the trackside objects. These should be kept in a separate file as well. I have not automated this yet.==
5) Run 3D23DO again. Quit DOSBox.
6) Copy the .3DO file to a subfolder (I call it TSD) for the TSD fixing procedure
7) Run Tjerk's MRON (still in Windows environment)
8) Open DOSBox and run 3DO2DEF. Quit DOSBox.
9) Python script to replace F21 with F02.
10) Open DOSBox and run DEF23DO. Quick DOSBox.
11) Copy the new .3DO file back to my working folder.
12) Run MRON on my entire working folder
13) Create a packing list of the working folder
14) Python script to pack the .dat file into my "fake N2" folder
15) Run the N2toICR2 converter - at this point I have to manually click a button to convert
16) Revert all the 3DO files in my working folder to their state before running MRON
17) Python script to unpack the .DAT file created by the converter
18) Copy all the ICR2-specific files that I keep separately (textures, models, etc.) to my ICR2 unpack folder
19) Python script to pack the ICR2 .DAT file again
20) Copy all the files in the root directory of the track that I keep separately (such as txt file, setups) to the ICR2 track folder

If I am making a release version of the track, I would also correct the colors in the ICR2 version by doing this:

21) Open 3DOEd and use Tjerk's Tutorial's technique to replace colors of walls and ground as needed.
22) Python script to repack the ICR2 .DAT.

Whew!

[Wolf_pd]

This is the same reason I love my automated testing at work. Just watch and sit back.

[checkpoint10]

Does anyone know what is the best way to make hills? For example, the hillsides at Mid-Ohio that extend beyond the track boundaries. I will need to do this for Detroit and Nashville, otherwise there are places where you can see through the underside of the track.

Right now, I was thinking I might use 3DOEd to figure out the coordinates of where the hillside should be, and then make a trackside object that fits into the space. I am not sure if there is another way that anyone has found.

[Eddie500]

An option would be to convert the .3do layout into obj with the gpl editor, as the scale is not accurate, convert the .3do to .def with n3def and paste the (tweaked) n3 vtx coordinates in the .obj object. This one could now be imported at correct scale into blender or whatever so you can build a hill around in a "what you see is what you get" way. With the Boblogsan scripts the exported hill would then be in its final state as an icr2 ingame object.

[checkpoint10]

An option would be to convert the .3do layout into obj with the gpl editor, as the scale is not accurate, convert the .3do to .def with n3def and paste the (tweaked) n3 vtx coordinates in the .obj object. This one could now be imported at correct scale into blender or whatever so you can build a hill around in a "what you see is what you get" way. With the Boblogsan scripts the exported hill would then be in its final state as an icr2 ingame object.

Thanks for explaining this process. Unfortunately, I don't know how to use Blender, but I am aware that Boblogsan made those scripts to convert to and from those formats.

[Eddie500]

About 2 of 3 modelling softwares out there can handle the .obj format, maybe you can translate it by hand if you wish as it's humanly readable like the papy .3D files are.

[checkpoint10]

I made a version of Nashville with brake markers, but this time I used a different technique to place them which bypasses OPE for the most part - I loaded the track 3DO in 3DOEd and then figured out the coordinates of the places where I wanted brake markers by clicking on those points along the wall and manually updating the .3D file with them. I could even manually adjust the rotation and see what it would look like in 3DOEd. Although it sounds like more work, this is a lot preferable to doing it in OPE because OPE is still quite sensitive to my joystick movement when it comes to smaller details like this. If you use this method, remember to use OPE to recalc the draw order of the objects.

Getting comfortable with 3DOEd I think will help me do some more advanced things later like making hills.

[Eddie500]

What is the preferred procedure out there to put a scratch track lenght to official mesurement down to the last inch please ?

[checkpoint10]

What is the preferred procedure out there to put a scratch track lenght to official mesurement down to the last inch please ?

For my last two tracks, I scaled and measured the aerial photo and modified the scale in SGE.INI accordingly before tracing the track in SGE down the centerline. This way I do not rely on SGE’s scaling function which I find inexact.

[checkpoint10]

I am adding trees to Nashville and used the following method:

- Made some placeholder 3DOs for use with OPE. These placeholder 3DOs have the names tree1, tree2, etc. but they are squares that have various shades of green just so that I can see clearly where I am placing them in OPE.
- Once I convert the track over to ICR2, I bring over the tree1.3do, tree1.pmp, etc. from a default track. This is because this kind of object does not convert well from N3.
- I did not like the size of one of the trees, so I am able to adjust the size of the ICR2 tree1.3do by hex editing. Within the hex editor, I noted that offset(h) 34 is a number that probably is the width of the object in 500ths. There are converters online that can convert a decimal number to a little endian hex number, which helped with this step.