Modified Track Path Editor + Tracks/Discussion

I don't suppose anyone has written a how-to guide for custom track editing? An explanation of each value in a TED file would be awesome. I would be willing to write a guide, if I can gather enough information. Then again, if the ted-editor keeps getting better, perhaps this would just be a waste of my time?

I'm a little impatient though, because there is a track I've wanted to drive on for decades and have never been able to build. So I've been conducting sloppy experiments to try to figure out how the TED file works, but I don't want to waste too much time reinventing the wheel here, so maybe you guys have some insights you could share about the specific values in the TED file? Can I assume that the ted-editor already takes care of everything except for CHECKPOINT, ROAD, and DECORATION data?

In breaking down the TED file, Razerman's template has been very helpfull, but it doesn't explain the purpose of any of the values. And without knowing what those values are for, it is pretty tough to make manual edits. I converted Razeman's binary template into an XML template compatible with HexEdit, which is helping me out a lot.

I know so little right now, you may get a laugh at my experiements:

Experiment #1: I built a 14 km track in the ted-editor, then used HexEdit to copy CHECKPOINT, ROAD, and DECORATION data from a simple working TED file into my file, making sure all the offsets and counts were correct. When I tried to import the track into GT6, my PS3 appeared to import it okay, but then froze when it got to the test drive menu.

Experiment #2: I built a 10 km track using the vanilla TPE, saved a replay from it, and used Razerman's extractor to get a TED file. I imported that into the ted-editor, uploaded it straight into to GT6 to make sure it worked, and it worked fine. I then used HexEdit to manually changed only the SceneIndex from Eifel Flat (5) to Andalusia (3), and uploaded it to GT6 again, and this time it froze. The only change I had changed was the SceneIndex value. What happened?

There are so many things that could be wrong. If I change the SceneIndex from Eifel Flat to Andalusia, are there track-specific things that I also need to make adjustments to, perhaps to the decorations? Maybe my tracks are just too long or have too many control points? Maybe the elevation data from Eifel Flat don't translate well to Andalusia? I could run a hundred more experiments to narrow this stuff down, but I'd rather not if you guys already know the answers.
 
I don't suppose anyone has written a how-to guide for custom track editing? An explanation of each value in a TED file would be awesome. I would be willing to write a guide, if I can gather enough information. Then again, if the ted-editor keeps getting better, perhaps this would just be a waste of my time?

I'm a little impatient though, because there is a track I've wanted to drive on for decades and have never been able to build. So I've been conducting sloppy experiments to try to figure out how the TED file works, but I don't want to waste too much time reinventing the wheel here, so maybe you guys have some insights you could share about the specific values in the TED file? Can I assume that the ted-editor already takes care of everything except for CHECKPOINT, ROAD, and DECORATION data?

In breaking down the TED file, Razerman's template has been very helpfull, but it doesn't explain the purpose of any of the values. And without knowing what those values are for, it is pretty tough to make manual edits. I converted Razeman's binary template into an XML template compatible with HexEdit, which is helping me out a lot.

I know so little right now, you may get a laugh at my experiements:

Experiment #1: I built a 14 km track in the ted-editor, then used HexEdit to copy CHECKPOINT, ROAD, and DECORATION data from a simple working TED file into my file, making sure all the offsets and counts were correct. When I tried to import the track into GT6, my PS3 appeared to import it okay, but then froze when it got to the test drive menu.

Experiment #2: I built a 10 km track using the vanilla TPE, saved a replay from it, and used Razerman's extractor to get a TED file. I imported that into the ted-editor, uploaded it straight into to GT6 to make sure it worked, and it worked fine. I then used HexEdit to manually changed only the SceneIndex from Eifel Flat (5) to Andalusia (3), and uploaded it to GT6 again, and this time it froze. The only change I had changed was the SceneIndex value. What happened?

There are so many things that could be wrong. If I change the SceneIndex from Eifel Flat to Andalusia, are there track-specific things that I also need to make adjustments to, perhaps to the decorations? Maybe my tracks are just too long or have too many control points? Maybe the elevation data from Eifel Flat don't translate well to Andalusia? I could run a hundred more experiments to narrow this stuff down, but I'd rather not if you guys already know the answers.

Well, here is what I know. Not sure if the order is the same as it is in the file, but it should be roughly the same:

  1. Header. The key for reading the file. Shows where each type of data begins and how many items there are of that type. When you add or remove data from the file, the header needs to be updated to reflect those changes. The header also contains some track data, such as the scene, the type (point-to-point or circuit) and the position of the start line. All position data is relative to the first anchor of the track, by default the beginning of the pit straight.
  2. Cp. This data contains the coordinates and the form type of the track. It can be straight, nearly straight, or left/right turn. This corresponds directly to the anchors you place when you create the track, although all the corners are split into two Cp points (one for entry radius and one for exit radius). The corner data also contains two coordinates: one is the coordinates of the anchor and the other is the coordinates of the center of the arc.
  3. Checkpoints. The position of the checkpoints, as the distance relative to the first anchor. The number of items determines the number of checkpoints you'll have in the track.
  4. Road. This contains the actual road mesh type. There are several different types, such as pit straight, gravel trap, decreased radius, forest, etc. @Mr Grumpy made a list of most of these. Keep in mind that the ID values are long and complex so make sure there is no typo when you edit them. Copy-pasting is a good strategy. The road items have start coordinates and end coordinates, again measured from the first anchor of the track. It's important that no coordinates exceed the length of the track because if they do the game doesn't know where to place it and that will end in horror. The length of these road items is flexible, but you should probably keep them near the default values of around 50 or 100 meters (for Eifel, I haven't studied other scenes very much).
  5. Decorations. All the stuff you can place in the TPE app. It's similar to the Road data, but got an extra parameter for which side of the road the decoration is placed at. See @Mr Grumpy 's list for this as well. The length of the decorations is flexible, but keep in mind that they will stretch/compress when you change their length. Decorations on the inside of a turn should be a little longer than those on the outside of the turn, as the track is shorter on the inside than on the outside. You can be pretty free when placing decorations, the game seems to be able to tolerate a lot of abuse when it comes to this.
Edit: I knew I forgot something :P

  • Bank. This divides the track into a number of bank segments, sets the bank angle and also controls the distribution of the height data.
  • Height data. Just a list of height values. Their distribution is controlled by the divNum of the Bank data.
 
Last edited:
This may not look like much at the moment, but it's an embryo for a new course layout feature that I've been thinking about for a long time now.

Skärmbild (11).png


Basically, instead of working with straights and corners you place a framework polygon and then the corners are automatically rounded based on the individual turn radius settings for each corner. The advantage of this is that you can adjust the layout without distorting the turn radius. This allows you to quickly "sketch" a track layout without having to worry about reshaping the corners every time you want to adjust the length or direction of a straight.

The idea is that you can quickly create a layout, the application will then export is as a basic track file which you can then import in @tarnheld's ted editor where you can do any fine adjustments that you might want to do and calculate the heights to match the landscape.

(The mess in the picture above is a randomly generated polygon with rounded corners)

Edit: Here is a better picture, where the framework polygon is drawn (this is a random polygon with 8 points). As you can see there is just a single control point per curve+straight, allowing you to quickly modify the layout and experiment until you find one that you like.

Skärmbild (12).png
 
Last edited:
This may not look like much at the moment, but it's an embryo for a new course layout feature that I've been thinking about for a long time now.
Is it correct that one of the goals here is to do tracks (from scratch) with this program and TED, without necessarily playing with replay files?
 
This may not look like much at the moment, but it's an embryo for a new course layout feature that I've been thinking about for a long time now.
Maybe you could also add some sort of a manipulator handle to each control point to let you quickly adjust how sharp you want your corner to be? You pull the handle to make it sharper and push it to make it wider. For example:
handles.png

Maybe you could allow side-to-side adjustment of the manipulators as well, allowing us to make asymmetrical corners? This might be more complicated, but I think it would be an awesomely powerful tool.
 
Okay this is probably way off, but do you think it's possible to have rain or snow on a custom track? it may not be adjustable but I'm curious whether there are certain values that could be altered to make the game have weather conditions when it normally wouldn't..
 
Okay this is probably way off, but do you think it's possible to have rain or snow on a custom track? it may not be adjustable but I'm curious whether there are certain values that could be altered to make the game have weather conditions when it normally wouldn't..
I imagine the weather comes from the "prepackaged" theme, like Eifel, that has weather effects. Similar how if you start a new game and driver and do some laps on a custom track, I imagine it would give your favorite track as the theme of the custom track (because that's what replays say). But maybe it excludes them completely and just gives some "PD manufactured" track there.

As for making the game trip over itself online (there are threads on GTP about getting it, don't remember much), well, maybe, but probably Eifel only. But you probably meant permanent snow, not merely snowing.
 
Don't forget an import image option :cheers:

Maybe added later on, I don't want to complicate things too much initially :lol:

I also think that this mode might be a bit awkward for tracing a background image as the control points doesn't directly tell you where the corners are placed, the TPE or the ted editor is probably much better for doing that. This is more of a tool for quick freehand sketching and creating your own unique designs :)
 
I imagine the weather comes from the "prepackaged" theme, like Eifel, that has weather effects. Similar how if you start a new game and driver and do some laps on a custom track, I imagine it would give your favorite track as the theme of the custom track (because that's what replays say). But maybe it excludes them completely and just gives some "PD manufactured" track there.

As for making the game trip over itself online (there are threads on GTP about getting it, don't remember much), well, maybe, but probably Eifel only. But you probably meant permanent snow, not merely snowing.

Thanks for the info! yeah my dream would be to be able to run our custom tracks with wet conditions or snow affecting the handling. That may be too complicated to do without completely cracking open the game.. but I'm curious as people seem to keep making progress with the track editor
 
Thanks for the info! yeah my dream would be to be able to run our custom tracks with wet conditions or snow affecting the handling. That may be too complicated to do without completely cracking open the game.. but I'm curious as people seem to keep making progress with the track editor
I'm unsure whether you have tried some of them in wet conditions, because the Eifel ones have that option. Just a few days ago I had "lots and lots" of water on my own track (Eifel Flat).
 
Implemented manual polygon creation (click on the canvas to add a point) and it looks promising already. These are all default 90 meter radius corners, and still it looks like a pretty nice track. This polygon has 13 points (in grey and light blue), to compare to the 24 anchors you'd have to carefully place to create this in the TPE app.

Also, note that you can easily create increasing/decreasing radius corners (see bottom left corner) by adjusting the angle between the vectors.

Skärmbild (15).png
 
Nice work @eran0004, had a similar idea of track creation in the beginning days of the ted-editor, but i went to biarcs as i wanted to keep as close to the TPE as possible. It's great to have a different editing method, maybe it's even possible to combine them and use them for different track parts.
Have you thought already how to export the segments to the ted file? I guess you can add the arcs directly by using the Arc1 clockwise/anticlockwise types for the control points, so there would be no corresponding Arc2 like with the TPE in your exported ted files. In this case i have to adapt my import routine as i expect that each Arc1 is followed by an Arc2. No big deal, i can add a check and build a biarc just from an Arc1 if there is no Arc2, we just have to make sure that your new arcs are easily and uniquely identified in a ted file.
 
I will eventually complete GT6's career mode one day. When the servers are turned off, and I can no longer fully enjoy what has become the game I've gotten the most involved/lost in ever, I rarely go more than 2/3 days without driving/messing with a track. Because if for no other reason, @Razerman,@eran0004, @tarnheld, @Mr Grumpy - in fact all of you who have made a contribution - your collective coding skills and sheer creative genius humbles me beyond words. The effect that @PR1VATEJ0KER's "Devils Elbow" had was like dropping a boulder in one of Norway's vast and very beautiful fjords, releasing an incredible amount of energy, the first mods were the ripples created, and ripples grow, BUT.....
YOU guys have been the energy behind those ripples.... :gtpflag:

Thank You :bowdown:
 
Last edited:
Nice work @eran0004, had a similar idea of track creation in the beginning days of the ted-editor, but i went to biarcs as i wanted to keep as close to the TPE as possible. It's great to have a different editing method, maybe it's even possible to combine them and use them for different track parts.
Have you thought already how to export the segments to the ted file? I guess you can add the arcs directly by using the Arc1 clockwise/anticlockwise types for the control points, so there would be no corresponding Arc2 like with the TPE in your exported ted files. In this case i have to adapt my import routine as i expect that each Arc1 is followed by an Arc2. No big deal, i can add a check and build a biarc just from an Arc1 if there is no Arc2, we just have to make sure that your new arcs are easily and uniquely identified in a ted file.

I guess the arcs can simply be split in two (arc1, arc2), so it shouldn't be a big problem when exporting to the ted format.

It should be possible to combine the editing modes. The cornerpoint needed for this polygon editing mode can be recreated by tracing the vectors of the two ancors of the corners. A problem occurs when the corners is 180 degrees or more (as the vectors would never cross under those circumstances), in those cases it would need to be split into multiple corners.
 
I will eventually complete GT6's career mode one day. When the servers are turned off, and I can no longer fully enjoy what has become the game I've gotten the most involved/lost in ever, I rarely go more than 2/3 days without driving/messing with a track. Because if for no other reason, @Razerman,@eran0004, @tarnheld, @Mr Grumpy - in fact all of you who have made a contribution - your collective coding skills and sheer creative genius humbles me beyond words. The effect that @PR1VATEJ0KER's "Devils Elbow" had was like dropping a boulder in one of Norway's vast and very beautiful fjords, releasing an incredible amount of energy, the first mods were the ripples created, and ripples grow, BUT.....
YOU guys have been the energy behind those ripples.... :gtpflag:

Thank You :bowdown:

Now it's a unstoppable tsunami from which there's no escape lol :)
 
The code is there, but it still needs a better user interface.
Something like Photoshop.
Like this?
adobe-photoshop-1-07.jpg
Or do you like the big userbase helping you where they can with nice tutorials:

:P
Ok seriously, these tools aren't made by a big company with a whole department for UI, but by some enthusiasts in their spare time. If you have constructive proposals for the UI don't hesitate to ask, maybe your wish can be granted. :)👍
 
Yeah, user interface is tricky. Making something that works is hard enough, but making something that works and is intuitive to use is even harder :lol:

Edit: While on the topic of Photoshop and as an example of the complexity of user interfaces, here is an Adobe Illustrator-inspired function that only deals with left-click vertices selection.

Code:
def leftClick(event):
    global selectedPoints, MouseLocation
    MouseLocation = event
    #test if click is done on a polygon point
    pointIndex = getPointIndex(event)   
    if pointIndex != None:              #If click is done on a polygon point   
        if len(selectedPoints) < 2 or pointIndex not in selectedPoints:     #If less than two points already selected
            selectedPoints = [pointIndex]

    elif len(selectedPoints) > 0:       #If click is not on a point and a point is already selected
        selectedPoints = [] 

    else:                                #if no point is already selected, add a point at the location   
        polygon.append([w.canvasx(event.x), w.canvasy(event.y), 90])
 
Last edited:
I have been looking at Mr Grumpy's ROAD and DECORATION codes and was a bit puzzled as to why so few objects are distinguished with such a large code. The codes listed are 8 bytes long, meaning we could have up over 18.4 x 10^18 (18.4 pentillion!) different objects. Digging into this issue, I have found that they can be greatly simplified because most of the data in the codes is redundant. When I converted all of the codes into 8 byte hexidecimal, it became immediately clear that 6 of the 8 bytes are constant, meaning that all objects can be represented with only 2 bytes. (This is not strictly true, but continue reading below for an explanation.) For the Eifel / Eifel Flat ROAD data for example, the "Normal Road" is represented by hex code A36924BE050DCAC8 and the "Forest Road" is represented by AF5B24BE050DCAC8. Only the first four digits (2 bytes) change. In fact, for all of the ROAD data in Eifel / Eifel Flat, all ROAD codes end in the following 12 digits (6 bytes): 24BE050DCAC8. Looking at the DECORATION codes, the same trailer is used for all of those as well! To make it easier for me to discuss, I will call these last 6 bytes a "trailer."

Looking at Andalusia ROAD and DECORATION data however, there is a bit of a difference. Here we find 3 different trailers in use: 0024E8474511, B8AC6F879E55, and F0921CF30B58. (The last of the three trailers is, however, not used in the DECORATION data). So, the trailer is not strictly a "constant" but some other type of variable that only has 4 possible values (I haven't examined any codes for Death Valley, so I expect there will be a few more). What similarities exist among objects that use the same trailer? I don't yet see an obvious answer.

My Custom Track Editing Guide is coming along nicely, but I still have lots of questions. I will bring them up when I get the chance.
 
@Kornepheros if you figure out how to get a working pit lane on the opposite side of the track while investigating these codes, I will personally bring you a box of cookies to your door :) Where do you live ?........... ooohhhh the States, Edit: I will personally send you a box of cookies lol :)
 
@Kornepheros if you figure out how to get a working pit lane on the opposite side of the track while investigating these codes, I will personally bring you a box of cookies to your door :) Where do you live ?........... ooohhhh the States, Edit: I will personally send you a box of cookies lol :)
I do like cookies, but I think it is going to take a lot more experimentation before we can figure that out (or rule out the possibility). There do seem to be a few values that have not been explained completely yet, so lets keep on experimenting!

Let me post what I've written in the guide so far concerning ROAD and DECORATION sections of the TED file. Advice, comments, and suggestions are greatly welcome!

ROAD SECTION
A ROAD entry is a 20-byte entry containing the type of road mesh to use and where to use it. Each entry consists of 5 components:

1. ID
This 2-byte component contains a value that identifies the type of road mesh to use. This component seems to be identical in usage to the ID component used in the DECORATION SECTION. It seems likely that each ID must be paired with the proper Trailer component (see below) in order to get the desired unique road mesh.

2. Trailer
This 6-byte component contains a value of unknown purpose, and seem to be identical in usage to the Trailer component used in the DECORATION SECTION. It seems likely that these must used in conjunction with the ID component to determine each unique road mesh. These seem to be unique to each scenery area, which means if you want to migrate a track from one scenery area to another (e.g. from Andalusia to Eifel), you will probably need to change these as well. The following Trailer values (in hex) are known to be in use:
  • 24BE050DCAC8 - Eifel / Eifel Flat
  • 0024E8474511 - Andalusia
  • B8AC6F879E55 - Andalusia
  • F0921CF30B58 - Andalusia
Although the ID and Trailer components seem to be used the same way they are used in the DECORATION SECTION, I don’t know if this has been tested. See that section below for more questions about these values.

3. Flag
This 4-byte component is used in a couple of different ways, depending on the type of road mesh being used. For Start/Finish road meshes, the flag defaults to a value of 2. Changing this value to 0 enables them to match the selected track width. For other road meshes, a value of 0 or 1 can be used to determine the flip orientation of the mesh. Might a value of 1 flip the orientation of Start/Finish road meshes like it does with the other road meshes?

4. Start Position
This 4-byte component contains the start position for the road mesh. The first road mesh used should start at position 0. The second road mesh should start at the same position that the first road mesh ended, and so on for each entry.

5. End Position
This 4-byte component contains the end position for the road mesh. The last road mesh used should end at position 0 to meet up with the beginning of the first road mesh used. No position should exceed the length of the track, and the distance between the start and end positions should probably remain near the default values.

Do these entries need to be listed in the proper order? For example, could you switch the first and last entries and still make it work? Also, what are the limits on start and end positions? Are there size limits? Can you start start and end at a position that is different than position 0? What happens if you leave a gap between road meshes, or if you cause some overlap? What happens if the start and finish positions are equal, or if the finish position is less than the start position? What effect does stretching or shrinking the distance between the start and end positions look like out on the track?

DECORATION SECTION
A DECORATION entry is a 24-byte entry containing the type of decoration to use and where to use it. Each entry consists of 6 components:

1. ID
This 2-byte component contains a value that identifies the type of decoration to use. This component seems to be identical in usage to the ID component used in the ROAD SECTION. It seems likely that each ID must be paired with the proper Trailer component (see below) in order to get the desired unique decoration.

2. Trailer
This 6-byte component contains a value of unknown purpose, and seem to be identical in usage to the Trailer component used in the ROAD SECTION. It seems likely that these must used in conjunction with the ID component to determine each unique road mesh. These seem to be unique to each scenery area, which means if you want to migrate a track from one scenery area to another (e.g. from Andalusia to Eifel), you will probably need to change these as well. The following Trailer values (in hex) are known to be in use:

  • 24BE050DCAC8 - Eifel / Eifel Flat
  • 0024E8474511 - Andalusia
  • B8AC6F879E55 - Andalusia
NOTE: Code F0921CF30B58 - Andalusia, used in the ROAD SECTION, in not known to be used for decorations.

I have found two decorations that have the same ID value but different Trailer values (“Trees” ID: ADBF Trailer: B8AC6F879E55 used in Andalusia and “Right Curbing” ID: ADBF Trailer: 24BE050DCAC8 used in Eifel / Eifel Flat). This means that ID values must either be linked to a specific scenery area, or to a specific Trailer in order to provide a unique handle for a decoration. I suspect the ID and Trailer must always be paired up correctly, and the Trailer must be used for the scenery area for which is has been designed. But I do not have any proof for any of this.

3. Flag
This 4-byte component is used to determine which side of the track the decoration appears on (its flip orientation).

4. Start Position
This 4-byte component contains the start position for the decoration.

5. End Position
This 4-byte component contains the end position for the decoration. No position should exceed the length of the track. The distance between the start and end positions can be changed from the default values, but the decorations will appear to stretch or shrink accordingly when viewed in the game.

Do these entries need to be listed in a certain order? What happens if you try to place more than one decoration in the same location? Can decorations overlap a little, or not at all? Also, what are the limits on start and end positions? Are there size limits? What happens if the start and finish positions are equal, or if the finish position is less than the start position?

6. ItemTrack
This 4-byte component seems to be used to specify TRACK TYPES and/or RAIL TYPES. I do not understand these types yet...
 
Progress update: Zoom functionality added! Next step is probably to build the export-to-ted function and then test-fire this thing for real.

Skärmbild (18).png


Do these entries need to be listed in the proper order? For example, could you switch the first and last entries and still make it work? Also, what are the limits on start and end positions? Are there size limits? Can you start start and end at a position that is different than position 0? What happens if you leave a gap between road meshes, or if you cause some overlap? What happens if the start and finish positions are equal, or if the finish position is less than the start position? What effect does stretching or shrinking the distance between the start and end positions look like out on the track?

I don't think that they need to be listed in the proper order, other than for your own sanity. If they're not in order it's going to be really hard to check that the entire track is covered by the road items.

Stretching or shrinking (at Eifel) the positions extends the particular section. It doesn't seem to scale or distort it from what I can see.

Do these entries need to be listed in a certain order? What happens if you try to place more than one decoration in the same location? Can decorations overlap a little, or not at all? Also, what are the limits on start and end positions? Are there size limits? What happens if the start and finish positions are equal, or if the finish position is less than the start position?

They do not need to be listed in a certain order, so you can choose yourself if you prefer to sort by distance or by item type (for instance, grouping all trees together, grouping all houses together, etc.). Decorations can overlap freely, there is no restriction other than that it might look ugly if a mesh clips through another mesh. Size limits: Each prop (on Eifel at least) has an ideal size and if you make them longer or shorter the mesh will be distorted, either stretched out or squeezed together. They do not expand like the road items seem to do.

Edit: For both road and decoration items it's worth noting that some of these items consists of three parts: a start, a middle and an end (for instance the banked forest at Eifel). Typically, they appear with one of each, but you can choose to place several middle sections before you place an end, or you can choose to omit the middle section entirely and just use the start and end items.
 
Last edited:
I'm hoping that we can add functionality to the ted-editor that will automatically convert from one scenery area's ROADs and DECORATIONs to anothers and vice verse. I would think a simple conversion table, and simple replacements would be able to handle most (perhaps all) of that?
 
I'm hoping that we can add functionality to the ted-editor that will automatically convert from one scenery area's ROADs and DECORATIONs to anothers and vice verse. I would think a simple conversion table, and simple replacements would be able to handle most (perhaps all) of that?

A conversion table should do the trick. As some props have different lengths an additional function to close gaps / remove overlaps might be needed as well.
 
Back