Forums

Full Version: Nashville Street Circuit (WIP thread)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
(10-15-2021, 05:23 AM)samsepi0l Wrote: [ -> ]Pavel- I know it has been a long time, but when you built miami95, did your chicane have the same style creation where it was not a corner, rather just a lane-change in SFE, like this?
Yes, it's not a corner there.

There are tqo tools LPEdit (or Edit45) - old one by Robert and AIEdit - newer by Nigel. And as I wrote it's pretty easy manually restore bad racing line parts  in AIEdit. So don't afraid to see errors from Trafo. Generate lp, open it in AIEdit, adjust racing line in damaged parts, adjust speeds in LPEdit, generat coriolis (latereal speeds) in LPEdit and test lp files in game.
I think, the difference is, through a small chicane you can drive diagonal and have a lower angle to the centerline. In Nashville there is a real straight between the two corners of the chicane and you drive almost in 90 degrees angle to the centerline.
(10-15-2021, 05:45 AM)Dennis Wrote: [ -> ]I think, the difference is, through a small chicane you can drive diagonal and have a lower angle to the centerline. In Nashville there is a real straight between the two corners of the chicane and you drive almost in 90 degrees angle to the centerline.

My thoughts exactly.... when I made multiple replay attempts I slowed down to an absolute crawl trying to minimize the coriolis... it was very low in record 37 before the record 38 which is where I get the garbage data.  My coriolis was only about 4, or 5 or so in record 37. 

(remember the garbage data screws-up the whole lap mostly- making most of the replay unusable)

I really want to understand how RPY files store data so we can maybe develop a new tool.

Do they store the X,Y position of the car, or is it more like DLONG/DLAT?
(10-15-2021, 06:01 AM)samsepi0l Wrote: [ -> ]Do they store the X,Y position of the car, or is it more like DLONG/DLAT?
Without looking at the file, I would say, DLONG/DLAT. X/Y is for graphics only.
Maybe this file will help with understanding the RPY file and perhaps a new tool if needed: http://www.simcyberworld.com/text/bbb/i2replay.txt
(10-15-2021, 10:12 AM)checkpoint10 Wrote: [ -> ]Maybe this file will help with understanding the RPY file and perhaps a new tool if needed: http://www.simcyberworld.com/text/bbb/i2replay.txt

I just spent an hour reading and playing with my calculator and hexed.it.

I see the first line of my replay corresponds. When the car is sitting in the pits it has a linear position of roughly 60,509,020 dlong. This is what the replay shows. I know Nashville is 66,031,337 DLONGs long, so I think that sounds about right. I am using a conversion factor of 260 "DLONGS" is one "replay unit".

What do you have the players pit position as in the nash.txt file? My guess is it's darn close to 60,509,020. I don't have that computer on now to check.
The player pit is at DLONG 59578188 and DLAT 428250 according to the nash.txt file.

I started building out a tool using your replay file, and I see that the car starts at a "replay DLONG" of 232727 so I think the conversion factor is 256 which would get you to the regular DLONG of 59578112 (which is practically the same location as what we see in the nash.txt file).

The "replay DLAT" is 1672 which translates to 428032. And this is a match for the player pit DLAT of 428250.

That's all the time I have for research today, but this is encouraging.

(10-15-2021, 05:23 AM)samsepi0l Wrote: [ -> ]I'm starting to wonder if it may have been a better idea to just keep the chicane the way it was back in the original nashville.  I know it's not as accurate, but this does solve a lot of problems.  With a game this old there are going to be short-comings that need to be worked around. 
I didn't catch this comment earlier but let's keep trying because if we succeed it will open up more possibilities for other tracks. But I am prepared to alter the layout if necessary.
(10-15-2021, 06:01 AM)samsepi0l Wrote: [ -> ]My thoughts exactly.... when I made multiple replay attempts I slowed down to an absolute crawl trying to minimize the coriolis... it was very low in record 37 before the record 38 which is where I get the garbage data.  My coriolis was only about 4, or 5 or so in record 37. 
I thought about this. Till now I thought, high coriolis valuer are the reason for this bug. But according to your observation, it isn't true or at least not the only reason, because it seems, that the car angle to the centerline is the main problem.

I'm curios, is the "car orientation" value in the RPY file the angle to the centerline? It should be. But then, why couldn't Róbert implement it correct in the conversion? In TRAFO20.TXT he wrote "try not to broadside or spin your car and do not drive backward".
I'm looking forward to new surprises, hopefully there aren't any Confused

Update:
I've looked at the coriolis calculation formula, and the car orientation isn't used for it.
Even for GPL after many years speed values for lp that are caculated by converter from replay still wrong in corners. And you think you will be able to solve this problem?
Replay unlike lp store information differently. First and major problem here: replay store car possitions accordinf framerate, but lp file store car position with dlong step. Second problem is speed calculation. Replay doesn't store speed values. So converter (Trafo) should calculate speed from difference between points of travel. All converters don't take into account car position in turnes. If car is located on centerline then everything is ok. But for example if it's left turn and car is moving along left edge of the track then lp position steps are much smaller. But converters calculate speeds as if it normal 'centerline' step is used. And result is abnormal high speeds values in lp file.
(10-15-2021, 06:16 PM)Pavel 69 Wrote: [ -> ]Even for GPL after many years speed values for lp that are caculated by converter from replay still wrong in corners. And you think you will be able to solve this problem?
Replay unlike lp store information differently. First and major problem here: replay store car possitions accordinf framerate, but lp file store car position with dlong step. Second problem is speed calculation. Replay doesn't store speed values. So converter (Trafo) should calculate speed from difference between points of travel. All converters don't take into account car position in turnes. If car is located on centerline then everything is ok. But for example if it's left turn and car is moving along left edge of the track then lp position steps are much smaller. But converters calculate speeds as if it normal 'centerline' step is used. And result is abnormal high speeds values in lp file.
It's one thing, that the values are calculated incorrectly, I'm sure, I could do the calculations, to get the correct values, if I know what we have and what to get. I've already done one part of it, and I have ideas, how to do the rest.
The problem is, we don't know, why trafo20 doesn't get values anyway. Is it a programming bug in trafo20, is it a wrong calculation method in trafo20, is it an unknown formatting or file structure problem in the RPY file? And what do we know about the LP file structure and its limitations?
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29