[meta] Include dr2_logger in dirt-rally-time-recorder?

[ErlerPhilipp]

We could probably include my dr2_logger in your tool. Users could compare race times and analyze the used setups in one tool.

You only store race times, right? The setup analysis requires more detailed data which is ~4MB in NPZ format on the HDD for a 8min race. I think this would be the biggest change for your users. We could add a switch in the settings or delete the data for old races.

What do you think?

[maxbechtold]

Hey, interesting proposal. I think, however, that the two tools have different goals which doesn't align with the Unix philosophy ("do one thing"). There's quite a gap in technology and UX as well. And while one's probably mostly interested in the most recent setup analysis, time-recording is very much about historical data.

But I think I see where you're coming from, namely that the basic mechanism is the same: transform UDP data into insights for the user. Should we rather discuss a common basis for the UDP data recognition? I'd like to believe that I pretty much nailed it regarding the game state recognition for DR1 and DR2. I think it would not be too much effort to extract it and make it reusable for the dr2_logger. The car and track base data could be part of this library as well, but let's discuss it.

[ErlerPhilipp]

do one thing

I see your point here. If you add analysis of multiple runs in the future, like show the variance of race times for a specific car on a specific track or show the number of crashes per race on a type of track, then the goals would align much better and you could benefit from some structures in the dr2_logger.

I'd like to believe that I pretty much nailed it regarding the game state recognition for DR1 and DR2.

It's pretty disappointing that we have to guess the game state and car/track names. Also, there is no chance to get the setup data, maybe except for invasive stuff that would trigger cheat detection. The UDP data in Project Cars 2 is so much better. Anyway, I'm happy to get a common basis for that. My current version for the game state detection is in get_game_state(). I had some more sophisticated detection but it wasn't reliable enough. Now it's just 3 states: running, not running, paused. 'Running' is essentially lap_time > 0.0. 'Paused' is when the same data is received again (except for run_time). 'Not running' is everything else. It seems to be reliable now, also for RX. What are your detected states and the basic idea? Btw. is your game state detection for DR1 the same as for DR2?

The car and track base data could be part of this library as well, but let's discuss it.

My car and track data is currently just hard-coded dicts in python files: cars and tracks. It would be some effort to add SQL like in your tool. Not sure, if SQL is the best solution.

Anyway, we should also share the car and track detection with heuristics.

We could make a common repo and include it in our projects via git sub-modules.