search

eckhchri / pcars-ds-liveview

Provides a html page for project cars dedicated server and display a map of the current race.
14 stars 1 forks source link

Round problem on gap calculation #157

Open viper4gh opened 4 years ago

viper4gh commented 4 years ago

In AMS2 in CREST2-AMS2 mode the lap time gap to the first driver differs sometimes about 1 millisecond in comparison to the in-game UI. The API provides the laptimes in milliseconds with at least one digit after the decimal point. liveview calculates the diff between the laptime of the first driver and the laptime of the current driver and then it is rounded, look at the CalcGaps function for it. The rounding happens then in the ConvertLaptimeInReadbaleFormat function.

Maybe we should round the two laptimes before and then calculate the diff.

Bear Issue #137 in mind. Maybe the problem come up now, because before the issue #137 we rounded the laptimes directly after receiving the data and before the gap diff calculation happens.

Check again with AMS2 and pcars2, compare gaps and laptimes between liveview drivertable and in-game UI. The console log shows the driverlist with the laptimes. And are the laptimes itself correct rounded, check if someone has a laptime of xyz.5 milliseconds

viper4gh commented 4 years ago

We need a rounding for the fastest lap time before the laptime gap calculation happens. Example (laptimes in ms from Shared Memory):

  1. 123456.7
  2. 123457.2 Laptimes in driver table rounded to
  3. 123.457 s
  4. 123.457 s You see the gap should be 0. But the gap calculation use the unrounded values, which means: 123457.2 - 123456.7 = 0.5. This value is then rounded to 1 ms and the table would show 1 ms gap.

In result that means the laptimes must be rounded before the gap is calculated. And the lowest CPU load is produced if you round it directly on receiving the data. In the other case you can transfer the rounded values always to the CalcGaps function, but this function is called multiple times per worker run.

For Issue #137 we need the unrounded values for sum up all laptimes, and this seems to work. Tested with 20 lap races in pcars2 and AMS2. There were only one or two gaps with a 1 ms error in comparison to the in-game UI result board. There is maybe only one thing we can do: on calculation the diff with CalcGaps, transfer rounded laptimes. But with the advantage that this fixes maybe the one or two 1ms errors, you have the disadvantage of calling Math.round much more often (additional 3 times per driver vi CalcGaps function).

viper4gh commented 4 years ago

Further there seems a problem in general with rounding of lap times from Shared Memory API. Example lap time from Shared Memory: 38.5425 ms The game shows it as 38.542, but correct rounded it should be 38.543.

We have suspected, that the value precision is higher in game internally in comparison how it is provided in Shared Memory, which means Shared Memory provides an already rounded value. If this is right the value could be the following: 38.54249 ms or 38.54251 ms If I round this to 4 digits after decimal point like in Shared Memory both is 38.5425. But if I round this to 3 digits like it is in game shown in the live timing: 38.54249 ms = 38.542 ms 38.54251 ms = 38.543 ms In this case there is nothing we can do, this is a problem in Shared Memory. Either they provide 3 digits after decimal point or 5 digits. Both would solve the problem.