Skip to content

Conversation

@AbsentData
Copy link
Contributor

This adds a crate that generates replay files for the simulator by pulling data from livetiming.formula1.com/static. Some things to note about the implementation:

  • This is my second ever project in rust, so there may be places that my code isn't as good as it could be, but I have tried to go back and improve it since I learned a lot working on this. The project compiles with no errors or warnings and it works efficiently and as intended, and pretty much all errors are either recovered from or explained to the user.
  • I used inquire to get user input since I don't think there would be a good way to get the info needed from the user through command line arguments, and although there are some things I don't like about inquire, overall I think it works well.
  • As is mentioned in the readme, there are many races this can't get. That is not an issue with the code, but instead with Formula 1 not putting those races with everything else. As far as I know, they aren't available, but I have a friend with F1 TV Pro who is checking if they can access those races, and if they can, I'll try to figure out how to make that work here.
  • The functions that get any sort of JSON data from F1 don't use reqwest's JSON implementation because F1 "illegally" adds a byte order mark at the start of the responses, so that had to be handled separately. This is also why those functions use a custom error enum.
  • When get_meetings returns a JSON error, the user is told that no races are available for that year. This is because for some reason, when a year with no data (or any invalid path) is requested, it returns an XML response saying "Access Denied" rather than the logical response of something in JSON. So, I interpret a JSON parse error as a year with no races available.
  • generate_raw_replay and generate_replay are separated into two different functions to allow for different replay file formats in the future (since the current one isn't very good). I intend to make an improved format after I make some more improvements to the simulator, like play/pause and skipping around.
  • This is multi-threaded because it speeds up the processing time quite a bit (~1100ms becomes ~150ms on my machine), and it also slightly speeds up the network requests. Also, if something goes wrong with the network request on any of the threads, it will print an error but will continue, since the replay file can still be created even if it's missing some data.
  • The network requests are done using reqwest::blocking, which is synchronous, for two reasons.
    • It didn't seem necessary because it's already multi-threaded so the requests are running in parallel, and there's nothing else for it to do while waiting for the requests to finish.
    • I have no experience with async in rust, and I know that if I tried to use it here it would either be really badly written or I would spend way too long learning how to do async.
  • This crate is both a binary and a library because I think it should be usable as a binary in the same way that saver and simulator are, but I also think it should get built into other crates. I'm planning to add it to the simulator, and I also think I could get added to something like the api, like in Feature: archive #163.
  • This requires fix: fixed simulator getting out of sync #294 to function correctly or else it will quickly get out of sync.

Let me know if you have any questions or suggestions.

@AbsentData AbsentData requested a review from slowlydev as a code owner August 20, 2025 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant