Skip to main content

Test an inverted BetonQuest condition with both player states

Applies to: BetonQuest; match the linked maintainer documentation to your installed platform and release.
Documentation checked .

An inverted condition can accidentally make a quest available only to the wrong players. Write a pass-and-fail table before changing the condition on a reward or conversation branch.

Check the installed content

BetonQuest expresses a quest through objectives, conditions, events and conversation links. Keep the package and player state together during testing. The linked reference describes the 2.2 documentation branch; select the corresponding documentation if your server runs another major version.

Work through the change

  1. Record the condition ID and the player state it checks. Describe in plain language when the branch should be available and when it should be hidden or rejected.
  2. Check the installed-branch scripting and condition references for negation and condition-list syntax. Keep the underlying condition definition separate from the place that inverts its result.
  3. On staging, prepare one disposable account that satisfies the condition and one that does not. Use a harmless observable branch rather than currency or item issuance.
  4. Run the same interaction with both accounts, change the relevant test state through supported tools and repeat. Inspect combined conditions individually before testing their full conjunction.

Verify the result

The branch should follow the written truth table for both states and their transitions. Inversion should change eligibility, without unexpectedly changing the event target or creating another reward path.

If the result differs

If both accounts behave alike, inspect the underlying state and package reference. If one additional condition changes the result, test that condition separately rather than adding another negation as a guess.

Keep a recovery path

Restore the earlier condition reference and keep the reward harmless if any case fails. Preserve live player state; changing a condition should not require clearing tags, objectives or completed quests for every account.

References and related help

Check the maintainer reference: BetonQuest documentation, BetonQuest documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.