Questions about simdata format
I'm probably going to need @SimGuruModSquad for this one :smile: I have a few questions about the correspondence between SimData files and XML tuning. First of all, let's take a look at the tra...
Forum Discussion
Hi guys,
In order to get the values of dynamic enums (as well as to override existing tuning XML files) you need to decode the combined tuning resource (0333406c:00000000:6e036824229d66d8 in SimulationFullBuild0.package). Dynamic enums have two components; a fixed set of values defined in Python (and reflected in the tdesc file), and a dynamic list which are stored as tunable lists of strings. As an example, tags are defined by Tuning/tags.tdesc. The tags.Tag enum type has one fixed value (INVALID = 0) and a dynamic list stored under tag.Tag._elements.
The combined tuning file makes heavy use of references, and you will need to expand these references in order to fully reconstruct the original tuning. However, the tag list is fairly simple to decode. You can find the root of the "tag" module tuning by searching for this element:
Inside that is the Tag class tuning, which starts with:
Inside this is a list of elements:
The tag enum values follow inside... pairs.
To answer your next question, each simdata resource corresponds to a single tunable object, but the format supports multiple tables with multiple rows each. The reason for this is that XML is hierarchical but simdata is tabular. The simdata format represents nested data using references to rows in sub-tables. While it would be technically possible to put data for two traits into one simdata resource, the game would not be able to do anything with this since the simdata resource for a particular trait is looked up by resource key.
Hope that helps, thanks!
In order to get the values of dynamic enums (as well as to override existing tuning XML files) you need to decode the combined tuning resource (0333406c:00000000:6e036824229d66d8 in SimulationFullBuild0.package). Dynamic enums have two components; a fixed set of values defined in Python (and reflected in the tdesc file), and a dynamic list which are stored as tunable lists of strings. As an example, tags are defined by Tuning/tags.tdesc. The tags.Tag enum type has one fixed value (INVALID = 0) and a dynamic list stored under tag.Tag._elements.
The combined tuning file makes heavy use of references, and you will need to expand these references in order to fully reconstruct the original tuning. However, the tag list is fairly simple to decode. You can find the root of the "tag" module tuning by searching for this element:
Inside that is the Tag class tuning, which starts with:
Inside this is a list of elements:
The tag enum values follow inside
To answer your next question, each simdata resource corresponds to a single tunable object, but the format supports multiple tables with multiple rows each. The reason for this is that XML is hierarchical but simdata is tabular. The simdata format represents nested data using references to rows in sub-tables. While it would be technically possible to put data for two traits into one simdata resource, the game would not be able to do anything with this since the simdata resource for a particular trait is looked up by resource key.
Hope that helps, thanks!
Featured Places
