- 11,229
- Sweden
- eran0004
The easiest solution is to create an elevation profile:
0,-155
1000,-155
Load that and it will show you the Eifel Flat ground level.
Modified Track Path Editor + Tracks/Discussion
- Thread starter The Chosen One
- 1,982 comments
- 191,769 views
The easiest solution is to create an elevation profile:
0,-155
1000,-155
Load that and it will show you the Eifel Flat ground level.
- 2,574
- United Kingdom
A few questions about int flags on road structures.
1 = why is the S/F straight (on any theme) on int flag 2 when the rest of the track are set at int flag 0 ? (I know the answer to this 1 sorry)
2 = what is the default width of int flag 2 ?
3 = can the default width be changed ?
4 = where can it be found ?
The reason for asking is..... I may have found a way to have different width for different sections of track (well 2x different widths anyway).
However using int flag 2 on any section of track makes it too narrow (about 8m) so I've been fiddling but found nout. Any idea's chap's
1 = why is the S/F straight (on any theme) on int flag 2 when the rest of the track are set at int flag 0 ? (I know the answer to this 1 sorry)
2 = what is the default width of int flag 2 ?
3 = can the default width be changed ?
4 = where can it be found ?
The reason for asking is..... I may have found a way to have different width for different sections of track (well 2x different widths anyway).
However using int flag 2 on any section of track makes it too narrow (about 8m) so I've been fiddling but found nout. Any idea's chap's
- 2,228
- Bielefeld
- tarnheld
However using int flag 2 on any section of track makes it too narrow (about 8m) so I've been fiddling but found nout. Any idea's chap's
The flag 2 is a mystery, but i suspect the two track_width values in the header to play part in it, they come straight after the road_width and maybe they set the width for flag=2 segments. Just a guess, haven't tested anything of it. For the record here is a description of the header: (i/I 4 byte integer, f: 4 byte float, 8s: string of 8 bytes, 8x: unused padding of 8 bytes)
Code:
8s:id
i:version
i:scenery
f:road_width
f:track_width_a
f:track_width_b
f:track_length
I:datetime
i:is_loop
8x:
f:home_straight_length
f:elevation_diff
i:num_corners
f:finish_line
f:start_line
8x:
I:cp_offset
i:cp_count
I:empty1_offset
i:empty1_count
I:empty2_offset
i:empty2_count
I:empty3_offset
i:empty3_count
I:bank_offset
i:bank_count
I:height_offset
i:height_count
I:checkpoint_offset
i:checkpoint_count
I:road_offset
i:road_count
I:decoration_offset
i:decoration_count
8x:
- 32
- United States
- Kornepheros
I have some TED file questions and comments about the FORM TYPE flag for CP entries. I'd like to know what experiments have been done with these so far. I suspect that there are forum postings with some of this information, so pointing me to those would be helpful.
1. I've noticed that in all of our available editors, corners are defined by of a pair of CP points (i.e. a pair of arcs). There doesn't seem to be any particular need for this. Does the GT6 program require that every FORM_ARC_1ST is followed by a FORM_ARC_2ND? Has anyone experimented with making single-CP-point (i.e. single-arc) corners? If you think about it, eran0004's new alternative editor essentially simulates single-arc corners because it treats both halves of a corner as halves of a single arc. In order to get the same functionality as the TPE or the ted-editor (which use twin-arc corners), two separate corners (and thus four CP points) would need to be used. I like eran0004's new method as I feel it gives me more control (corners in the other editors are more "squirmy"), but it would be even better if we could use a single CP point (one arc) for a corner if desired.
2. What happens if you put non-zero values for the second set of coordinates in a FORM_STRAIGHT entry? I'd assume it gets ignored as GT6 probably uses the FORM TYPE flag to decide whether or not to bother looking at the second set of coordinates. But has anyone performed an experiment this to verify? The reason I ask is because the program may not use the FORM TYPE to determine if a CP entry is a curve or a straight - it may check the second set of coordinates for non-zero values instead. Maybe the FORM TYPE is used for other reasons? (For example, see the next question.)
3. What is the purpose of FORM_NEARLY_STRAIGHT (value=3)? I have to assume that these are actually curves, just like the ARC forms, but why does GT6 need to know that a curve is "nearly straight"? Does GT6 use different options when displaying ROAD or DECORATION entries depending on whether it is a curve or a straight? Maybe the FORM_NEARLY_STRAIGHT type is used to tell GT6 that although it is a curve, it should be handled like a straight stretch when placing ROAD or DECORATION entries? (When thinking about this, I also couldn't help but remember eran0004 talking about the algorithm he used to determine if a corner was sharp enough to be counted as a corner in his new alternative editor.)
4. There seems to be a clockwise and counterclockwise component involved in the FORM TYPE. I've noticed in Razerman's hex editor template that he includes a FORM_ARC_1ST_CLOCKWISE and FORM_ARC_2ND_CLOCKWISE. But the only difference between the values used for these and the values used for FORM_ARC_1ST and FORM_ARC_2ND are that the hex value 80 00 00 00 has been added. So I propose dividing the 4-byte FORM TYPE value into two separate values: A single-byte "Direction" value which would be "0" for counterclockwise and "80" in hex (or "128" in decimal) for clockwise. This is followed by a 3-byte value that can be "straight" (value=0), "arc 1" (value=1), "arc 2" (value=2), or "nearly straight" (value=3). Does anyone have any idea why clockwise or counterclockwise matters to the GT6 program? Like question #3 above, might it have something to do with displaying ROAD or DECORATION items?
1. I've noticed that in all of our available editors, corners are defined by of a pair of CP points (i.e. a pair of arcs). There doesn't seem to be any particular need for this. Does the GT6 program require that every FORM_ARC_1ST is followed by a FORM_ARC_2ND? Has anyone experimented with making single-CP-point (i.e. single-arc) corners? If you think about it, eran0004's new alternative editor essentially simulates single-arc corners because it treats both halves of a corner as halves of a single arc. In order to get the same functionality as the TPE or the ted-editor (which use twin-arc corners), two separate corners (and thus four CP points) would need to be used. I like eran0004's new method as I feel it gives me more control (corners in the other editors are more "squirmy"), but it would be even better if we could use a single CP point (one arc) for a corner if desired.
2. What happens if you put non-zero values for the second set of coordinates in a FORM_STRAIGHT entry? I'd assume it gets ignored as GT6 probably uses the FORM TYPE flag to decide whether or not to bother looking at the second set of coordinates. But has anyone performed an experiment this to verify? The reason I ask is because the program may not use the FORM TYPE to determine if a CP entry is a curve or a straight - it may check the second set of coordinates for non-zero values instead. Maybe the FORM TYPE is used for other reasons? (For example, see the next question.)
3. What is the purpose of FORM_NEARLY_STRAIGHT (value=3)? I have to assume that these are actually curves, just like the ARC forms, but why does GT6 need to know that a curve is "nearly straight"? Does GT6 use different options when displaying ROAD or DECORATION entries depending on whether it is a curve or a straight? Maybe the FORM_NEARLY_STRAIGHT type is used to tell GT6 that although it is a curve, it should be handled like a straight stretch when placing ROAD or DECORATION entries? (When thinking about this, I also couldn't help but remember eran0004 talking about the algorithm he used to determine if a corner was sharp enough to be counted as a corner in his new alternative editor.)
4. There seems to be a clockwise and counterclockwise component involved in the FORM TYPE. I've noticed in Razerman's hex editor template that he includes a FORM_ARC_1ST_CLOCKWISE and FORM_ARC_2ND_CLOCKWISE. But the only difference between the values used for these and the values used for FORM_ARC_1ST and FORM_ARC_2ND are that the hex value 80 00 00 00 has been added. So I propose dividing the 4-byte FORM TYPE value into two separate values: A single-byte "Direction" value which would be "0" for counterclockwise and "80" in hex (or "128" in decimal) for clockwise. This is followed by a 3-byte value that can be "straight" (value=0), "arc 1" (value=1), "arc 2" (value=2), or "nearly straight" (value=3). Does anyone have any idea why clockwise or counterclockwise matters to the GT6 program? Like question #3 above, might it have something to do with displaying ROAD or DECORATION items?
Last edited:
- 11,229
- Sweden
- eran0004
Single CP-point corners work just fine. They're always divided in the TPE app, but there is no need for that if you want a constant radius turn. The ted-editor requires double CP-point corners though, I believe.
Nothing happens, those coordinates are only used for corners (remember that the coordinates reads (0,0) rather than (None, None)).
The nearly straight draws a straight between the CP and the previous CP. I assume that it's used when the corner angle is very small.
My corner determination algorithm is purely used to count the number of corners of the track, I'm not using the nearly straight form type.
Clockwise turns goes to the right, counter-clockwise goes to the left. If you replaced a clockwise turn with a counter-clockwise turn you'd probably end up with an inverted corner, i.e. instead of 90 degrees to the right you'd get 270 degrees to the left:
Last edited:
- 198
- Essex
- Peemo72
public void ButtonToABTrackMode()
{
if (StaticObj.m_isCurbMode)
{
StaticObj.m_isCurbMode = false;
this.ToABTrackMode();
}
}
public void ButtonToCurbMode()
{
if (!StaticObj.m_isCurbMode)
{
StaticObj.m_isCurbMode = true;
this.ToCurbMode();
}
}
Could it be relating to deco objects?
It could explain why there appears to be no difference when the values are changed as they're prefabs(?).
{
if (StaticObj.m_isCurbMode)
{
StaticObj.m_isCurbMode = false;
this.ToABTrackMode();
}
}
public void ButtonToCurbMode()
{
if (!StaticObj.m_isCurbMode)
{
StaticObj.m_isCurbMode = true;
this.ToCurbMode();
}
}
Could it be relating to deco objects?
It could explain why there appears to be no difference when the values are changed as they're prefabs(?).
- 769
- Tampa, FL
- NingDynasty
Last edited:
- 11,229
- Sweden
- eran0004
- 2,574
- United Kingdom
This int flag stuff has given me a great idea 💡 & it's working .
Creating a fun (test) track now based off my deep canyon track.
Watch this space.
Hopefully have it up in 30min (got delayed)
EDIT: Check this out.
I call it Trial River Rally X lol
https://www.gran-turismo.com/us/gt6/user/#!/friend/Mr-6rumpy1/course/2683832/
Room open.
.Creating a fun (test) track now based off my deep canyon track.
Watch this space.
Hopefully have it up in 30min (got delayed)
EDIT: Check this out.
I call it Trial River Rally X lol
https://www.gran-turismo.com/us/gt6/user/#!/friend/Mr-6rumpy1/course/2683832/
Room open.
Last edited:
- 11,229
- Sweden
- eran0004
This int flag stuff has given me a great idea 💡 & it's working
Creating a fun (test) track now based off my deep canyon track.
Watch this space.
Hopefully have it up in 30min (got delayed)
EDIT: Check this out.
I call it Trial River Rally X lol
https://www.gran-turismo.com/us/gt6/user/#!/friend/Mr-6rumpy1/course/2683832/
Room open.
Nice one! I could swear that I heard a splash when I drove through the water
- 2,574
- United Kingdom
- 11,229
- Sweden
- eran0004
Actually I didn't notice that, but on the other hand I'm driving a Fiat 500 so it's not really a problem for me
What about Eifel? The pit straight is fairly wide there.
Edit: Made some changes to the way the banks are calculated. They're a bit smoother now.
Here is the algorithm for calculating the shift distance and the bank angle for each bank:
Code:
for index, bank in enumerate(BANKS):
prev_bank = BANKS[index-1]
prev_vlen = prev_bank['vlen']
vlen = bank['vlen']
min_vlen = min(prev_vlen, vlen)
shift = min_vlen*1/3
if shift > 20:
shift = 20
prev_bank['m_shiftNext'] = shift
bank['m_shiftPrev'] = shift
bank['m_bank'] = shift*1/6*bank['corner']The shift length is calculated by comparing the vlen of the current bank and the previous bank. The shift distance is defined as 1/3 of the shortest vlen (capped at 20 meters). So the bank is approximately 1/3 transitioning from the previous bank angle to the current bank angle, 1/3 current bank angle and 1/3 transitioning from the current bank angle to the next bank angle.
The angle is defined as 1/6th of the shift length multiplied by a corner indicator (-1 for left turns, 0 for straights and 1 for right turns). This makes the angle shallower for corners with shorter shift length and gives a very smooth transition.
If you want to try steeper bank angle you can make the angle factor (the "1/6" in "shift*1/6*bank['corner']") greater. It's on line 140 currently.
For instance:
angle factor 1/6 = bank angle 3.3 degrees or less (20*1/6)
angle factor 1/4 = bank angle 5 degrees or less (20*1/4)
angle factor 1/2 = bank angle 10 degrees or less (20*1/2)
angle factor 1 = bank angle 20 degrees or less (20*1)
angle factor 2 = bank angle 40 degrees or less (20*2)
angle factor 10 = you should probably not try this. (20*10)
I also changed the default scenery from Eifel to Eifel Flat, because racing at ground level is better than racing in the sky
Here is a track I made, you can try it out to get a feeling for how the curbs work.
https://www.gtplanet.net/forum/resources/scania-ring.5695/
Last edited:
- 32
- United States
- Kornepheros
- 2,574
- United Kingdom
Excellent work Mr Grumpy! I think the narrow road would still be fine for racing. Pikes Peak Hill Climb racing side by side sounds pretty cool.
I noticed you can't spend too much time in the water or you get reset.
Yeh you don't get long in the water, but I did try going for drive in the river lol.
@eran0004 Eifel is where I first played around with the int flags as I was experimenting with my Monza 1960 track (trying to recreate the shared S/F straight). The problem with Eifel is yes the pit is wider but has less grass so when we use normal road you get alot of grass either side so the road is a lot thinner.
I'll get a monza test up later, show you guys what I'm attempting & whether you think I'll get away with 8m road.
Last edited:
- 769
- Tampa, FL
- NingDynasty
I have to say @Mr Grumpy you are doing amazing work. I just tried out your Trial River Rally X and the concept you have there is brilliant.
However. Highlands... that's really a different level. Quite possibly the best looking and most complex creation to date. I really don't think it's close. Really amazing stuff.
However. Highlands... that's really a different level. Quite possibly the best looking and most complex creation to date. I really don't think it's close. Really amazing stuff.
- 2,574
- United Kingdom
Thank's mate
Not having alot of luck with monza though atm, I actually fell asleep with the keyboard on my lap last night lol,
- 769
- Tampa, FL
- NingDynasty
- 11,229
- Sweden
- eran0004
Here is version 1.0 of the Course Layout creator.
What's this?
This is a community-created course maker for GT6. It's intended to be a fast and easy way to create complex layouts. To do that you build a polygon frame, to which the track is then generated, by rounding off the corners. The polygon frame allows you to control the track with relatively few points and you don't have to worry about reshaping the corners every time you move a control point.
Update 2017-02-12: Version 1.1 uploaded.
Update 2017-02-13: Version 1.2 uploaded.
What's this?
This is a community-created course maker for GT6. It's intended to be a fast and easy way to create complex layouts. To do that you build a polygon frame, to which the track is then generated, by rounding off the corners. The polygon frame allows you to control the track with relatively few points and you don't have to worry about reshaping the corners every time you move a control point.
- Python 3
- Windows (other OS might work, but has not been tested)
- Mouse with scrollwheel.
- File -> Save polygon: saves the polygon data as a .pgn file.
- File -> Load polygon: loads a .pgn file.
- File -> Export to TED: generates a ted file from the polygon.
- Append point at the end: With no points selected, click on the canvas to add a point at the location.
- Insert point on a line: With no points selected, click on a line to insert a point on the line.
- Delete point(s): Select the point(s) you want to delete, then press <delete>.
- Selection: Click on a polygon point to select it. Hold shift to add to selection.
- Select all: Press <a> to select all points.
- Deselect all: Press <escape> to deselect all points.
- Move point: Click on a point and drag.
- Move points: Select the points you want to move, then click on one of the selected points and drag.
- Change turn radius: Right click on a point and drag up/down.
- Change turn radius for multiple points: Select the points, then right click on one of the selected points and drag up/down.
- Scale: Select the points you want to scale and press <s>. Click and drag up/down to scale. Press <escape> to stop scaling.
- Rotate: Select the points you want to rotate and press <r>. Click and drag to rotate. Press <escape> to stop rotating.
- Close / open circuit: Press <j>.
- Pan the view: Right-click on the canvas and drag to pan the view.
- Zoom in/out: Use the scrollwheel.
- Currently only supports closed circuits. Point-to-point tracks does not work.
- Currently only supports Eifel Flat.
- Save polygon does not save the road width setting.
- Load polygon does not automatically close the circuit. You have to do it manually (press <j> for join).
- Track length is not calculated when Labels are hidden.
- Help and Edit menus are currently disabled.
- Curbs, decorations and alternative road sections are not included (but can be added manually to the file with hex editing).
v 1.0
v 1.2
v 1.2
Update 2017-02-12: Version 1.1 uploaded.
- The mouse wheel no longer rotates / scales the polygon when in rotating/scaling mode. Instead it correctly zooms in/out.
- When zooming, the canvas is locked to the position of the cursor.
- Rotation has been improved.
- Sliders for camber angle (degrees) and camber change rate (degrees per meter) has been added.
Update 2017-02-13: Version 1.2 uploaded.
- Flip the direction of the track by pressing <f>.
- Limit scaling to a single axis: Press <x> or <y> while in scaling mode to scale only along that axis. Press the same key again to scale along both axes.
- Mirror the selected points: Press <m> to toggle mirroring mode, then press <x> or <y> to set the mirroring direction. The points are mirrored around the selection center.
Last edited:
- 32
- United States
- Kornepheros
So the center-of-arc values are not used when using the "Nearly Straight" track type? Then is there any known difference between a "Straight" and a "Nearly Straight"?
I've been assuming that the type contained in a CP entry was used to draw a track segment to the following CP, but you wrote that it is used to draw to the previous CP. Could you please verify which is correct?
Interesting idea. Has this been tested? Might it be useful for creating tight corners?
- 32
- United States
- Kornepheros
Very nice!
First bug/feature report:
1. When you use the mouse scroll wheel while in rotate (or scale) mode, the track rotates (or scales) while you zoom in/out.
2. You can press 'r' (or 's') a second time to exit rotate (or scale) mode, along with being able to press 'ESC'.
3. Zooming in with the scroll wheel doesn't take you to the cursor.
I noticed that you use two control points for each corner. Is this to maintain compatibility with the ted-editor, or is there another reason?
Last edited:
- 11,229
- Sweden
- eran0004
Well, straights have to be followed by a corner or a nearly straight, while nearly straights can be followed by anything. That's in the app at least, not sure if there is any difference in the game.
The x and y coordinates are for the end of the segment, so the road is drawn from the previous CP to the current CP.
I haven't tested it. I don't really know what would happen. The thing is that as the road continues forwards but in the mirrored direction, the left side of the road actually becomes the right side and vice versa. It could cause a lot of headache.
Grippy
(Banned)
- 381
- Australia
Such a lot of progress made by you guys!! wow!! I can see we will be able to see lots of new replicas with near identical tracks with 1:1 elevations also in the database soon! If you haven't tried eran's track with the minute bumps and elevations in it, I highly recommend it, it really feels like a oldschool premium racetrack! Almost makes me want to make some tracks again. Just well done. https://www.gtplanet.net/forum/thre...racks-discussion.337816/page-30#post-11593320
eran0004 do you have a copy of that Figure 8 jump track? I looked through and it appears all of them were deleted from your page? Would be really cool to test it for the first time, I'm a bit late to the party lol
eran0004 do you have a copy of that Figure 8 jump track? I looked through and it appears all of them were deleted from your page? Would be really cool to test it for the first time, I'm a bit late to the party lol
Last edited:
Grippy
(Banned)
- 381
- Australia
