Andirz.com

Participants & Resolvers

A beginner-friendly guide to Participants and Resolvers in The Sims 4: Actor, TargetSim, PickedSim, SavedActor, stored Sims, households, objects and context-sensitive tuning.

The Sims 4 Modding Encyclopedia · Context & Targeting

Participants answer “who or what?” Resolvers provide the context that makes that answer possible.

Many tuning problems are not caused by the test, loot or interaction itself. They happen because the logic is applied to the wrong participant, or because the current resolver does not contain the participant you expected.

Understand common and specialized participants Understand saved and picked participants Understand what a resolver does Debug context-sensitive tuning
1 Big picture 2 Participants 3 Saved & stored 4 Objects & households 5 Resolvers 6 Tests & loot 7 Common errors 8 Debugging workflow

1. The big picture

A lot of Sims 4 tuning is reusable. A test or loot action does not need to know the identity of a specific Sim in advance. Instead, it asks the current context for a participant.

Participant

A named role such as Actor, TargetSim, PickedSim or SavedActor1.

Resolver

The runtime context that maps those role names to actual Sims, objects, households, lots or values.

Test

Uses the resolver to ask a question about one or more participants.

Loot

Uses the resolver to decide who or what receives an effect.

Mental modelParticipant = role name. Resolver = the current map from that role name to the actual game entity.

2. The participant vocabulary

The exact participant enum available depends on the tuning class and resolver. The site’s hidden builder currently exposes the following participant names for several common test contexts; these are useful as a practical reference, not a promise that every one exists everywhere.

Participant Usually represents
Actor The Sim performing or owning the current action/context
TargetSim The Sim targeted by the action
PickedSim A Sim chosen by a picker
StoredSim A Sim stored by the current gameplay context for later reuse
StoredSimOnActor A stored Sim reached through the Actor’s context
OwnerSim The Sim who owns the relevant object/entity when that ownership is available
SignificantOtherActor Actor’s significant other
SignificantOtherTargetSim TargetSim’s significant other
ActorFiance Actor’s fiancé/fiancée participant when available
TargetFiance TargetSim’s fiancé/fiancée participant when available
PregnancyPartnerActor Pregnancy partner resolved from Actor
PregnancyPartnerTargetSim Pregnancy partner resolved from TargetSim
CareerEventSim Sim supplied by a career-event context

Picked participants

A picked participant is created when some earlier UI or gameplay step selects something.

Open Sim picker
  → player chooses Sim B
  → Sim B becomes PickedSim
  → later test/loot can target PickedSim

The same idea applies to PickedObject and, in contexts that support it, PickedStatistic.

PickedSim is not just another name for TargetSim.
TargetSim normally comes from the interaction target. PickedSim comes from a selection step. If nothing created that picked participant, the resolver cannot magically provide it.

3. SavedActor, StoredSim and why saved participants exist

The builder exposes SavedActor1, SavedActor2, SavedActor3 and SavedActor4. These are numbered participant slots used by systems that save a participant earlier and need to retrieve that same entity later.

Conceptually:

Earlier step
  → save Sim A into SavedActor1
Later step
  → resolver exposes SavedActor1
  → test or loot can act on that same Sim

This is useful in multi-stage interactions and other gameplay where the relevant Sim at the end is not necessarily the current Actor or TargetSim anymore.

Saved ≠ currentActor describes the current role. SavedActor1–4 preserve a participant slot so later logic can refer back to an earlier entity.

StoredSim vs SavedActor

Both ideas solve the same broad problem — remembering a Sim across pieces of logic — but they belong to different participant mechanisms/contexts. Do not treat the names as interchangeable. If EA tuning uses StoredSim, copying it and replacing it with SavedActor1 changes where the resolver tries to get the Sim from.

The same warning applies to StoredSimOnActor: the name tells you that the stored Sim is being resolved through Actor-related context, not simply from a generic saved slot.

Best way to learn a saved participant
Find an EA interaction from the same system and trace where that participant is first saved, then where it is consumed. The enum name alone does not tell you who filled the slot.

4. Object, household and lot participants

Participants are not limited to Sims.

The object-oriented participant selector used by the builder includes:

Participant Practical meaning
Object The primary object in the current context
ActorSurface Surface associated with Actor/current interaction context
CarriedObject Object currently being carried in the relevant context
CraftingObject Object involved in crafting
CreatedObject Object created by an earlier action
PickedObject Object chosen by a picker
ObjectParent Parent object of the current object
ObjectInventoryOwner Owner/container of an object’s inventory context
RandomInventoryObject An object selected from an inventory by the relevant system
ObjectAnimalHome Animal-home object associated with the current object/context
SituationCraftingItem Crafting item provided by a situation context
ObjectCrafter Sim associated with having crafted the object, where available

These participants explain why object-state tests and loot can look correct but still operate on the wrong object.

Household and lot participants

The current participant list also includes:

Participant Usually represents
ActiveHousehold The currently active household
ActorHousehold Actor’s household
TargetHousehold TargetSim’s household
Lot The current/resolved lot
LotOwnerSingleAndInstanced A resolved lot owner in contexts that expose one

For example, taking money from ActorHousehold is conceptually different from operating on ActiveHousehold. They may happen to be the same household during normal player control, but they do not mean the same thing.

5. What a resolver actually does

A resolver is the runtime context that answers questions such as:

  • Who is Actor?
  • Who is TargetSim?
  • Was a Sim or object picked?
  • Is there a SavedActor1?
  • Which household belongs to Actor?
  • Which object is being crafted or carried?
  • Which lot or career-event Sim is relevant?

You usually do not create resolvers when working only in XML tuning. But understanding them explains why the same reference can work in one place and fail in another.

Same loot, different resolver

A reusable loot action configured for Actor does not point to one fixed Sim. Interaction A resolves Actor to Sim A; Interaction B can resolve Actor to Sim B. The loot stays the same while the resolver changes the entity behind the role.

Not every resolver provides every participant

An ordinary object interaction may expose Actor and Object but no PickedSim. A picker can expose PickedSim only after a selection. A career event can expose CareerEventSim. A multi-stage system may expose SavedActor slots.

Core ruleA participant enum can be valid in the game and still be unavailable in the resolver evaluating your tuning.

This is why copying one field from unrelated EA tuning often fails even when the XML and ID are perfectly valid.

6. Participants in tests and loot

Trait test

participant = Actor
question = Does Actor have Trait X?

Changing only one field:

participant = TargetSim
question = Does TargetSim have Trait X?

produces a completely different condition.

Statistic test

Actor Programming >= 5

is not equivalent to:

TargetSim Programming >= 5

The builder’s current test examples also use TargetSim as the default subject for several skill and trait-availability tests, which is a useful reminder to check the subject field instead of assuming Actor.

Relationship logic

Relationship systems frequently need two resolved participants:

source = Actor
target = TargetSim

Directional relationship data can behave differently if the pair is reversed.

Loot

Loot answers what changes, but participants answer who receives that change.

loot participant = Actor
  → Actor receives Buff X

versus:

loot participant = PickedSim
  → the Sim selected in the picker receives Buff X

versus:

loot participant = SavedActor1
  → the Sim previously saved into slot 1 receives Buff X
Related reading
Tests, Logic & Tooltips explains AND/OR grouping, test sets and failure tooltips. This article explains the context those tests evaluate.

7. Common participant and resolver mistakes

1Right effect, wrong Sim. Loot uses Actor when the design requires TargetSim or PickedSim.
2Using PickedSim before anything was picked. The resolver has no such participant yet.
3Using SavedActor1 without understanding who filled it. The slot can resolve an unexpected Sim or be unavailable.
4Confusing StoredSim with SavedActor. They are different participant sources.
5Testing Object when you meant CreatedObject or PickedObject. The test is valid but looks at a different entity.
6Using ActiveHousehold when ActorHousehold was intended. This can break NPC/non-active contexts.
7Copying EA tuning without its resolver context. The original interaction supplied participants your new context never creates.
8Reversing relationship participants. Directional systems can produce unexpected results.

“But the XML is valid”

Participant bugs often produce no syntax error. The XML is valid and every referenced tuning ID can exist. The logic simply resolves a different entity — or no entity — from the one you intended.

8. A debugging workflow

1
Identify the entry point

Which interaction, event, picker, situation or career event creates the context?

2
Write down the participants you actually have

Actor, TargetSim, Object, PickedSim, SavedActor1, CreatedObject, households, etc.

3
Trace where saved/picked participants came from

Find the selection or save step instead of guessing what a numbered slot contains.

4
Inspect every subject/participant field

Tests and loot often use different participant fields within the same feature.

5
Compare with EA tuning from the same context

Use another picker for picker logic, another social for social logic, another multi-stage interaction for SavedActor logic.

Worked example: Pick a Sim, then affect that Sim later

Desired flow:

Actor opens a picker
  → player selects Sim B
  → Sim B = PickedSim
  → later step saves/propagates the participant as required by that interaction chain
  → loot affects the resolved selected/saved Sim

A common broken version applies the final loot to Actor. The interaction appears to work, but Actor receives the buff instead of the selected Sim.

The fix is not necessarily “change Actor to PickedSim” blindly. First verify whether PickedSim is still available at that later stage. If the interaction saved the selection into SavedActor1, then the later resolver may expect that saved participant instead.

Best questionWhen reading any test or loot, complete the sentence: “Run this on whom — and where did that participant come from?”

Quick reference

Need Common participant
Sim performing action Actor
Sim being targeted TargetSim
Sim chosen in picker PickedSim
Object chosen in picker PickedObject
Participant preserved for later stage SavedActor1–SavedActor4
Sim stored by a storage context StoredSim, StoredSimOnActor
Actor/target partner SignificantOtherActor, SignificantOtherTargetSim, fiancé/pregnancy-partner variants
Newly created object CreatedObject
Object being carried/crafted CarriedObject, CraftingObject
Actor’s household ActorHousehold
Target’s household TargetHousehold
Current active household ActiveHousehold
Current/resolved lot Lot
Career-event participant CareerEventSim
Statistic selected by picker/context PickedStatistic