What Is Tuning?

Before we begin

You do not need Python or advanced XML to understand tuning. The important part is recognizing the data structures and the relationships between resources. Once you can distinguish a scalar value, an enum, a list, a structured group and a reference, an unfamiliar tuning file becomes much easier to read.

1. What is tuning?

A large part of The Sims 4 gameplay is configured through tuning resources. They describe values, choices, lists, tests and references to other resources.

Python provides engine systems and classes; tuning supplies much of the data those systems consume. Many mods therefore need no Python at all if the game already provides the behavior the modder wants to configure.

XML is not the tuning system itself. XML is the readable representation modders usually inspect and edit.

2. Anatomy of a tuning resource

Consider this opening element:

<I c="Skill" i="statistic" m="statistics.skill" n="statistic_Skill_AdultMajor_RocketScience" s="16710">

The name is mainly useful to humans. The numeric ID is what makes the resource addressable by other tuning.

3. IDs, comments and references

A reference to another tuning resource often looks like this:

<T>16710<!--statistic_Skill_AdultMajor_RocketScience--></T>

The game uses 16710. The XML comment is only a human-readable label.

Who creates the ID?

For EA resources, EA already assigned the ID when the game content was built. When you export an EA tuning resource, Sims 4 Studio simply shows the ID that already exists.

For your own custom tuning, you create the ID. The normal modding workflow is to derive it from a unique internal tuning name with a hash function.

You choose a unique tuning name
            ↓
Sims 4 Studio Hash Generator
            ↓
        FNV32 / FNV64
            ↓
      numeric Instance ID

For example:

andirz_MyMod_CustomInteraction

is a name you invent. You then open Sims 4 Studio → Tools → Hash Generator, enter that name, and use the appropriate FNV result as the resource Instance.

The screenshot shows why modders often talk about the same ID in two different forms. Sims 4 Studio gives you the generated hash for the resource key, while XML normally displays the tuning ID as a decimal integer. You are not creating two IDs: you are looking at one number represented differently.

Decimal vs hexadecimal: where do you see each one?

The same ID can be displayed in different numeral systems.

Decimal:      16710
Hexadecimal:  0x4146

They are the same integer.

For example:

Sims 4 Studio Instance: 0xA1B2C3D4
XML tuning:              s="2712847316"

These represent the same 32-bit value.

The package resource key

A DBPF package resource is identified by a key commonly represented as:

Type + Group + Instance

These three fields have different jobs:

So two resources can deliberately share an Instance while still being different package resources because their Type differs. Trait tuning plus its companion SimData is the classic example.

FNV32 and FNV64

• FNV32 produces a value that fits in 32 bits: at most 8 hexadecimal digits.
• FNV64 produces a value that fits in 64 bits: at most 16 hexadecimal digits.
• The correct width depends on the resource system.

For ordinary custom tuning, FNV64 is common. Custom traits should use FNV32, and their matching SimData must use the same Instance. See Traits & Preferences → Trait IDs & SimData.

4. Common data structures: T, E, L, U and V

The short XML tags represent familiar data structures. The examples below use deliberately fake loot names so that the structure is realistic without pretending that the sample IDs are EA resources.

<T n="loot">100000001<!--loot_Example_AddBuff--></T>

<E n="subject">Actor</E>

<L n="loot_actions">
  <T>100000001<!--loot_Example_AddBuff--></T>
  <T>100000002<!--loot_Example_GiveMoney--></T>
</L>

<U n="entry">
  <T n="loot">100000003<!--loot_Example_RemoveTrait--></T>
  <T n="weight">5</T>
</U>

<V n="action" t="loot">
  <U n="loot">
    <T n="loot">100000001<!--loot_Example_AddBuff--></T>
  </U>
</V>

<L n="entries">
  <U><T n="loot">100000001<!--loot_Example_AddBuff--></T></U>
  <U><T n="loot">100000002<!--loot_Example_GiveMoney--></T></U>
</L>

The n attribute identifies the field being configured. The tag tells you the shape of the data, while n="..." tells you which tunable field receives that data.

5. SimData: the companion data resource

Some tuning types also use a companion SimData resource. SimData stores structured data in a binary/table-oriented form that some game systems expect alongside tuning.

XML Tuning = hierarchical configuration you normally read/edit
SimData    = companion binary/table data used by some resource types

For resource types that require SimData, the companion resource normally uses the same Instance ID as the tuning resource.

In the Sims 4 Studio resource list, compare the columns rather than just the resource names. The Type tells Sims 4 Studio and the game what kind of resource each row contains. The tuning row and the SimData row therefore have different Type values. Their Instance, however, is intentionally identical so the companion data belongs to the same logical tuning resource. The Group is another part of the package key and is normally kept consistent with the resource pattern you cloned or created.

Custom traits are the important beginner example: keep Trait tuning and matching SimData together. If you change the trait’s Instance but leave the old SimData Instance behind, the package may still contain both rows while the logical pair is broken.

6. How to read tuning without guessing

What you should know now

You should now be able to answer: Who assigned this ID? If it is mine, how did I generate it? Is the same number being shown in decimal or hexadecimal? What do Type, Group and Instance identify? Which fields are configured? Which values are references? Does the resource need companion SimData?