Tests & Logic

1. What is a test?

A test asks a question about the current game state and returns a result that is effectively pass or fail.

Examples:

• Does the Actor have a specific trait?
• Is the TargetSim an Adult?
• Is a skill at least level 5?
• Is an object in the required state?
• Is the current lot residential?
• Does this relationship have the required bit?
• Is the Sim missing a cooldown buff?

That means a test and loot have opposite jobs:

2. Common test families

The game contains many specialized tests. Beginners do not need to memorize all of them; it is more useful to recognize the question each one asks.

Trait test example

Conceptually:

PASS if Actor has trait_X
FAIL otherwise

The same test family can also work as a blacklist:

PASS if Actor does NOT have trait_X
FAIL if trait_X is present

This is why reading only the word trait is not enough. You still need to inspect whether the list is a whitelist, blacklist, required set, excluded set, or another variant.

Buff tests are excellent for cooldowns

A hidden temporary buff can act as a timer:

Interaction succeeds
  → adds cooldown buff for 120 Sim minutes
  → test requires that cooldown buff is absent
  → interaction cannot be used again until buff expires

That is a common pattern because the buff stores temporary state while the test enforces the restriction.

3. AND and OR logic

The easiest way to understand test logic is with ordinary Boolean logic.

AND

With AND, every required condition must pass.

Adult AND has Cooking 5 AND not Tense

The interaction is allowed only when all three are true.

OR

With OR, one successful branch can be enough.

Has trait_A OR has trait_B

Groups matter

The most important beginner trap is assuming that every list of tests means the same thing.

A common structure is effectively:

GROUP 1: test A AND test B
OR
GROUP 2: test C AND test D

So the whole structure passes if one complete group passes.

Negation

Many tests also express the opposite condition:

NOT has trait_X
NOT has buff_Y
NOT object state = Broken

In tuning this may be represented by blacklist fields, inverted variants, flags or specialized configuration rather than a literal NOT keyword.

4. Participants: who are you actually testing?

A perfectly written test can still behave incorrectly if it checks the wrong participant.

Common participants include Actor, TargetSim, target objects, picked Sims/objects, owners, household members and situation participants.

For the full participant system, including PickedSim, SavedActor and resolver context, see Participants & Resolvers.

5. Tests in interactions

Interactions are one of the places where beginners encounter tests most often. You will frequently see test logic under fields such as test_globals, while other interaction systems can apply additional tests elsewhere.

Typical purposes include:

• hiding an interaction completely;
• showing it only for certain Sims or objects;
• preventing autonomous use;
• allowing user-directed use but not autonomy;
• blocking use while another state is active;
• requiring a pack, trait, skill, relationship or object state.

Conceptually:

Player clicks object
  → interaction candidate is evaluated
  → tests run
  → PASS: interaction can be offered/run
  → FAIL: interaction is hidden or unavailable, depending on the context/configuration

Availability and autonomy are not the same thing

An interaction can pass the tests required to appear in the pie menu and still fail autonomy-specific logic. Likewise, an interaction may be available for autonomy but restricted for direct player use if the tuning is configured that way.

6. Tooltips: when do they actually matter?

A tooltip is useful only when the player can encounter an unavailable option and needs to understand why it is unavailable. This is a UX decision, not a requirement for every test.

Good use of a failure tooltip

Imagine a visible interaction is disabled because the Sim needs Cooking level 5. A useful tooltip would say something like:

Requires Cooking Level 5

The player can see the option, understands the requirement, and knows what to do next.

When a tooltip is usually unnecessary

A tooltip adds little value when the failed condition is purely internal or the interaction should not be exposed at all, for example a hidden developer interaction, special NPC role, invisible cooldown or internal situation/loot condition.

Tooltip vs interaction name

The display name tells the player what the interaction does; the failure tooltip explains why it cannot currently be used. Both are localized strings. See STBL & Localization for the text/localization side.

Tooltips can depend on the failed test

In some tuning structures, individual tests can provide their own tooltip. That can let an age test, skill test and object-state test each provide a different reason. When several conditions fail at once, however, the UI path may not expose every reason, so each tooltip should make sense independently.

7. How to debug broken test logic

Example debugging problem

You want:

Adult AND (Trait A OR Trait B)

But accidentally build:

(Adult AND Trait A) OR Trait B

Now any Sim with Trait B can pass even when they are not an Adult. The individual tests are correct; the grouping is wrong.

Quick reference