Tdesc file structure as compared to tuning files? (and some thoughts on error checking)
So as a little side project for attempting to make it easier to spot errors in mods in need of fixing when updates happen, I was looking at the idea of using the TDESC file structure compared to the format of code in a tuning file and compare the two to see if anything is awry. I got a little tripped up in the details though and figured I'd ask around if anyone knows more about the TDESC file structure, or some perspective I hadn't thought of that might lead to a solution. So far, I worked out that for tuning files: I = Instance ("instance_type") L = Tunable List U = Tunable Tuple V = Tunable Variant E = Tunable Enum T = Tunable Type And that 't' and 'n' in the tuning files are short for 'type' and 'name' in the TDESC files. But it seems to get increasingly complicated from there, rife with exceptions to the rule. Where some branches of commands will follow a structure identical (or near) identical to its sister tree in the TDESC file, some others most definitely don't. For example, for some branches you can't just translate it like: Actor To something like: And looking for a branching setup like that in the Interaction.tdesc file as it just wouldn't exist in that format. If I remember correctly for this specific case, the TunableVariant part at the top is instead decided on from a series of different types and is, by default, none. In theory, exceptions like these could be hard-coded for, but it's hard to tell just how many of them there are and to what extent they would result in false positives when testing for tuning code with errors. I remember trying to resolve the one as in the example above and running into more confusing exceptions to the rule, or I misunderstood what I had thought was a rule that wasn't, or something like that. However, I know folks like Zerbu have created tools that can generate certain code. I'm not sure if those tools are based off of the tdesc files or copies of tuning files, but presumably the TDESC files could be interpreted from somehow. The other approach I had considered was testing bits of code (ex: the VFX segment above) against the most up-to-date tuning files and simply seeing if it matches any of the existing code. This would probably work for a lot of things, but runs the risk of false positives if someone has utilized a combination of tuning possibilities that simply hasn't been used in the actual game. It also risks being performance-heavy to analyze, as there's no way of knowing for sure how many files would need to be searched through and compared against. In the case of an error, you'd have to assume it analyzes at least every single game file of a certain type (ex: Interaction) until it finds that there is no code like the sample checked for. Best case scenario for performance would be that it locates an existing example quickly and returns with no error. So I'm at a bit of a standstill at the moment, in terms of tackling the problem. I think interpretation of the TDESC files and comparing that to tuning files is a realistic possibility. It's just proven to be more convoluted that I thought it would be and I'm not sure if that's because of how the TDESC files are structured, or if I'm just not understanding them well enough.