PalSchema authoring turns supported Palworld data and Blueprint-property edits into small JSON or JSONC documents backed by generated schemas. The schema is the contract between your editor and the current game data: it provides discoverable keys, types, enums, and validation before the runtime ever sees the mod.
The productive loop is generate for the current Palworld revision, choose one supported category, copy only the row or property you intend to change, validate in the editor, then watch PalSchema apply it in a disposable session. Do not start by copying an entire table; the smallest patch is easier to merge, review, and update.
Build the authoring environment
- 01
Install the documented development stack
Use the PalSchema development release, the exact experimental Palworld UE4SS build it names, and any generated schema prerequisites from the maintainer instructions.
- 02
Launch once and inspect logs
Prove UE4SS and PalSchema initialize before adding your package. Resolve signature, generation, and path errors at the framework layer first.
- 03
Generate schemas for this game revision
Run the maintainer’s generation workflow after Palworld changes. Store the generated version/revision with your development notes, but do not assume old output describes new game data.
- 04
Connect your editor
Open the mod workspace in an editor with JSON Schema support so autocomplete, required fields, property types, and validation appear while you write.
- 05
Create a uniquely named mod folder
Keep the supported category directories under one stable package identity. Avoid generic names that will collide with another author’s folder or official PackageName.
Choose the narrowest supported category
| Category family | Use it for | Review focus |
|---|---|---|
| pals / items | Targeted Pal or item parameters and related data | Row identity, type, persistent effects, overlapping properties |
| buildings / spawns | Construction definitions and world distribution data | World-state migration, multiplayer authority, removal |
| blueprints | Supported structured Blueprint defaults/properties | Object path, property type, runtime vs default behavior |
| translations | Language strings and additions | Stable keys, locale coverage, encoding |
| appearance / skins | Supported presentation or skin data | Asset availability and client requirements |
| raw / enums | Advanced schema-exposed structures | Current generated shape and semantic validity |
A targeted data-table edit
This illustrates the maintainer’s “table, row, changed property” shape. Use autocomplete from your generated schema for the exact current key and type; do not copy values blindly.
{
// Target only the row and property your mod owns.
"Kitsunebi": {
"WorkSpeed": 120
}
}Iterate without losing the signal
- 01
Start with one property
Choose a change with an obvious result and a reversible test. Keep the baseline value in notes so you can prove the patch, not merely notice variation.
- 02
Validate before launch
Resolve editor schema errors, malformed JSONC, invalid enums, and unknown properties. A warning ignored in source becomes a harder runtime diagnosis.
- 03
Watch a fresh PalSchema log
Confirm the mod folder, category file, target row/object, and application result appear without parse or schema errors.
- 04
Use auto-reload deliberately
PalSchema can accelerate supported edits during development. Change one value, wait for the documented reload, and verify it; restart when testing initialization or persistent behavior.
- 05
Test interaction and persistence
Run on a new world, a copied existing world, multiplayer sides where relevant, and after save–exit–reload. Then test the package with common overlapping mods.
Design for coexistence
Patch only owned properties
Do not restate unchanged rows or objects; every extra field becomes another possible conflict.
Publish a touched-data manifest
List category, table/object, row, and property so users and patch authors can identify overlap.
Avoid relying on application order
When two semantic changes conflict, provide a deliberate compatibility package instead of promising a filename trick.
Separate optional features
Independent modules let users avoid conflicts and help you identify which edit a game update invalidated.
Explain save effects
State which values are runtime-only and which may be serialized or leave world content behind.
Retest generated schemas after updates
Diff relevant shapes and enums, then test on the new revision before changing the supported-version claim.
Package a maintainable release
Keep only runtime mod content in the release—no generated dump corpus, editor cache, personal paths, backups, or unrelated experiments. For the official loader, add a root Info.json with a stable alphanumeric PackageName, incremented Version, PalSchema InstallRule, MinRevision, and explicit Dependencies for the PalSchema package it requires.
Install the final package through the same path users will use, then retest. A correct source folder can be turned into a broken release by one extra nesting level or a missing category directory. Include a concise change list, touched-data manifest, dependency versions, removal notes, and a known-conflicts section.
Validate and release
Research sources
The claims in this guide were checked against these current references. Primary sources are marked first.