DFHack
Improve structure forward compatibility for modders
A pain point for modders is that when we identify and name a structure field, a script that was previously working could break because field "anon3" (for example) no longer exists. The mod author then has to find the new name, update the code everywhere that field is used, and redistribute the updated mod to all its users.
There are a couple ways to improve this situation.
If the mod author knows what the unnamed field does, that knowledge should just be upstreamed into the structure definition. We can promote this in a DFHack modding guide.
For all the scripts that already use the old name, though, we can allow fields to be accessed by multiple names. The field could gain a tag in the xml listing the aliases for the field, and the field can be accessed by its "real" name or any of its aliases. This works naturally in Lua. It's up for debate whether we want to generate unions for cpp. The strong typing makes naming changes easier to discover and fix at build time, so I don't think this would be much of an issue there.
If they are simply setting the field the same as another object that they are copying, an easier solution is to clone the object instead of copying field by field. We can promote this in the modding guide.
As I see it, there are two distinct problems here:
- Fields getting renamed from "unk_123" to "does_something", which breaks scripts referencing the old name (and nothing else)
- Unnamed fields (which get an autogenerated "anon_N" name) being given names, which breaks scripts referencing any other unnamed field (because removing "anon_1" will cause "anon_2" to change into "anon_1")
The suggestions above would certainly help with the former case, but for the latter we would realistically need to go through and assign names to all fields (of which there look to be over 2000 lacking names) and then update the codegen script to require all fields to have names going forward.
Assigning names to all unnamed fields sounds reasonable (and desirable for the stability, even if we just use their current autogenerated name).
since this will come up every time there is a new structure or new unknown field, we should write a script that reads in the XML and spits out a modified XML with autogenerated names for any unnamed field so it doesn't have to be done manually. codegen already has most of this code, so it might be easiest to just extend that script.
From discussion on discord, lethosor brought up some cases where this proposal won't help:
- fields moving in/out of a sub-struct (which we do sometimes to fix alignment)
- we rename a field from A->B, then later discover that an unknown field should be named A
moving a field in/out of a sub-struct could potentially be handled with some lua trickery, but we'd have to decide whether it's worth the complexity. Nothing is likely to help the second case, but it should be very very rare.