Hi there!

I'm currently doing some experiments with pth-fileformat.
Doing so I came along one fact, that is quite ... irritating ...
I calculated the tracklength given in pth-files by simply adding up distances between the single points (which - if I'm not wrong - should be some sort of ideal-line).
This result differs from the tracklengths given in the english manual (the only one that seems to have values in metres) (http://en.lfsmanual.net/wiki/Tracks) by something between 2 and 4 metres, where "my" result seems to be always the smaller one.
Whereas, if I calculate the length using the middle of the track, I get values which are way to high.
Example: FE4:
idleal-line: 6557.3m
middle of track: 6622.0m
manual: 6559m

So ... the following questions should be obvious:
Where do the values in the manual come from?
How where they calculated?
Which ones are correct?
What values are used ingame/at lfsw?

Quote from avetere :

Where do the values in the manual come from?
How where they calculated?
Which ones are correct?
What values are used ingame/at lfsw?

- I calculated them a long time ago.
- By measuring the distance between nodes in the pth files.
- No idea.
- Dunno.

Well, that's exactly, what I did ... perhaps those 2m-differences are due to some minor track-updates!?!

Now the interesting question is:
What is the best way to calculate it? Ideal-line or middle of track?
Any ideas, how this is done in real life?

Well, here's a small comparison between your data and mine (bold) ... as stated above, the maximum diff is 6m ... maybe we should nevertheless consider ekich are the better values and keep the manual up to date

BL1 3.307 km (2.055 mi) 3.305 km (2.054 mi)
BL2 1.839 km (1.143mi) 1.836 km (1.141 mi)
SO1 2.033 km (1.263 mi) 2.031 km (1.262 mi)
SO2 2.048 km (1.273 mi) 2.047 km (1.272 mi)
SO3 1.334 km (0.829 mi) 1.334 km (0.828 mi)
SO4 4.029 km (2.504 mi) 4.027 km (2.502 mi)
SO5 3.146 km (1.955 mi) 3.143 km (1.953 mi)
SO6 2.917 km (1.813 mi) 2.915 km (1.811 mi)

FE1 1.584 km (0.984 mi) 1.583 km (0.984 mi)
FE2 3.086 km (1.918 mi) 3.086 km (1.917 mi)
FE3 3.514 km (2.183 mi) 3.513 km (2.183 mi)
FE4 6.559 km (4.076 mi) 6.557 km (4.075 mi)
FE5 2.018 km (1.254 mi) 2.017 km (1.253 mi)
FE6 0.745 km (0.463 mi) 0.745 km (0.463 mi)

KY1 2.980 km (1.852 mi) 2.979 km (1.851 mi)
KY2 5.138 km (3.193 mi) 5.137 km (3.192 mi)
KY3 7.377 km (4.584 mi) 7.376 km (4.583 mi)

WE1 5.180 km (3.219 mi) 5.178 km (3.218 mi)

AS1 1.870 km (1.162 mi) 1.868 km (1.161 mi)
AS2 3.077 km (1.912 mi) 3.076 km (1.912 mi)
AS3 5.602 km (3.481 mi) 5.599 km (3.479 mi)
AS4 8.089 km (5.026 mi) 8.083 km (5.023 mi)
AS5 8.802 km (5.469 mi) 8.798 km (5.467 mi)
AS6 8.002 km (4.972 mi) 7.998 km (4.970 mi)
AS7 5.168 km (3.211 mi) 5.164 km (3.209 mi)

My data might just be wrong, I dunno. It was a long time ago and I don't have the code I used anymore. If you think yours are correct and you want to change the manual feel free.

I've no knowledge of this system, so shoot down this suggestion if it's nonsense, but could this difference in lengths be due to you not connecting the last node back up to the first node?

That's been also my first guess, so I double-checked that.
Well ... here's the code I used:
Where obviously $pthdata is the array containing all nodes ... and $ds is the total distance

Looking at that reminds me of how much I hate PHP.

:haha: ... well, I'm quite sure, that's not the most elegant way to do it ...

I made such an application myself years ago in java.
The values, you have been posted, are wrong, the manual is right.

Edit: What happens if you replace 65535 with 65535.0 ?
Edit: I think I see the problem ... you applied the converion to meter (/655535) very early, which causes the difference in values, apply the conversion as last operation to the overall length and you get the same values as written in the manual.

Quote from yankman :

The values, you have been posted, are wrong, the manual is right.

Well, I don't claim to be right ... I'd just like to know, where the difference comes from

Quote :

Edit: What happens if you replace 65535 with 65535.0 ?

same thing, no differences (apart from the fact, that I divide by 65536 --> (1 metre = 65536)) I tried 65535 though, with no relevant diffs ...

Quote :

Edit: I think I see the problem ... you applied the converion to meter (/655535) very early, which causes the difference in values, apply the conversion as last operation to the overall length and you get the same values as written in the manual.

nope ... tried that before, makes no difference ...


the overall technique can't be to wrong though, as results for FE6 are exactly the same

I got it .

You forgot about the z axis.
Include the z-axis in calculation and everything is fine.

Yeah, that was it, thanks! ... A little to obvious to see it ...

Quote from avetere :

That's been also my first guess, so I double-checked that.
Well ... here's the code I used:


<?php 
foreach($pthdata as $id => $point) {
    if(isset($pthdata[$id+1])) {
        $dx2 = pow(($pthdata[$id+1][centreX] - $pthdata[$id][centreX])/65536,2);
        $dy2 = pow(($pthdata[$id+1][centreY] - $pthdata[$id][centreY])/65536,2);
        $ds += sqrt($dx2 + $dy2);
    }
    elseif(!isset($pthdata[$id+1])) {
    $dx2 = pow(($pthdata[0][centreX] - $pthdata[$id][centreX])/65536,2);
    $dy2 = pow(($pthdata[0][centreY] - $pthdata[$id][centreY])/65536,2);
    $ds += sqrt($dx2 + $dy2);
    }
}
?>



Where obviously $pthdata is the array containing all nodes ... and $ds is the total distance

WTF is that
it's thousand times easier and more understandable to write it in ANSI C
or C#, Java, what ever you like, just don't use PHP for desktop applications

Quote from JackCY :

just don't use PHP for desktop applications

Who said, it was for a desktop app?

Quote from JackCY :

WTF is that
it's thousand times easier and more understandable to write it in ANSI C
or C#, Java, what ever you like, just don't use PHP for desktop applications

I want to see your ANSI C compliant version of this. Of course with file handling.

And who did ever ask for your opinion regarding php ?
Please behave.

PHP, C, C# and Java all have an extremely similar syntax, in fact with a few small changes you'd be hard pushed to tell which language that code example was in! Also all of them are easily capable of all sorts of programs, from web to desktop apps.

Oh yeah, Python is best.

Well I didn't think of syntax, that is just something you can adapt.
But memory management, type juggling etc. that is what really seperates the script languages.
Also there is lack of template libraries in ANSI C, so if u need a hash table, you first have to invent it, as well as a few other things.

But at the end I don't want to discuss programming languages.
I was just annoyed by that dumb post.

I say don't use a mallet to fix a fuel injector, unless all you need is a mallet. Some times a mallet is all you need.