FreeGameDev

Hi everybody! At the request of FabianF, I'm posting this topic. He and Anard played in Nessie's Pong track in Strasbourg Ranked today in near UTC+0 13:00. Me and Ulli61 spectated. FabianF finished the race first, then after 5-10 seconds Anard, before the finish, turned left (to the blue flag). Then race was ended. In list was:

FabianF 02:__:__
Anard 00:00:00

(sorry for lack of screenshot, but nobody made it)

Fabian lost some points, Anard got them. So, because of this bug, de jure Anard won. I'm asking to developers with question: why it happened? Is this a track error or it's possible everywhere?
Do you know about it? Comment, please.

Weird issue. This "00:00:00" time is what is behind the point change I guess, but this doesn't tell us how this bugged time happened.

I was able to replicate this, here is a video: https://www.youtube.com/watch?v=Z7Y-YhBP_5E

I had not seen that issue. This other issue may or may not be relevant: https://forum.freegamedev.net/viewtopic ... 17&t=12400

because float finish_proportion = curr_distance_after_line
/ (prev_distance_before_line + curr_distance_after_line);

prev_distance_before_line and curr_distance_after_line are both zero, then finish time is NAN (you see 0 in game)

maybe just use getTime() if division by zero?

benau {l Wrote}:because float finish_proportion = curr_distance_after_line
/ (prev_distance_before_line + curr_distance_after_line);

prev_distance_before_line and curr_distance_after_line are both zero, then finish time is NAN (you see 0 in game)

maybe just use getTime() if division by zero?

Would using it for all cases solve the other problem mentioned above?

theodorepringle {l Wrote}:Would using it for all cases solve the other problem mentioned above?

A race would have to have an extremely close finish for this not to work. Unless I'm mistaken, the purpose of that calculation is to increase accuracy, since (correct me if this is wrong, I'm not a dev) the race checks your position once every frame, so you will probably already be past the finish line when it checks. That calculation interpolates to find out when you actually would have crossed the finish line. At 15 FPS (pretty low, but reasonable), your final time could be off by up 1/15 of a second (that is, 1 second / 15 FPS = 0.066... sec per frame).

tempAnon093 {l Wrote}:

theodorepringle {l Wrote}:Would using it for all cases solve the other problem mentioned above?

A race would have to have an extremely close finish for this not to work. Unless I'm mistaken, the purpose of that calculation is to increase accuracy, since (correct me if this is wrong, I'm not a dev) the race checks your position once every frame, so you will probably already be past the finish line when it checks. That calculation interpolates to find out when you actually would have crossed the finish line. At 15 FPS (pretty low, but reasonable), your final time could be off by up 1/15 of a second (that is, 1 second / 15 FPS = 0.066... sec per frame).

I'm not sure if the interpolation is supposed to depend on FPS. I tested playing at graphics level 6, where I get about 20 FPS, and the time shown in the end screen is still usually not more than 1/120 of a second faster than the elapsed time. Occasionally (at any FPS) the difference is more than that, especially if the finish occurs at the edge of the lapline. When a checkline is placed on the lapline, finishing on that checkline sometimes results in the final time shown being about 1/24 of a second faster than the elapsed time, though this doesn't seem to be entirely consistent; it may depend on exactly how the finish is approached.

The 0.00:00 issue in Nessie's Pond is fixed. The bug happened because of this other core issue : https://github.com/supertuxkart/stk-code/issues/3272