EDIT. This whole thread is obsolete.

Hello. I'm experiencing problems with my InSim application, which are rather subtle and therefore, difficult to explain. Instead, I will ask specific and simple questions concerning inner work of LFS. I don't think anyone but the devs can answer these questions. (EDIT: these are obsolete, see post 8 for details)

Let's take a dedicated host, which has an InSim app connected (with MCI enabled). There is one client on the server, who has a ping of (say) 100.

Question 1:
How are the X, Y, Z coordinates and speed in MCI packet calculated? The simpliest assumption is that they are from the last UDP packet sent from the client to the server. But this does not seem to be the case.

Question 2:
If a client lags (from other clients' viewpont, the car "disappears" and is replaced by some sort of a lag counter), what would be the XYZ and Speed sent in the MCI?

Thank you.

Wow I think youre making things more complicated than they really are. Im no dev but I can answer you

Coordinates have all to do with position in the LFS world axis and nothing to do with latency, therefore what you're getting in your MCI are values taken from the 'real' position of the cars, not the values sent in the last MCI packet.

I think this answers both your questions.

Feel free to correct me if im wrong, though.

Quote :

not the values sent in the last MCI packet.

That's not what I meant. Maybe my wording wasn't quite good. To clarify, by "client" I mean an ordinary LFS user.

Quote from BurnOut69 :

Coordinates have all to do with position in the LFS world axis and nothing to do with latency, therefore what you're getting in your MCI are values taken from the 'real' position of the cars

I know that. I'm asking what is "real position of the car", as you call it. Ideally, it would the the position in client's LFS. But as the server receives it with a delay, it only has "old" data all the time. And I think the server compensates that by an approximation. How it's calculated is my question.

Or maybe I'm totally wrong in which case, feel free to enlighten me

Well, it's definetly sends out the position of the client's car based on the last data received by the server. I don't know that the server compensates, rather I think thats on the client, but of course Scawen would be best to answer that.

Quote from Knu :

I know that. I'm asking what is "real position of the car", as you call it. Ideally, it would the the position in client's LFS. But as the server receives it with a delay, it only has "old" data all the time. And I think the server compensates that by an approximation. How it's calculated is my question.

I am not sure what you are trying to do, but I doubt the data is very reliable. If you get a new packet every 100ms, combined with your latency to the server (if remote), the fact that you can not read all car packets simultaniously and the latency from the client to the server - I think it's rather inaccurate as to the actual current cars positions by the time you get to do anything with the data.

Quote from F.Rizzo :

I am not sure what you are trying to do, but I doubt the data is very reliable.

Yes, but that's besides the point. I'm trying to get greater accuracy with the existing tools. And, believe me, it is possible to achieve great results in some problems. For example, for 2 cars moving with high speeds, I'm calculating the time gap up to a 1000th of a second, and it works exceptionally well.

Quote :

If you get a new packet every 100ms

That's 50ms, and I compensate for that in my calcutations.

Quote :

combined with your latency to the server (if remote), the fact that you can not read all car packets simultaniously

I use a local application, so there's no additional delays.

In your original post you stated 100ms i was simply reffering to that, not the lowest possible setting

Calculating time gaps sounds like a nice idea!

I've done some data logging and math mumbo-jumbo in Excel and actually got a partial answer to my questions. And, sadly, it is extremely unappealing. Here it is, maybe someone may find it interesting.

For example, this is typical "Speed" readings in a period of 2 seconds.

During that time, the car was accelerating from a low speed. This was done on a local server (ping < 1 ms), with PPS = 12, and captured by a local InSim app.

As you can see, Speed is updated not 12 times per second (as dictated by PPS), but about 2, and even less on average. Changing PPS to a default 4 didn't change anything.

However, the coordinates change in every packet - and by comparing
and Speed, I have found out that
1) when Speed is constant, coordinates are a linear approximation.
2) when Speed changes, the coordinates "jump".

In the light of this, some new questions arise.

Question 1:
Does the LFS server really send the newest and accurate data via InSim? I personally find it hard to believe.
Question 2:
If the answer is 'yes', what is the meaning of PPS?
Question 3:
If the answer is 'no', why?

Resolved. Kinda.

http://www.lfsforum.net/showthread.php?p=594018