SG files and new editing tools

[checkpoint10]

Over on the NASCAR forum I was looking into gaps between the x,y,z coordinates at the last DLONG of one section vs the first DLONG of the next section, noting that most gaps are from 1-20 500ths different, but a particular trouble spot was off by 620.

I ran this script on Surfers where I have heard multiple accounts of crashes near the pit exit (although I have not experienced this myself), and found something similar:

Sect DLONG Distance
0 0 5.302346315937229
1 2620068 1.0000025007337898
2 3262817 1025.1238664796206
3 3553662 2033.9019435262555
4 3914938 1.000007109874225
5 5485124 1.0000000064827383
6 7320824 1.000000861724935

...

I am not including the rest of the data but most of the gaps are less than 10. Obviously the transition between S1/S2 and S2/S3 stand out as having major gaps almost 100x normal. Could this be why the game crashes a lot near pit exit there?

The solution would involve doing the math to figure out the best fit curve and line segment that would connect to each other closer. Those of you with experience with SGE have probably observed that SGE has a way to connect segments that are slightly misaligned, usually by adjusting a line segment or radius. So I think I can try to write a script that goes through these problem spots and try to close the gap... and hopefully to do it in such a subtle way that we wouldn't have to recreate the 3DO file.

[Pavel 69]

GTKmaker - 'SGE/SFE' tool for making GPL tracks shows DLAT and DLONG gap between sections. And it's good practice there to check whole track for gaps and try to minimize them. Our SGE and SFE tools don't have such feature and gaps may exist at some tracks especially at parts were several curved sections with various radius were placed one after another.

So I think it may be good to have some tool that will check trk files for the gaps and report if something is found.

[checkpoint10]

Here is something I made using ChatGPT - this took a lot of back and forth between myself and ChatGPT resolving bugs. It is a Python program that draws a track based on a TRK file, allows you to zoom in/out and drag the view, and then place a crosshair anywhere on the map, and it tells you in the status bar where you put it.

One problem I have, though, is that the code is somewhat beyond my actual skill as a programmer, and I think I need to stop and understand what I made before I would feel comfortable adding anything else to it. I don't have any real experience with creating a program with a UI so there is a big learning curve.

[samsepi0l]

It looks like belle isle, but from underneath point of view.

Very cool potential here.

What you described it pretty much how I feel whenever I program something and ask for help.

[checkpoint10]

It looks like belle isle, but from underneath point of view.

Ha, I didn't notice it was flipped! I thought it was just rotated. I'll let ChatGPT know to fix it :-p

[checkpoint10]

Useless fact of the day! Comparison of how SGE and SFE recolor your PCX.



Top: original grayscale pcx file
Middle: SGE (7 colors, darker)
Bottom: SFE (4 colors, original brightness)

[Pavel 69]

I usually make b/w track pcx very bright and increase contrast to work in SGE and SFE. When it doesn't help to see track edges then in paint program I draw contrast line around such places But yes, SGE and SFE use some weird method to display pcx images.

[samsepi0l]

the problem with historic-aerials is the watermark always makes seeing harder in SFE/SGE