How errors behave

The item parser is fail-soft by design: a typo in one field almost never crashes a /reload or takes the rest of your add-on down with it. It logs a WARN, drops just the bad piece, and keeps loading. A few cases are fail-hard — they reject the whole definition — and they’re worth knowing so you don’t ship an item or furniture that silently never appears. This page is the field guide for reading the log and knowing what each fallback means in-game.

Where to look

The item parser logs under the logger name DataDrivenItems, with line prefixes [DataDrivenItems] and [DataDrivenItemParser]. Furniture logs under TiedUpFurniture with the prefix [FurnitureParser]. Grep your latest.log for those and you’ll see exactly what the parser made of your files.

The two outcomes

Every problem the parser hits resolves to one of two things:

Outcome	What it means	Log level
Skip-the-piece (fail-soft)	The offending field/entry is dropped; the rest of the item loads.	WARN
Skip-the-definition (fail-hard)	The whole file is rejected and the item/furniture never registers.	ERROR

Read it as a rule of thumb: WARN = something you wrote was ignored; ERROR = the item didn’t load at all. If an item is missing from the game entirely, search the log for ERROR and that file’s name.

Fail-soft: the tolerances

These all produce a WARN and keep going. ✅ Available

Unknown living-motion → “did you mean…?” suggestion

When a key in animations.living_motions doesn’t resolve to any known motion, the parser doesn’t just drop it — it runs a Levenshtein fuzzy match (tolerance 3 edits) across the vanilla and TiedUp! motion names and suggests the closest one:

[DataDrivenItemParser] Unknown motion 'WAKL' in item mymod:wrist_cuffs, skipping. Did you mean 'WALK'?

The binding for that motion is dropped; every other motion in the block still loads. If your typo is more than 3 edits from any real name, you get the same skipping line with no suggestion — that usually means you invented a motion that doesn’t exist. See the full motion list on Bones & regions and Animations.

Note

Motion names from the first two sources (vanilla EF + TiedUp!) are case-sensitive — WALK, not walk. A datapack motion is referenced as a namespace:id resource location instead. A bare lowercase name like walk won’t match an enum or look like a resource location, so it falls through and is reported as unknown.

Bad ResourceLocation → skipped

Anywhere the parser expects a namespace:path id (slim_model, icon, animations.on_equip / on_unequip, equip_sound / unequip_sound, a living_motions animation, cloth.mesh / cloth.texture), a malformed string is logged and that one field is set to null/skipped:

[DataDrivenItemParser] Malformed ResourceLocation 'mymodfoo' for on_equip in item mymod:wrist_cuffs (expected 'namespace:path'), skipping.

The parser is strict here on purpose: it rejects noNamespace, :path, mod: (empty path) and a bare : rather than letting minecraft: be silently assumed. In-game the item still equips — it just won’t play that sound/animation or won’t show that icon.

Unknown region → skipped individually

Each name in regions / blocked_regions is upper-cased and matched against the 14 BodyRegion values. An unknown one is dropped with a WARN; the others stand:

[DataDrivenItems] In mymod:wrist_cuffs: unknown region 'WRISTS' in 'regions', skipping

…but all-invalid regions IS fail-hard

regions is required and non-empty. If every name in it is unknown (or the array is empty/absent), there’s nothing left and the whole item is skipped (see the fail-hard table). blocked_regions is gentler: empty or all-invalid simply defaults to the occupied regions — blocking is not silently turned off.

Absent animation → vanilla fallback

If an item has no animations block at all, the field is left null and the item keeps the stock vanilla animator behaviour — it equips and renders, it just doesn’t pose or override any motion. This is the normal state for a simple item (the wrist cuffs in Your First Item ship no animation). No log line; absence is not an error.

Likewise, an unresolvable equip_sound/unequip_sound id falls back to the vanilla leather equip sound rather than going silent, and unequip_sound falls back to equip_sound if you only set one. 🖥️ Client / singleplayer only (equip sounds are played locally — see the caveat on Components / packaging).

Empty {} → EMPTY sentinel

The animations block distinguishes absent from present-but-empty:

• No animations key → null → vanilla behaviour (above).
• "animations": {} → an internal EMPTY marker. The item is explicitly “animation-aware with no bindings” rather than “never looked at.”

In practice both render the same; the distinction exists so tooling can tell an intentionally-blank block from a forgotten one. There’s no reason to prefer one over the other for a static item.

Other quietly-dropped fields

You wrote	What happens	Why
Unknown components key	WARN, that component ignored, rest of the item loads	typo’d or non-existent component
Non-object component config (e.g. "lockable": true)	WARN, treated as {} (defaults)	components take an object, not a bare value
movement_modifier without movement_style	WARN, modifier ignored	the modifier only applies when a style is set
Unknown movement_style	WARN, ignored (item still equips)	not one of WADDLE/SHUFFLE/HOP/CRAWL
Legacy animation_bones key	WARN, ignored	dead PlayerAnimator-era key; declare bones per-motion via OVERLAY joints instead
Bad hex in item tint_channels	WARN, that channel skipped, item loads	item tinting is per-channel fail-soft (contrast furniture, below)
living_motions OVERLAY with no joints	WARN, that binding skipped	an overlay with no joints would mask nothing

Joint typos are caught at EQUIP, not at /reload

Bone names inside a living_motions joints array are not validated when the file loads — the parser has no skeleton yet. A misspelled joint is dropped with a WARN the moment the item is equipped, not at /reload. So a clean reload log does not prove your joint names are right: equip the item and watch the log. Joint names are case-sensitive (Hand_R, never hand.R) — see Bones & regions.

Fail-hard: the cases that reject the whole definition

These log an ERROR and return nothing — the item or furniture never registers, so it won’t exist in-game at all. If something is simply missing, this table is where to look.

Items

Trigger	Log (ERROR)
type is missing or not exactly tiedup:bondage_item	Skipping …: invalid or missing type '…'
display_name missing or empty	Skipping …: missing 'display_name'
model missing or empty	Skipping …: missing 'model'
model is not a parseable ResourceLocation	Skipping …: invalid model ResourceLocation '…'
regions missing, empty, or all names invalid	Skipping …: missing or empty 'regions'
The whole JSON file fails to parse (syntax error)	Failed to parse JSON …: <message>

Note

Note the asymmetry on model: a malformed id (model can’t be parsed) is fail-hard and skips the item, but a well-formed id that points at a file that isn’t there is not caught here — the parser only checks the id is valid, not that the GLB exists. A missing GLB surfaces at render time, not at /reload.

Furniture — bad hex color is fail-hard ⚠️ Partial

This is the asymmetry to remember. Where an item tolerates a bad tint_channels hex (skips just that channel), furniture does not — one invalid hex rejects the entire furniture definition:

[FurnitureParser] Skipping mymod:bondage_cross: tint_channels 'frame' has invalid hex color 'red' (expected '#' followed by 6 hex digits)

The furniture validator is strict: a channel value must be a string, # followed by exactly 6 hex digits (#8B4513). No #, the wrong length, or a non-string value, and the whole piece is dropped. Furniture is fail-hard on id, display_name, model (same spirit as items — though furniture has no type discriminator), plus a missing or empty seats array and this hex rule. (Player dye recolouring is separate and not wired — see Furniture.)

A quick triage flow

1. Item not in the game at all? Search the log for ERROR + the file name. It hit a fail-hard case (table above) — most often type, display_name, model, or all-invalid regions.
2. Item exists but a feature is missing (no sound, no pose, missing icon, a region not blocked)? Search for WARN + the item id. A field was dropped fail-soft; fix the line it names.
3. Reload is clean but the pose is wrong on the body? Equip the item and re-check the log — joint names validate at equip, not reload.
4. Unknown-motion WARN with a “did you mean…?” Take the suggestion; it’s a Levenshtein match against the real motion names.
5. A crafting recipe doesn’t load? Pack recipes fail like any vanilla recipe — a recipe whose result.tiedup_item points at an id that doesn’t exist is dropped on load. Check the log for the recipe id, and see Packaging for the recipe format.

Tip

The whole philosophy is: one bad field shouldn’t cost you the item, and one bad item shouldn’t cost you the add-on. Reloads stay robust, the log tells you precisely what was ignored, and only a small, documented set of mistakes is fatal. When in doubt, read the log — it names the file, the field, and usually the fix.