Stepping through a recorded session does not update data for this time

[moritzdietz]

I think there is a bug in the UI when opening a recorded session and then going back in a recording using the N and M keys.

Currently the behavior is so that the data in each column stays at the values from which I stepped back from.
Also all other data stays frozen until the playback reaches the time of the race from when I went back in history – if that makes sense.

Untitled.mp4

[JustAman62]

Similar to the issue described in #197 (the difficulty in implementing this is described there as well). Essentially we don't support going "backwards" in time, as all the deltas we receive for the timing state are forward-looking, and it's not trivial to reverse a applied change in the timing data to make it go backwards when the delay is increased.

This is a fundamental issue with the current data architecture. You can kinda see how this works in the S Session page accessed from the main timing tower page, where you can see new messages flowing in to the table with the current simulated timestamp. All these messages are partial delta that we apply to the current state, say updating a sector time for a driver. This makes it impossible to "rewind" the state, as when we update a sector time, we don't have an opposing message to set the sector time to what it was before, you can't just "undo" that sector time update easily.

This is the second request for this kind of functionality though, so I'll keep this issue open for now whilst I think of ways to achieve this. Probably involves creating some sort of inverse delta for every delta we receive and keeping them in some sort of undo stack.

We may also be able to cheat and have a button that allows you the "replay" all the messages received since the beginning of the session to the current time, allowing you to do a two-stage rewind where you first increase delay, then you playback all the messages to that new delay level. This would let you rewind whilst keeping our current forward-only semantics.

Can't make any promises about being able to implement this though! Fingers crossed.

[moritzdietz]

Gotcha! This sounds very reasonable. Thanks for taking the time to explain the details. Feel free to close this issue if needed :) People will probably find it eventually