Authoring Quests & Bounties

Quests are authored in a shared schema the library owns, so the same file shape, the same field names and the same tooling serve quests and achievements alike. A contract on a board IS a quest: it reuses the quest groups verbatim and adds one group saying which boards it hangs on.

The shared quest file

YourPack.zip
├── manifest.json
└── Server/ZiggfreedCommon/
    ├── Quests/
    │   └── MyStudio/
    │       ├── Zones/Zone_Slay_Base.json
    │       └── Zones/_Wilds/Trork_Trouble.json
    ├── QuestGenerators/
    │   └── Zone_Slay.json
    ├── Boards/MyStudio/Daily.json
    └── Bounties/MyStudio/Bounty_Boar_Hunt.json

That zip is the deliverable: author the tree as a folder, zip it with the manifest at the root, and drop it in your mods directory - see Building the zip.

Where a file goes, and what its id is

Folders under the type root are yours to arrange. The engine scans them recursively and, by default, they change nothing about the id - so Zones/Wilds/Trork_Trouble.json and Zones/Ashlands/Trork_Trouble.json are the same id twice, which the loader reports as a collision. A folder whose name starts with _ contributes its name to the id: drop the underscore, lower-case it, join with _.

Quests/MMOSkillTree/Zones/_Wilds/Trork_Trouble.json         ->  wilds_trork_trouble
Quests/MMOSkillTree/Zones/_Wilds/_Act1/Trork_Trouble.json   ->  wilds_act1_trork_trouble
Quests/MMOSkillTree/Zones/Trork_Trouble.json                ->  trork_trouble

The groups

{
  "Name": "Forgot_Something",
  "Text":   { "TitleKey": "quest.forgot_something.title",
              "FlavorKey": "quest.forgot_something.flavor" },
  "Listing":{ "Category": "misc", "SortOrder": 199, "Tags": ["Tutorial", "Repeatable"] },
  "Repeat": { "Cooldown": { "Hours": 1 } },
  "Npc":    { "ViewId": "Mmo_Hub" },
  "Requires": { "Quests": ["getting_started"] },
  "Objectives": {
    "break_block": { "Kind": "BREAK_BLOCK", "Target": "", "Amount": 1,
                     "TextKey": "objective.text.quest.break_any" }
  },
  "Rewards": {
    "Claim": [
      { "Kind": "Item", "Params": { "Item": "Mmo_Menu_Scroll", "Count": "1" } },
      { "Kind": "Item", "Params": { "Item": "Mmo_Quest_Book", "Count": "1" } }
    ]
  },
  "Meta": { "mmoskilltree": { "NpcOnly": true } }
}

Repeat: what brings a quest back around

There is no flag to set. The block's presence says it comes back around, and what is inside says what holds it back. An empty block, "Repeat": {}, is a quest with no clock of its own, governed entirely by whatever offers it - which is exactly what a rotating board contract is.

Every leaf is an INDEPENDENT constraint and they all have to pass, so a daily that may also never be done more than fifty times is both leaves side by side, not a special mode.

Meta.mmoskilltree

The shared schema carries a Meta map from a namespace to whatever that namespace's owner wants to say, and nothing in the engine interprets a block it does not own - so a file authored for two mods still loads with only one of them installed. A key nothing here claims is reported by name at boot and the rest of the block still loads, so a typo costs one knob rather than the whole file.

TextArgs: filling a written line's numbered slots

A whole ladder usually wants ONE written line - "Mine {0} ore" - with each rung supplying its own number, so the line is translated once instead of once per rung.

"Text": {
  "FlavorKey": "achievement.kills_trork.desc",
  "TextArgs": { "Title": [], "Flavor": ["@amount"] }
}

Title fills TitleKey's slots and Flavor fills FlavorKey's, in order. Write @amount and the amount this content asks for is substituted; anything else is used exactly as typed.

Listing.Chains: ladders

A ladder lets a surface draw a whole climb as one entry instead of a row of near-identical ones. A piece of content may be a rung of several ladders at once, each with its own tier; the FIRST membership is the primary one as far as this mod's ladder UI is concerned.

"Listing": { "Chains": [ { "Id": "kills_trork", "Tier": 2 },
                         { "Id": "combat_all",  "Tier": 5 } ] }

Reuse: native Parent inheritance

A file may name another as "Parent": "<id>" and inherit every field it does not mention. This is the engine's own inheritance, not a template DSL: there is no {{param}} substitution and no prune list.

{ "Parent": "Zone_Slay_Base", "Listing": { "SortOrder": 40 } }

• Leaves and groups merge per leaf. A child authoring Listing.SortOrder keeps the parent's Category.
• Objectives merges per step id, so one step can be re-tuned.
• Rewards.Auto, Rewards.Claim, Listing.Tags and Listing.Chains are each ONE leaf. Author one and the inherited list is replaced whole - so a child re-authoring Claim keeps the parent's Auto untouched.
• Meta merges per namespace, and a namespace you author replaces that whole block.

Quest generators: one file, many quests

A Server/ZiggfreedCommon/QuestGenerators/<Name>.json writes a family of quests from one table, and each child it emits is an ordinary quest carrying Parent - so a generated quest behaves exactly like a hand-written one, and any member that later needs to be special can be written out as its own file under the same id.

{
  "Base": "zone_slay_base",
  "IdPattern": "{quest}",
  "ForEach": [ { "Token": "quest", "Values": [
      { "quest": "wilds_trork_trouble", "giver": "Guide_Wilds", "sort": 3,
        "after": "wilds_hearty_meal", "gate_stat": "MMO_TotalLevel", "gate_min": 0,
        "target": "Trork", "amount": 8, "xp1_skill": "SWORDS", "xp1_amount": "800" }
  ] } ],
  "Child": {
    "Text": { "TitleKey": "quest.{quest}.title", "FlavorKey": "quest.{quest}.flavor" },
    "Listing": { "SortOrder": "{sort}" },
    "Npc": { "ViewId": "{giver}" },
    "Requires": { "Quests": ["{after}"],
                  "Factors": [ { "Factor": "hytale:stat", "Param": "{gate_stat}", "Min": "{gate_min}" } ] },
    "Objectives": { "main": { "Target": "{target}", "Amount": "{amount}" } },
    "Rewards": {
      "Claim": [ { "Kind": "Mmo_Xp", "Params": { "Skill": "{xp1_skill}", "Amount": "{xp1_amount}" } } ]
    }
  }
}

• Base is the quest id every child inherits, so the shape lives in one ordinary (usually Abstract) quest file and the table carries only what varies.
• ForEach rows bind tokens; Child is a quest body with {token} placeholders substituted anywhere, key or value. A row value keeps its own TYPE, so write it the way the field it fills wants it (an amount unquoted, a reward parameter quoted).
• IdPattern names each child. Generated ids do NOT take the _-folder prefix - the pattern is the whole id.
• Adding a member is copying a row and writing its two lang lines. Changing a row's quest id starts anyone mid-quest over, for the same reason a rename does.

Switching a shipped quest off

Author its id with "Enabled": false and nothing else, either from a pack or from the owner folder mods/mmoskilltree/quests/ (which always wins). A disabled quest leaves the objective index, NPC quest lists and category listings, while the quest system itself stays on. Progress a player already made stays parked in their data and is never deleted.

// Server/ZiggfreedCommon/Quests/MyStudio/Craft_Starter_Tools.json
{ "Enabled": false }

What the validator reports

/mmoconfig validate chats the aggregate audit, and the same findings are logged at boot.

Every NPC-id finding is a lenient warning, never an error. A character's id can be declared (a placement's identity, an identity overlay) or arrive by convention (any NPC answers to its own role id, lower-cased), and convention ids are not enumerable - so an id the validator cannot find is unverifiable, not wrong. The same leniency applies to factor and reward-kind ids, for the same reason.

Boards and bounties

A board is a posting of rotating contracts. It lives in the shared library, so the board itself and the contracts on it are two asset types under Server/ZiggfreedCommon/.

The board file

{
  "Text": { "TitleKey": "ui.bounty.board.daily", "FlavorKey": "ui.bounty.board.daily.desc" },
  "Order": 0,
  "Rotation": { "Period": "Daily" },
  "Selection": { "Type": "Weighted_Random" },
  "Slots": [
    { "Difficulty": "Training", "Count": 2 },
    { "Difficulty": "Easy" },
    { "Difficulty": "Normal", "Count": 2 },
    { "Difficulty": "Hard", "Optional": true }
  ],
  "Currencies": ["Bounty_Token", "Life_Essence"],
  "Reroll": { "Cost": { "Currencies": { "Bounty_Token": 25 } }, "MaxPerPeriod": 3 },
  "AcceptRequires": {
    "Normal": { "Factors": [ { "Factor": "hytale:stat", "Param": "MMO_CombatLevel", "Min": 25 } ] },
    "Hard":   { "Factors": [ { "Factor": "hytale:stat", "Param": "MMO_CombatLevel", "Min": 60 } ] }
  }
}

The contract file

A contract reuses the quest groups verbatim - Text, Listing, Objectives, Rewards (the same two-bucket group, and a contract's pay normally sits in Claim so it is collected at the board), Requires, Parent, Abstract, Enabled - and adds one group only a contract has:

{
  "Parent": "Bounty_Kill",
  "Text": { "TitleKey": "quest.bounty_boar_hunt.title",
            "FlavorKey": "quest.bounty_boar_hunt.flavor" },
  "Boards": [ { "Board": "Daily", "Difficulty": "Easy", "Weight": 2 } ],
  "Objectives": { "main": { "Target": "Boar", "Amount": 15 } },
  "Rewards": {
    "Claim": [
      { "Kind": "Currency", "Params": { "Currency": "bounty_token", "Amount": 75 } },
      { "Kind": "Mmo_Xp", "Params": { "Skill": "UNARMED", "Amount": 600 } }
    ]
  }
}

Five behaviours are stamped by the type and no file may author them, because each one is a bug that would otherwise be one careless file away:

The payout moment is the one thing the type leaves to the author, through the ordinary Rewards buckets: Claim parks the pay at the board it was taken from - where a contract's pay belongs, since it cannot then be lost to the board turning over - while Auto lands in the field the instant the work is done.

To take a board down without editing anybody's file, use the owner layer mods/ziggfreedcommon/boards.json: { "daily": { "Enabled": false } }. The audit runs from /zigcommerce validate, and /mmobounty validate is the alias over it. For the player-facing side, see Bounty Board.

The older shape (still read)

Everything written before 1.6.0 still loads. Server/MMOSkillTree/Quests/<id>.json, the QuestTemplates extends / params DSL, and a server owner's own mods/mmoskilltree/quests/ files all go through a compat reader that registers them into the same engine. It exists so nothing already shipped breaks, and it will die with the old format: author anything new in the shared shape above.

{
  "Name": "Simple_Kill",
  "Payload": {
    "id": "simple_kill",
    "category": "misc",
    "objectives": [
      { "id": "main", "type": "KILL_ENTITY", "target": "*", "amount": 5, "matchMode": "CONTAINS" }
    ],
    "rewards": [ { "type": "XP", "skill": "SWORDS", "amount": 500 } ]
  }
}

The public packs that ship this content are the MMO Skill Bounty Pack and the MMO Skill Quest Pack; see Add-ons for install links. Quests, boards and contracts all resolve as