- 332
- Denmark
Yes, or, to use Hamilton's own terminology, the vector (he actually coined the word) part followed by the scalar part.So the first three are the imaginary part and the last one is the real part?
I think you're over-complicating this. The only thing we're interested in is the sampling period, which is 1/60 s.The issue here is the time delta -- if you use the time progression in milliseconds you cannot use races with time progression factor that is unequal to one, and with time progression 0 you won't get any time progression. If you use external time measurements (measure time between arrival of packets) you will get inaccuracies. I came up with a timing solution based on the packet numbers and that the timing between them is almost-always-but-not-quite fixed to 1/60s. But it is quite involved and requires you to not miss some special packets. It doesn't work in some cases like standing starts. @Stoobert also found some velocity discrepancies with live vs. replays in the data so the time retrieval is sketchy and thus also deriving things from it like acceleration.
How do you get the time delta to differentiate from velocity to acceleration?
I just do a[n] = 60 * (v[n] - v[n-1]), where v[n] is the velocity vector in packet n.
(because a = dv/dt -> a = dv/(1/60) = 60 * dv. And dv = v[n] - v[n - 1].)
For lap timing I accumulate 1/60 s. for each logged (i.e. non pause-flagged) packet. This yields the exact lap times displayed in-game to the millisecond, so I can't see where the alleged special packets fit in.
Edit: Ok, having logged a couple of whole races (with standing start,) there's something weird going on, but only on the final lap of the race. From my logger's debug messages it seems like the game skips a lot of packets, so the calculated timing for the last lap (and only that) is off.
Last edited: