The problem with number-only systems
Numbers are fine for rendering, but bad for memory. Staff documents turn into giant translation tables, old IDs get reused by mistake, and debugging a broken quest reward becomes slower than it should be.
Keep a readable identity layer
Even if the visual model pipeline still points to a number, your server workflow should also keep a string ID such as rp.guard.badge_bronze or quest.chapter3.letter_mayor. That string can live in minecraft:custom_data while the visible art keeps using custom_model_data.
A safe combined pattern
components:{
"minecraft:custom_model_data":2047,
"minecraft:custom_data":{
item_id:"rp.guard.badge_bronze",
issue:"capital_watch"
}
}Why this scales better
- The art team can search readable IDs in docs.
- Quest logic becomes easier to audit.
- Old items are less likely to be confused with test assets.
- Trades and rewards can validate the hidden string, not only the visible model.
Suggested naming strategy
- Use namespaces by system:
rp.,quest.,shop.,faction. - Keep tokens readable and stable.
- Avoid spaces and translated names in the hidden ID.
- Let the visible text be local and pretty, and let the hidden ID stay boring.
Where the number still belongs
The numeric model hook still matters for rendering and pack organization. The trick is not to throw it away, but to stop pretending that one integer should also be your only admin-friendly item identity.
Recommended server workflow
- Assign the art-facing model value.
- Assign the logic-facing string ID.
- Use the string ID in documentation, shops, and validation checks.
- Keep the number mainly as a pack rendering detail.