Sign in to Mod The Sims
Replies: 0 (Who?), Viewed: 3616 times.
#1
10th Sep 2014 at 11:22 AM
10th Sep 2014 at 11:22 AM
Info | XML tuning and simdata files
C+ P from EA forums, for interested parties:
Quote: Originally posted by thequux2
|
I have a few questions about the correspondence between SimData files and XML tuning. First of all, let's take a look at the trait_Novelist trait from the novelist package that was in the docs. I've figured out that the enumeration for Ages is defined in the Python that was provided, but I'm not sure where the values for tags (column 11) come from, particularly because the field refers to a dynamic tag in the tdesc file (and python code). Second, it seems that you have multiple objects packed into one table: table[1] has both tags and ages stored in it, and table[2] has two different strings. Am I understanding the file format correctly? Third, could you clarify how the game turns SimData files into objects (in the CS sense) that appear in the game? Based on the first version of the novelist example (with just two simdata resources and two XML files), the trait is found by scanning the package files. However, the only thing I can find that indicates that there is a trait resource is the fact that the SimData file has a schema named "Trait". Would it be valid for a SimData file to have two traits stored in it, and if so, what would the game do with such a resource? Third, in order to make sense of the simdata file, it looks like I'll need data files derived from the python archives from the game. Would it be allowed to distribute works derived from the python files and TDesc files? (I need the tuning descriptions from the tdescs and the enumerations from Python). |
Quote: Originally posted by velocitygrass
|
The tags can be found in the following two resources: S4_545AC67A_006CA304_DDE418AFF7A9D9AD S4_545AC67A_006CA304_D89CB9186B79ACB7 Table[1] includes all object of type 0x00000008, but like all tables that don't have a structure position set, it's only a container. In this case, the ages field of the main struct is a list with seven elements starting at the position of the first element in the table. So the first 7 elements in table[1] belong to that first list (ages), while the other two belong to the tags array. Same goes for table[2]. It's a container for all strings used elsewhere (in this case only the null for cas_idle_asm_state and the None for cas_trait_asm_param). (I haven't actually looked too deeply into the simdata info in the bt file so far, so this is from my own observations while I was writing my tool.) |
Quote: Originally posted by thequux2
|
Awesome! That pretty much squares with what I had imagined, though it's good to know about the tag resources. Also, are there any docs on the filename format that the modding community tends to use? Is it just S4_{type}_{group}_{instance}, in all caps in hex, or is there more to it than is immediately apparent? So far I've just been using the "{group}!{type}.{instance}" format that the game engine seems to use internally (so you can use an unpacked package just the same as a packed one) |
Quote: Originally posted by SimGuruModSquad
|
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: <M n="tag" s="15608553923092786359"> Inside that is the Tag class tuning, which starts with: <C n="Tag"> Inside this is a list of elements: <L n="_elements"> The tag enum values follow inside <T>...</T> 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. |
--
|
|