This goes with what Ermo posted about coded physics files.
A member named Shiimis had done quite a bit of translating of the physics files. I took over and added more translations and became a maintainer of the information. Other members have contributed along the way, too. Since the physics data is coded, I discuss what's in the files at another site, along with providing access to the info via public folder.
Some time ago, Shiimis also created a binary file modification tool which will take a specifically formatted text file and generate the coded physics files. This tool was left in my hands to where I would still need to create the various formatted text files and supporting template binary files to work with the tool. In most cases, this tool would cause more harm than good. The reason being are the many "Unknown" parameters in the physics files.....especially in the Chassis file (CDFbin).
As as example, when I need to change from RWD to AWD, I know to grab a chunk of data at the bottom of the CDFbin, and replace the data in my own file, along with changing a series of bytes and floats in another section of the file. Also, if the chunk of data I added in was different in length, I have to revise a group of byte count registers at the top of the file. I refer to this as "Blind" editing...don't know what's in all of the data, I just know that's what needs to be done to get the results I'm looking for. Likewise, there's a bit of blind editing to change a car from a H-shift manual to a semi-auto/sequential (just changing a series of bytes and floats in a section of the code).
I guess the point to this post is, whether or not, SMS would be open to providing a matrix to all of the parameters that may reside in each of the coded physics files. We see there is a hex string (ID) for each parameter. In most hex strings there are also bytes to denote the format of data to follow (byte, float, 32bit decimal, etc). So, the proposed matrix would include the hex string (ID), the name of the parameter and maybe a description of the function if it's not so obvious. Also, the meaning of the chunk of code at the very end of the CDFbin (after the RearRight section with byte length noted at address 0x20)
If I had a better grasp on all of the "Unknowns", I could look into creating something more functional to work with the binary file modification tool by Shiimis.