Wiki
Tools
Project
ENRUFRDE
← All articles

select, range_dispatch, or condition?

The hardest part of Minecraft 1.21.4+ item definitions is usually not typing the JSON. It is deciding which branch type actually matches the way the item changes. Once that choice is clean, the file gets smaller and the rest of the team can still read it a week later.

Open item model builderRead the main guide

Think in signals before syntax

Before choosing a branch type, ask a simpler question: does the item always look the same, switch between named states, move through numeric thresholds, or react to a yes-or-no condition? Once the answer is honest, the JSON usually gets much calmer too.
This is why so many new definitions feel heavier than they should. People reach for the most flexible branch first, not the smallest one that actually matches the behavior. Flexibility sounds safe, but it often leaves a larger tree than the item needs.

Quick decision table

Use thisWhen it fits bestTypical example
minecraft:modelThe item has one fixed visual identity.A guild pass, prop book, or single relic icon.
minecraft:selectThe item switches between named states.Sealed, awakened, broken, cursed.
minecraft:range_dispatchA number crosses clear thresholds.Charge stages, durability bands, progress levels.
minecraft:conditionThe result depends on true or false.Selected in hand, using item, damaged, or not.

Three easy wording tests

  • If you describe the change with words like ritual, spent, or active, you probably want select.
  • If you describe the change with numbers like 0-25-50-75, you probably want range_dispatch.
  • If the item is either doing something or not doing it, condition is usually enough.

Examples that clarify the choice fast

1. A relic with story states

If the relic is sealed, glowing, or cracked, those are named states. That is a clean select case.

2. A staff that changes as it charges

If the staff moves through four visual charge bands, this is a range_dispatch problem because the shift happens over thresholds.

3. A map that changes only while selected

If the alternate look appears only when the player is actively holding or using it, a simple condition branch usually keeps the definition smaller and calmer.

Common overengineering mistakes

  • Using select for a single fixed prop because the branch structure feels future-proof.
  • Using range_dispatch when the real change is not numeric but named.
  • Turning a binary state into too many branches and making debugging harder than the item deserves.
  • Forgetting that a good fallback model is part of readability, not just a safety net.

Where the builder helps most

The item model builder is strongest when the decision is almost clear but the wrapper is still annoying. It lets you pick the branch, keep the fallback visible, add cases in a controlled order, and copy the finished JSON into the pack without rebuilding the outer structure from memory.
That makes it especially useful during migrations. You can prototype one definition, see whether the branch really matches the behavior, and only then copy the pattern across a larger item family.

FAQ

Do I always need branching in 1.21.4+?

No. Many items are still just one direct model file. Branches only matter when the appearance really changes.

Can one item use both named states and numeric stages?

Yes, but that is exactly when you should slow down and choose the simplest outer branch first instead of stacking everything into the first draft.

Should I decide the branch before the texture exists?

Usually yes. The visual file can come later, but the logic question of how the item changes is worth answering early.