Forum Announcement, Click Here to Read More From EA_Cade.
1.6.69 : TDESC files
SimGuruModSquad
Posts: 597 Member
Hi all, attached are the new TDESC files for today's May 4th patch 1.6.69.
Heads up that with patch 1.6.69 there is a tweak to the format of TDESCs being released by Maxis. Since we know that tuning mods are prone to breakage due to changes made in patches, this new format includes additional data that can be used to more easily resolve incompatible changes made in mods.
For this patch, the following files have been provided:
Note that future patches will only supply the TDESCs in the new format.
The 1.5.149 TDESCs are provided in order to take advantage of the new data, which requires you to compare the old TDESCs against the new ones to determine what has changed.
The change involves including metadata in the TDESCs file to make it easier for you to understand how the structure of the tuning has changed. There are two new sets of information in the TDESC files:
== MUIDs ===
Each tunable field now has a MUID attribute. The MUID uniquely identifies the underlying tunable structure of the field. Descriptions are ignored, meaning that two fields that are functionally equivalent but have different descriptions will share the same MUID.
== Version History ==
Each TDESC file may now include a version history. The history provides a change log of the fields in the TDESC from previous versions. Compare the previous version's TDESCs to determine what new items have been added to the version history. You will find some actions recorded predate 1.5.149, you can ignore those changes.
There are two types of actions:
=== kRemove ===
This indicates that a field was removed.
For example, in Career.tdesc:
... indicates that a field with that MUID was removed, and is no longer valid tuning for the game. If you reference the previous version of Career.tdesc, you'll notice that that MUID corresponds to a particular field:
If one of your tuning files specified that field, it must be removed in order for your modded content to properly match the schema. We usually remove fields that are deprecated or non-functional.
=== kRename ===
This indicates that a field was renamed. It provides the old MUID and the new MUID it was renamed to.
For example, in ObjectState.tdesc:
... indicates that, in the old version of ObjectState.tdesc:
was renamed to:
A rename action is not merely about the field's name, but also about its hierarchy. Tunables may be moved in or out of parent nodes, and those are considered rename actions and recorded as such. This is the case in the provided example. Your tuned values will still be valid, but need to be updated to match the new name and hierarchy as appropriate.
Big thanks to @SimGuruEugi for suggesting we make this change.
Thanks,
SGMS
Heads up that with patch 1.6.69 there is a tweak to the format of TDESCs being released by Maxis. Since we know that tuning mods are prone to breakage due to changes made in patches, this new format includes additional data that can be used to more easily resolve incompatible changes made in mods.
For this patch, the following files have been provided:
"1.5.149 - April Patch - TDESCs.zip" : Patch 1.5.149 TDESCs.
"1.5.149 - April Patch - TDESCs + MUIDs.zip" : Patch 1.5.149 TDESCs in the new format.
"1.6.69 - May Patch - TDESCs.zip" : Patch 1.6.69 TDESCs in the old format, so that existing tools
used to consume the TDESCs will not be broken.
"1.6.69 - May Patch - TDESCs + MUIDs.zip" : Patch 1.6.69 TDESCs in the new format.
Note that future patches will only supply the TDESCs in the new format.
The 1.5.149 TDESCs are provided in order to take advantage of the new data, which requires you to compare the old TDESCs against the new ones to determine what has changed.
The change involves including metadata in the TDESCs file to make it easier for you to understand how the structure of the tuning has changed. There are two new sets of information in the TDESC files:
== MUIDs ===
Each tunable field now has a MUID attribute. The MUID uniquely identifies the underlying tunable structure of the field. Descriptions are ignored, meaning that two fields that are functionally equivalent but have different descriptions will share the same MUID.
== Version History ==
Each TDESC file may now include a version history. The history provides a change log of the fields in the TDESC from previous versions. Compare the previous version's TDESCs to determine what new items have been added to the version history. You will find some actions recorded predate 1.5.149, you can ignore those changes.
There are two types of actions:
=== kRemove ===
This indicates that a field was removed.
For example, in Career.tdesc:
<Action type="kRemove" old_muid="FF49432F3B0399CD" />
... indicates that a field with that MUID was removed, and is no longer valid tuning for the game. If you reference the previous version of Career.tdesc, you'll notice that that MUID corresponds to a particular field:
<Tunable type="int" name="text" class="TunableLocalizedString" default="0x0" display="Text" muid="FF49432F3B0399CD" description="The prompt's text." Deprecated="False" filter="0" group="General" />
If one of your tuning files specified that field, it must be removed in order for your modded content to properly match the schema. We usually remove fields that are deprecated or non-functional.
=== kRename ===
This indicates that a field was renamed. It provides the old MUID and the new MUID it was renamed to.
For example, in ObjectState.tdesc:
<Action type="kRename" old_muid="894D2902A31E0E27" new_muid="FBB604B5A8C86BFD" />
... indicates that, in the old version of ObjectState.tdesc:
<Tunable type="int" name="display_name" class="TunableLocalizedString" default="0x0" display="Display Name" muid="894D2902A31E0E27" description="A localized string that may NOT require tokens." Deprecated="False" filter="0" group="General" />
was renamed to:
<Tunable type="int" name="enabled" class="TunableLocalizedString" default="0x0" display="Enabled" muid="FBB604B5A8C86BFD" description="The instance's name." Deprecated="False" filter="0" group="General" />
A rename action is not merely about the field's name, but also about its hierarchy. Tunables may be moved in or out of parent nodes, and those are considered rename actions and recorded as such. This is the case in the provided example. Your tuned values will still be valid, but need to be updated to match the new name and hierarchy as appropriate.
Big thanks to @SimGuruEugi for suggesting we make this change.
Thanks,
SGMS
Post edited by EA_Cade on
5
Comments