Quest Data

A quest definition combines objectives, rewards and rules for when a player or team may accept it. Definitions reload as one validated catalogue: a broken prerequisite graph or invalid definition keeps the previous catalogue intact.

Where the files live

Use data/<namespace>/quests/**/*.json. Each file defines one quest; data/example/quests/misc/visit.json normally becomes example:misc/visit. An explicit id overrides that identity. Ordinary resource-pack priority selects the resource at a shared file path; different surviving files that claim the same quest ID reject the quest catalogue reload.

Quest definitions are server data. Titles and descriptions are client translations in assets/<namespace>/lang/en_us.json and zh_cn.json, not fields inside the quest. This checkout’s demonstration quests in docs/examples/quests/ are authoring fixtures rather than installed gameplay content.

Minimal example

This is the visit-location objective shape used by the demonstration fixtures, reduced to required fields. Save it at data/example/quests/first_tick.json. It completes on the next qualifying player tick after acceptance because it has no location filter; add an objective condition to require a destination.

{
  "tier": "misc",
  "prerequisites": [],
  "objectives": [
    {
      "id": "visit",
      "progress_type": "boolean",
      "type": "isekaiexpansion:visit_location",
      "data": {}
    }
  ],
  "rewards": []
}

Fields

Root

Tier and pool names trim whitespace, ignore case and replace spaces/hyphens with underscores. Pool constants are DEFAULT, TOWN, COMBAT, DEBUG, ADVANCEMENT, CRAFTING, FORGERY and ALCHEMY; their JSON names are default, town, combat, debug, advancement, crafting, forgery and alchemy.

The normal pick path permits a solo player or a team’s owner. It rejects already-active quests and unmet prerequisites, then checks cooldowns and pick conditions. Main-story selection uses the first eligible definition ordered by minimum story progress, then quest ID. Misc selection uses relative weights among eligible candidates in the requested pool and optional chapter; weight does not bypass eligibility. A completed misc quest must remain unlocked for repetition.

Prerequisites, objectives and rewards

Objective payloads and event filters are documented in Quest objectives. Reward payloads and recipient selection are in Quest rewards.

Pick conditions

Condition objects use type and data. Arrays at any condition-node position are shorthand for isekaiexpansion:all. The following table describes general conditions used by picking and objective content triggers; it does not describe objective event-filter leaves.

Online-member checks do not count offline teammates and do not require the same dimension. If no matching online member is found and there is an acting player, that player is the fallback member.

For objective_progress, boolean false/true becomes 0/1. Numeric crossed_only requires previous progress below min and new progress within the inclusive range; jumping beyond max fails. Boolean crossing requires false → true, as well as the range check. Ordinary pick conditions should use player/team leaves, not objective progress.

Isekai Core owns adventurer ranks. Checked against its local source checkout for the consumed 0.4.0-build60: accepted promotion targets are copper, silver, gold, diamond, mythril, adamantite, stormyx and celestium, case-insensitive and trimmed. none is rejected here. Readiness requires the next rank and, beyond the initial rank, the dependency’s reputation requirement; already holding the target does not pass readiness. This is a source-checkout verification, not a claim of binary equivalence.

Resolution cooldowns

Despite the field name, both completion and failure start the resolution clock. THIS uses this quest’s most recent resolution. ALL uses the latest resolution, in this profile, among currently loaded quests that have a positive ALL rule. It does not use every quest indiscriminately.

Each candidate applies its own authored duration to the relevant clock. Both rules must expire before selection succeeds; negative elapsed time is treated as 0, and no previous resolution means no cooldown. Time is world game time, not real-world time spent with the server stopped.

Translation keys

Paths replace slashes with dots. Objective IDs replace both slashes and colons with dots. Choose IDs whose normalised forms remain distinct; unique raw IDs alone do not guarantee unique translation keys.

Validation

Malformed JSON text can be discarded by the underlying resource-reading stage before quest validation. The atomic guarantee applies to the definitions delivered to the quest parser; it is not a promise that every unreadable resource preserves an earlier entry.

Reloading

Server data reload rebuilds the catalogue and increments its revision only after definition and prerequisite-graph validation succeeds. A successful empty catalogue replaces the old one. Saved quest profiles are separate from these definitions; changing IDs is not a save-data migration.

Full client synchronisation sends visible definitions and the corresponding filtered profile. Clients still need translation assets locally. The Quest runtime page describes sync triggers, active-state reconciliation and diagnostics.

Related

• Quest objectives — objective types, event filters, delivery, content actions and failures.
• Quest rewards — reward fields, recipients and failure handling.
• Quest runtime — state ownership, persistence and integration.