1.6.0 Migration Converter

Zip up your server's mods/mmoskilltree/ folder (config overrides, quests/, achievements/, retired owner files). You get back a replacement folder shaped for 1.6.0: among the rewrites, an old mastery.json (or classes.json) becomes the schema-v3/v2 per-leaf overlay the server reads now, and world-rules.json gets both of its moves in one pass (the retired flat Match into Where, the flat 1.5.x gameplay knobs into the nested Rules group).

Already started the server on 1.6.0 once? A zip taken after that first boot still works: the .legacy files and timestamped backup/ copies it left behind are recognized and converted the same as their old names would have been. A copy whose content the server already moved for you is named in the report as exactly that, never converted a second time. On a live server, /mmomigrate (new in 1.6.0) reports the same findings for your mods folder and your installed packs, and converts the mods/mmoskilltree/ owner files in place, with automatic backups, via --action=owner --confirm=yes. Content packs are never rewritten in game: converting a pack is what this page is for.

Zip up a pack repo (manifest.json with IncludesAssetPack, its Server/ tree). You get back a pack with a regenerated manifest and 1.6.0-shaped assets. A file that cannot be converted mechanically is reported instead, with the target shape quoted and the original preserved under _unconverted/ - a mastery track or template in the old grammar, for example, is re-authoring work (the structured schema, an Abstract Parent base, a generator file), so the report points at it rather than guessing at it.

Three more repairs land the same way: a shared-store quest or achievement still written in an earlier 1.6.0 preview shape (a positional Criteria list, a flat Rewards list, ClaimRewards, Flow.AutoClaim, a top-level Visibility group) is refreshed in place to the keyed Criteria map and the bucketed Rewards: {Auto, Claim} group; an NPC placement still spelling its gate Requires.Conditions is renamed to Requires.Factors (the old key leaves the gate empty, so the placement stood unconditionally); and a block or item file still authoring the retired Flags.IsUsable leaf is reported, never rewritten - an Update 6 server just ignores the key, so deleting that one line is yours to do.