Tuning Standards: TunableType

In The Sims 4 XML Tunings, there is a standard on how to represent certain Tunables as a certain Character or Attribute.

For a more in-depth explaination, refer to this article written by LeRoiDeTout: Medium Article

Base Tunables
There are quite a number of Base Tunables that are used by the game, Depending on their structure it can be in the form of  or  or etc.

They Include:


 * Instance Tunable (Excluding Module Tunings) 
 * Module Tunable (Used only in Module Tunings) 
 * Class Tunable (Used only in Module Tunings) 
 * Tunable  or  based on usage
 * TunableVariant  or  or <V n="" t=""></V> based on usage
 * TunableTuple <U></U> or <U n=""></U> based on usage
 * TunableEnum <E></E> or <E n=""></E> based on usage
 * TunableList <L></L> or <L n=""></L> based on usage
 * TunableSet <L></L> or <L n=""></L> based on usage
 * TunableMapping <L n=""> <U></U> </L>

Instance, Module & Class Tunables
These Tunables are the base elements to a Tuning, be it an Interaction, Snippet or even a Module Tuning.

Instance Tunables
Most Tunings use the Instance Tunable as the base element. Inside the Instance Tunable, there are a few Things that make up the Instance Tunable:


 * class (c)
 * instance type (i)
 * module (m)
 * name (n)
 * sequential ID (s)

The n and s refer to the Instance Name and the Instance ID, where they are used in other forms of tuning parts.

c, i, m all correspond to the referenced Python Script where c infer to the class name (i.e. SuperInteraction) while i would probably infer to the base class script file from which other subclasses uses (i.e. SuperInteraction derives from Interaction Class which is in interaction.__init__ (__init__ takes the name of the folder which interaction.__init__ would mean interaction) and m refers to the module name from which where the class derives from, which have to start from simulation file (i.e. buffs.buff, snippets)

Module & Class Tunables
Only the Module Tuning (or Tuning or tun) uses the Module and Class Tunables which reflects towards to the Python Script.

Tunable 
The tunable is a BaseTunable that does not have any tunables after it. The Tunable by itself can be used for data types such as str, int, float, bool, etc. However there are many Sub-Tunables that have other functions:


 * TunableLocalizedString - used to hold String IDs (0x0)
 * TunableReference - Used to Reference to an Instance (i.e. Interaction Instance)
 * TunableBuffReference - Buff Specific Reference

Iterable Tunables <L> <U>
Iterable Tunables are an object that can hold values. In Python, there are 4 types of Iterable Objects:


 * Sets
 * List
 * Tuple
 * Dictionary - Or dict when used in Python

Depending the type, each storable iterable have certain limitations and certain advantages when used.

TunableList <L> | []
TunableList is an ordered and changeable List which allows for a list of a specified tunable. The TunableList is very commonly used in many situation like super_affordances in an Object Tuning or values in a AffordanceList.

Injection/Overrides In Scripting
TunableLists can be be appened on either through the .append function or using +=. For Overridding, a = would suffice in rewriting the tunables inside a TunableList.

TunableTuple <U> |
TunableTuple is an ordered and unchangeable Tuple which allows for a list of specified tunables prior to naming of tunables. The TunableTuple is very commonly used as a TunableFactory with or without a TunableVariant.

TunableSet <L> | {}
TunableSets is an unordered and unchangeable frozenset which is not commonly used. Only super_affordances, actor_mixers and provided_mixers use TunableSet which makes injection frustrating, which results to using buffs instead or just injecting onto the Sim Object.

TunableSet uses the <L> attribute despite not being a list, it is recommended to check the TDESC for a Tunable's Class (i.e. The buff super_affordances uses the TunableSet class).

TunableMapping <L> <U> | {"key:x, "value":y}
TunableMapping is a Dictionary which uses the <L> and <U> attributes which allows for iteration across different entries of a dictionary. The example below uses a Tunable Mapping. It is actually possible to use a TunableList and a TunableTuple combined to achieve the same outcome as the TunableMapping but with more entries from specifying the TunableTuple.

Accessing entries in TunableMapping In Python
Accessing entries in a TunableMapping requires the use of the .items function as TunableMapping is a dictionary. .items opens up the TunableMapping which would in turn allow you to access the entries. The example below shows the method of accessing data inside a TunableMapping.

TunableEnums <E>
TunableEnums are Tunables that only accept Enums. These Enums must match to the tuned enum class that is specified in the TunableEnum and it needs to exist in the enum class. There are two types of TunableEnums, they are:


 * TunableEnumEntry <E>
 * TunableEnumFlags <L> <E>

TunableEnumEntry is the base Tunable that can use Enums. A TunableEnumEntry can only use Enums from a specified class (In TunableEnumEntry, its referred as tunable_type) including if the specified Enum exists.

TunableEnumFlags are a TunableList that its tunable accepts TunableEnumEntries. This is main used in pickers and dialogs, specifically in dialog_options. Not much is known of this form of tunable as it is rarely used.

TunableVariant 
TunableVariants are a Tunable that are typically used inside basic_extras, basic_liabilities or even in tests. In those cases, the t (tunable) in the TunableVariant would take the form of the Tunable after it. (i.e. <V t="trait"> <U n="trait">).

TunableVariants can also take the form of an OptionalTunable, where the n (name) infers to the name of the tunable while t would infer as enableor disabled (or whatever was tuned to be the name when enabled/disabled).

TunableVariants are not used very often in basic modding as TunableLists, TunableTuple, Tunable, etc are typically used instead.