Fredrik, it would be nice to play the "inverted" tracks. Let me know if you want to add the files to the file archive.
How complicated is to create the CC line manually, using ArgTrack and the knowledge you have about the track file structure?
Does it come down to changing random things in the track file and seeing what happens to the CC line, or do you have a better idea of what you're doing?
Btw, keep up the great work :)
I have some news of my own.
For the past couple of weeks I've been dedicating my time after work to processing the data from the performance simulations. I've been writing the tools for each step of the data processing. The steps are as follows:
- Perform a qualifying simulation and export the print file with the qualifying results.
- Convert the print file with the qualifying results into a log text file containing the lap times and performance settings for each driver.
- Aggregate all qualifying log text files and export a full text database file.
- Convert the full text database to a full binary database file.
- Group the logs with the same settings in the full binary database, sort the data, and export the sorted binary database file with the time logs for each performance setting.
- Using the sorted binary database with the time logs, calculate the lap time for the given performance settings (grip, BHP, skill, track).
The core functionality for each of these steps has been implemented. There is still a lot of work to do with commenting and optimizing the code, as well as adding data verification procedures at each step, and finally documenting everything.
Given the large amount of data, I've run into numerous issues relating to memory allocation and variable limitations, compiler and built-in function limitations, etc. I'm not a programmer, so I have to test each step and figure out a way around the issues. I'm trying to find the right balance between managing the data in a safe and robust way, that can be used in the future, and not going overboard with making the tools more general than necessary.
At the moment, the simulations have covered the following performance range:
Track: 1-16 = 16 value
Grip: 1-15 = 15 values
BHP: 470-1240 (steps of 10) = 78 values
Skill: 0-59 = 60 values
Total number of data points: 16 * 15 * 78 * 60 * 10 = 11 232 000
Unique performance combinations (grip, BHP, skill) = 15 * 78 * 60 = 70 200
The full database file is taking up around 1 GB of space.
However, the processed indexed binary database file, with just the lap times, will take only around 40-45 MB.
This can be further reduced by including only the processed time information (average time, median, maximum and minimum time, maximum absolute error, standard deviation, etc.), instead of including all the individual time samples. Given the realistic time constrains, the lap times could also probably be stored in less than 4 bytes each.
My first goal is to release a command-line tool that calculates the lap time from the given performance parameters (grip, BHP, skill, track). This functionality could also be implemented in the ArgEditor carset editor.
After that, I would like to release a performance matching tool. The user would enter the desired lap time at each track, and the tool would calculate the optimum combination of performance settings to make it happen (grip, BHP, skill). This tool would ideally have a GUI, but a command-line version is not out of the question.
Ultimately, I'm hoping to figure out an analytical formula linking the performance settings and the lap times. This would eliminate the need to have a database in order to calculate the lap times. In that case, the performance matching would also be reduced to calculating an analytical expression, or solving a simple numerical problem.