Content Types & Merging

How merging works

• By id, additive. Each content entry has an id. A pack entry with a new id adds content; an entry whose id already exists overrides it. If two packs define the same id, the last-loaded pack wins.
• The server owner always wins. Content the owner authored locally (their own files under mods/mmoskilltree/ or mods/ziggfreedcommon/) is never overridden or dropped by a pack.
• Defaults < pack < owner. Packs override the plugin's built-in defaults, but not the owner's explicit customizations.

Shared library types merge on their own

Everything under Server/ZiggfreedCommon/ - quests, achievements, categories, milestones, conversations, NPC placements, wallets, storefronts, shelves, offers, boards, contracts, reward kinds, loot tables, feedback moments - is a keyed asset whose store the engine merges natively by id. There is no Control key for any of them and none is needed:

• To add, ship a file with an id nobody else used.
• To override, ship a file with the same id and the body you want.
• To re-tune one leaf, ship a file carrying "Parent": "<id>" and author only what changes.
• To switch one off, author its id with "Enabled": false and nothing else.

That is per file, which is finer-grained than a whole-type switch, and it is why the Control file below covers only the older mod-side types.

Every folder on this page is authored inside your pack directory and shipped as one zip - see Building the zip for the packaging step and the manifest-at-root rule. Every type here also carries a full editor schema, so a pack's files can be authored and validated in the game's own Asset Editor - closed vocabularies as dropdowns, defaults declared - rather than by hand.

Add vs. replace (the Control file)

By default a pack adds to existing content. To make a pack replace the built-in defaults for one of the older mod-side types (a total-conversion mastery pack, say), include a control file at Server/MMOSkillTree/Control/<YourPackName>.json:

{
  "Name": "MyMmoPack",
  "Quests": "replace",
  "XpMaps": "add"
}

replace drops the plugin's default content for that type and uses the pack's instead, but the server owner's own authored content is still kept and still wins. The Name must match your manifest Name.

The file accepts exactly these keys (PascalCase, like all asset JSON keys), and nothing else: Quests, QuestTemplates, Achievements, AchievementTemplates, XpMaps, MobKillXp, ItemRequirements, ActionRequirements, BoostTemplates, CommandRewards, CommandRewardTemplates, UIThemes. The Quests and Achievements keys steer the older compat layer only; shared-schema quests and achievements merge natively as described above.

Abilities, ability improvements, gear-triggered ability grants, custom skills, bonus drops, power-level tuning, world rules and mastery tracks have no Control key either - they merge by id like the shared types.

Feature gating

Quests and achievements can declare a dependency on one or more server features. When any listed feature is disabled, the entry is hidden everywhere - it does not appear in the UI, accrues no progress, and cannot be claimed. Re-enable the feature (config flip + server restart) and the entry returns.

There are three spellings of one gate, and they mean the same thing:

// Shared shape - a flat requirement
{ "Meta": { "mmoskilltree": { "Feature": ["mastery"] } } }

// Shared shape - one arm of an either-or
{ "Requires": { "AnyOf": [
    { "Factors": [ { "Factor": "mmoskilltree:feature", "Param": "mastery", "Min": 1 } ] },
    { "Factors": [ { "Factor": "mmoskilltree:feature", "Param": "taming",  "Min": 1 } ] } ] } }

// The older shape
{ "Name": "mastery_tithe", "Payload": { "id": "mastery_tithe", "requiresFeatures": ["mastery"] } }

• Lenient parse. Either a bare string ("mastery") or an array is accepted.
• AND-combined. When multiple ids are listed, the entry is hidden if any one is off.
• Inherited. A Parent (or an older template) carrying the gate applies it to every child; a child can author its own list, or an empty one to ungate.
• Unknown ids fail closed. An unrecognized feature id hides the entry and logs a one-time Unknown feature id warning at server start.

Shared library types (Server/ZiggfreedCommon/)

One file per entry, no Payload envelope and no Id field: the file is the asset. Folders under a type root are yours to arrange and normally change nothing about the id, so give yourself a namespace folder (Quests/MyStudio/...). Every one of these resolves

MMO content types (Server/MMOSkillTree/)

Files may be nested in subfolders freely. Three shapes are in use.

Structured types

The codec is the schema: PascalCase keys, no Payload wrapper, native Parent reuse.

Per-entry "payload" types

The older mod-side shape: one file per entry, the asset key derived from the filename, and Payload holding the entry as a nested JSON object.

Ability precedence (unique to this type)

Abilities are the one content type with a full three-layer fold, all through the SAME codec:

1. Defaults - the jar-shipped abilities under Server/MMOSkillTree/Abilities/<Skill>/*.json.
2. Pack - a pack file at the same path with a matching id overrides the default entirely, unless it uses Parent to overlay just a few fields.
3. Owner - mods/mmoskilltree/ability-overrides.json folds last, per-leaf (the same overlay semantics as Parent: overriding one field never nulls out the rest).

Per-pack "map" types

One file per pack; Name is your pack name and Payload is the config's natural map.

// Server/MMOSkillTree/XpMaps/MyMmoPack.json
{
  "Name": "MyMmoPack",
  "Payload": { "MINING": { "Ore_Adamantite": 25.0 } }
}

Masteries

A mastery track targets a skill (skill:MINING), an ability (ability:fireball) or every ability (global) and holds a Nodes map of purchasable nodes, each with a Tier, a Cost, and Modifiers. Repeatable Eternal nodes set MaxPurchases: -1 with CostScaling. Full field reference, Parent reuse and generators: Authoring Mastery Tracks; see the player-facing Mastery guide for how this looks in-game.

// Server/MMOSkillTree/Masteries/Mining_Mastery.json
{
  "Target": "skill:MINING",
  "RefundPercent": 50,
  "Requires": {
    "Factors": [ { "Factor": "hytale:stat", "Param": "MMO_Level_MINING", "Min": 5 } ]
  },
  "Nodes": {
    "min_t1": {
      "Tier": 1,
      "Cost": {
        "Currencies": { "mastery_point": 2, "life_essence": 500 },
        "Items": [ { "Item": "Ingredient_Crystal_Blue", "Count": 1 } ]
      },
      "Modifiers": [ { "Shape": "PERCENT", "ParamKey": "lootMultiplier", "Value": 0.03, "TargetSkill": "MINING" } ]
    },
    "min_eternal": {
      "Tier": 9,
      "MaxPurchases": -1,
      "CostScaling": { "Curve": "EXPONENTIAL", "Multiplier": 1.1 },
      "Cost": { "Currencies": { "mastery_point": 1, "life_essence": 200 } },
      "Modifiers": [ { "Shape": "PERCENT", "ParamKey": "lootMultiplier", "Value": 0.005, "TargetSkill": "MINING" } ]
    }
  }
}

Currencies, shops and boards moved

Wallets, storefronts, shelves, offers, boards and contracts are shared library content and live under Server/ZiggfreedCommon/. The six old mod-side stores (Currencies, Shops, ShopPools, ShopEntries, ShopTemplates, BountyBoards) are read at boot only so a pack still shipping them can be named in the log and pointed at the new folder; nothing in them loads. See Authoring Shops & Currencies and Boards and contracts.

Classes (Future)

The Class System is a future, unreleased feature; the schema below documents the planned content shape. The plugin ships no built-in classes, and without a class pack the class system stays dormant. A class definition carries base grants applied while the class is selected, plus an additive Advancements map (ranks, keyed by advancement id) unlocked by meeting requirements. It is a structured type: PascalCase fields, no Payload envelope, and a shared skeleton is an Abstract file named as Parent, the same paradigm as mastery tracks.

ClassGrants (used by base and each advancement):

Exporting your server's content as a pack

/mmopacks --action=export --name=<MyPack> writes your server's custom quests and achievements out as a loadable pack zip under packs/ - a working starting point with valid filenames and shapes already in place. /mmopacks (or /mmopacks --action=list) lists loaded packs and how many entries each contributes per content type. Both arguments bind by name only, never positionally. The exporter writes the shared Server/ZiggfreedCommon/ layout described above, so the result is ready to author further without conversion.