Why this becomes necessary earlier than expected
Most servers do not start with a formal registry. They start with a few prop items, one or two currencies, a quest pass, and a shared belief that everybody will remember which hidden ID belongs to which story object. That belief usually breaks long before the content feels large.
The catalog is not there to look administrative. It exists because memory is the first thing that scales badly. Once multiple builders, writers, or pack editors touch the same library, you need one stable row per item instead of one more conversation thread.
The minimum row every item should have
| Field | Question it answers | Why the team cares |
|---|---|---|
| Internal ID | What logic name this item lives under. | Prevents two objects from quietly sharing one identity. |
| Display name | What players actually read. | Keeps immersive naming separate from technical naming. |
| Base item | Which vanilla item still exists underneath. | Useful for pack checks and quick sanity checks. |
| Visual hook | Which item_model or CMD branch is attached. | Stops the art side from drifting away from the logic side. |
| Status or owner | Who is touching the item now. | Reduces accidental overlap when content is being revised. |
| Notes | What makes this item special. | Keeps one-off exceptions out of disappearing chat history. |
A team workflow that stays readable
- Sketch the item in the custom item builder or in design notes.
- Create a catalog row before the item spreads into commands, art, and scripting.
- Use tags and notes to record whether the item is currency, prop, quest logic, reward, or testing debris.
- Export JSON, CSV, or Markdown whenever the item set needs to leave one browser and become team-visible.
That order matters. The catalog is most useful when it captures decisions early, not when it tries to reconstruct them after the release week has already become messy.
What the duplicate warnings are really telling you
A duplicate hidden ID warning means two entries are trying to represent the same logical object slot. That is dangerous because commands, scripts, or rewards may stop pointing where you think they point.
A duplicate visual hook warning is softer, but still important. It often means two entries are sharing one look on purpose — or by accident. Both cases deserve a note so the next person does not “fix” a choice that was intentional.
Local browser drafts can still fit a team process
Browser-local storage is not the enemy here. It is a drafting space. The important thing is to treat export as the moment a private draft becomes team infrastructure. A calm workflow can absolutely start locally and then move into planning channels, docs, or external review once the row is stable.
That is why import and export matter so much in this tool. The catalog is allowed to begin as a solo scratchpad, but it should not stay trapped there once the item becomes real.
Common mistakes
- Only recording the display name and assuming the technical side will be obvious later.
- Letting multiple temporary prototypes keep the same hidden ID because “we will clean it up later.”
- Forgetting to note whether a shared visual hook is intentional or accidental.
- Treating the catalog like a museum after release instead of a living working document.
- Exporting too late, after the item logic has already forked across several teammates.
FAQ
Is a catalog only worth it for large servers?
No. It becomes useful surprisingly early, usually the moment custom items stop fitting in one person’s memory.
Should the display name and internal ID match exactly?
Not necessarily. The display name can stay dramatic or lore-heavy. The internal ID should stay stable and readable for the team.
Why not just keep everything in a spreadsheet forever?
You can, but a purpose-built catalog surfaces duplicates faster and stays closer to the rest of the item workflow on the site.
Does the catalog replace the custom item builder?
No. The catalog organizes the library. The builder still handles command generation.
Can this help during pack migrations too?
Yes. Once each item records its base item and visual hook, pack-side migrations become much less chaotic.