Actions, Loot & Outcomes

Gameplay resources often describe state or conditions, but something still has to perform the change. This is where actions, loot, Basic Extras and outcomes become important.

1. Loot: where many gameplay changes happen

In Sims 4 modding, loot does not mean an item dropped by an enemy. A loot action is gameplay logic that performs one or more changes.

Depending on the operation, loot can:

• add or remove a trait;
• add or remove a buff;
• change a statistic, skill, motive or commodity;
• change relationships;
• give or remove money and rewards;
• change object or Sim state;
• trigger additional loot or feature-specific operations;
• apply an effect to Actor, TargetSim or another participant.

A common chain looks like this:

Interaction succeeds
  → outcome is selected
  → loot runs
  → buff / trait / statistic / relationship changes

This is why a resource can look as though it “does nothing” until you follow its loot references.

2. Real EA loot examples

A good way to learn loot is to compare several real resources that do very different jobs. The examples below come from EA tuning and show why the word loot describes a container for consequences rather than one specific kind of effect.

The important lesson is not to memorize these names. It is to open several EA loot resources and ask: what operation is selected, which participant receives it, and which tests must pass?

For example, the Cowplant loot is useful because the result is not a visible moodlet or trait. It modifies a statistic. A loot action can therefore have a gameplay effect even when nothing obvious appears in the UI.

Cowplant interaction
  → Cowplant_PlayWith_Loot
  → statistic change
  → Gardening +15

The cauldron Luck examples show another important pattern. A single feature can split success and failure behavior into several reusable loot resources. One failure loot can add a trait, another can remove one, while the success loot can contain individual tested operations.

3. Loot is reusable

One advantage of loot tuning is that the same action logic can be referenced from different systems instead of rewriting the same consequence everywhere.

For example, one loot resource could represent the conceptual action “grant reward state” and be triggered by several interactions, a buff lifecycle event, a situation goal or another gameplay system.

Interaction A ─┐
Interaction B ─┼→ shared loot → add trait + change statistic
Situation goal ┘

The exact structure varies by loot class. Some loot resources are primarily containers for several operations; others represent more specialized action types. When reading unfamiliar tuning, inspect the selected variants and references rather than assuming every loot resource has the same fields.

4. Tests inside or around actions

Actions are often conditional. A test can occur before the action is reached, or an action structure can contain conditional branches of its own.

Conceptually:

Test: Actor has required trait?
  YES → run loot
  NO  → do nothing / use another branch

There are therefore two levels you may need to debug:

And there is a third possibility: the child action ran, but its operation, amount, reference or participant was wrong.

See Tests & Logic for test sets, AND/OR grouping and failure tooltips.

5. Basic Extras

Basic Extras are additional pieces of behavior attached directly to an interaction. You commonly encounter them in a list such as basic_extras.

They are useful for behavior that belongs to the lifecycle of that interaction rather than to a reusable result resource.

Depending on the selected extra type, an extra can participate in setup, temporary state, statistic changes, loot-like effects, visual/gameplay behavior or cleanup. The important point is that basic_extras is a container for different kinds of extras; the list name alone does not tell you what an entry does.

Loot vs Basic Extra

Do not force behavior into a Basic Extra simply because an interaction is involved. If the effect is a reusable consequence, a loot resource is often easier to understand and reuse.

6. Outcomes

An outcome represents a result of an interaction or gameplay event. It is especially useful when an action can produce different consequences depending on success, failure or another result branch.

Interaction
  → success outcome
      → success text
      → reward loot

  → failure outcome
      → failure text
      → penalty loot

The outcome itself and the consequence are not the same concept. The outcome identifies/describes the result branch; referenced loot or other action structures perform the changes associated with it.

7. Actions can be triggered from many systems

Do not search only inside interactions when trying to find where an effect comes from. Action/loot references can appear in many places, including:

• interaction outcomes;
• Basic Extras;
• buff addition/removal lifecycle logic;
• trait-related event behavior;
• situation and goal completion;
• careers, aspirations and progression systems;
• snippets and feature-specific tuning;
• Python code that explicitly invokes tuned actions.

For example, a delayed state can be built entirely through buffs and loot:

Loot A adds hidden timer buff
  → timer expires
  → buff's removal loot runs
  → Loot B adds next state

This is also why the Buffs, Moodlets & Moods article discusses loot_on_addition and loot_on_removal.

8. Participants change the meaning of the same action

The same operation can produce a completely different result depending on its participant.

Add Buff X to Actor

is not equivalent to:

Add Buff X to TargetSim

Nor should you assume that every context even has a TargetSim. The current resolver determines which participant roles are available.

9. A practical reading workflow

Quick reference