Codemasters Team@Hoobiechoobie I think this was already discussed in the past, but I think currently it's not possible to properly handle "flashbacks" with the data sent by the game (I think this is true since F1 2018). If I'm wrong, please correct me ( @cjorgens79 😉 )
We collect data for telemetry analysis, and not being able to handle flashbacks results in bad data streams, mixing packets from different "time-lines".
The main issue is that when a flashback occurs, both the the fields m_sessionTime and m_frameIdentifier wind back in time at the old values, making impossible to detect in a reliable way the event (e.g. if the FLBK event is lost or arrives out-of-order) and properly handle it (newly arriving packets will be indistinguishable from "old" packets, making impossible to understand if they're duplicated UDP packets, old out-of-order delivered packets, or new packets following a flashback).
This is an example from a real captured data flow:
Packet 13587 arrived notifying a FLBK event (considering the UPD protocol, it could easily go lost or arrive at the wrong moment, so it's not really useful in this context - but here you can see the correct header values received):
Packet 13588 arrived, and now m_sessionTime and m_frameIdentifier wind back and are now using "old" values:
A very simple solution would be to have m_frameIdentifier to continue with monotonic increasing values, also in case of a flashback. This would easily allows to detect and handle in a reliable way flashbacks (since m_sessionTime would be have wound back).
Thanks.
