World Customisation

The entity types you work with come from two places:

• System types are built into MythTapestry. Character, Location, Event, and the genre-specific ones the onboarding wizard switched on are all system types.
• World types are types you make yourself in Management → Entity Types.

Most of the time the distinction doesn’t matter — both kinds work the same way for users creating entities. But if you want to modify a type, the rules differ depending on whether it’s a system or a world type.

What you can change on a system type

System types come with a default set of fields, layouts, and behaviours that work well for most worlds. You can customise them for your world without forking the whole type:

• Add fields — your additions live on top of the system fields. Other worlds aren’t affected.
• Hide fields — mark a system field as hidden in your world. The field still exists; it just doesn’t appear on forms.
• Change layout — rearrange fields, add tabs, group differently.
• Add subtypes — your world-specific subtypes live alongside the system ones.
• Add behaviours — visibility rules, auto-calculations, feature requirements.

The system type’s defaults are the starting point; your additions are an overlay. If MythTapestry updates the system type later (adds a new field, fixes a default value), your overlay merges with the new defaults — your customisations stay, the new defaults flow in.

What you can’t change on a system type

A handful of things are baked into a system type:

• The internal ID of system fields. (You can rename their display labels, but the system field IDs stay the same.)
• The field type of system fields. A system “name” field is text in every world.
• The type’s identity — Character is always Character; you can’t rename a system type to “Person”.

If a system type is far enough from what you want that these limits chafe, the answer is usually a custom type alongside it. Make a “Persona” type with the structure you want, and use that going forward.

What you can change on a world type

Everything. World types are yours. Add, rename, delete, restructure — you own them.

The one rule: changes to a type apply to every existing entity of that type. Adding a field is safe (existing entities just have an empty value). Removing a field is destructive — every entity loses that data. The editor warns you before destructive changes.

Change	Effect on existing entities
Add a field	Existing entities show the field empty.
Rename a field’s display label	No effect on data; just the label changes.
Rename a field’s identifier	The data moves with the rename. Behaviours and templates referencing the old ID need to be updated.
Remove a field	The data is permanently deleted. Confirm dialog.
Change a field’s type	Risky. Sometimes works (text → rich text), sometimes doesn’t (text → number). Confirm dialog.
Add a subtype	Available immediately for new and existing entities.
Remove a subtype	Entities using it lose their subtype assignment but keep their other data.
Add a behaviour	Affects how the form looks immediately.
Remove a behaviour	The constraint goes away; previously-hidden fields reappear.

Hiding a field instead of removing it

If you’re tempted to remove a field but worried about losing data, hide it instead. Set the field as hidden in the layout or add a visibility rule that always evaluates false. The data stays in the database; users just don’t see the field. You can un-hide it later.

This is the safer move for fields that might be useful later, or that you’ve half-decided you don’t want.

Deprecating a type

When a custom type isn’t useful anymore, you have two options:

• Delete it — gone permanently. Entities of this type are removed; there’s no in-flow migration option.
• Deprecate it — kept but locked. Existing entities stay, but no new ones can be created.

Deprecation is almost always the safer option. It preserves history and any links from content or other entities; deletion can leave dangling references.

When to deprecate

• A type you’ve replaced with a better one. (Old “Town” type replaced by a more general “Settlement” type.)
• A type that turned out to be too narrow. (Used “Wand” type a few times early on, but Items cover the same ground.)
• A type from an experimental phase you don’t want to lose data from but don’t want to keep building on.

What deprecation does

• The type disappears from the Create Entity dropdown.
• Existing entities of this type stay in the database and remain visible.
• Existing entities can no longer be edited — they become read-only with a banner explaining why.
• A “Deprecated” badge appears on entities of this type in lists.

Migrating entities to a different type

If you’re deprecating a type because you’ve replaced it, you may want to migrate the existing entities to the new type rather than leaving them locked. The migration UI is on the roadmap but not yet shipped — for now, the workflow is:

1. Create entities of the new type, copying the data manually.
2. Update content links to point to the new entities.
3. Delete (or leave deprecated) the old entities.

If you find yourself needing this often, let us know — it’s a feature we’re tracking.

Un-deprecating

You can flip the deprecated flag off any time. The type returns to the Create dropdown and existing entities become editable again. Nothing is lost.

Deleting a type with active entities

If you delete a type that has entities, you’ll be asked how to handle them:

Strategy	Effect
Delete all entities	Every entity of this type is removed permanently along with the type. Use only if the entities themselves are no longer wanted.
Keep but lock	Same effect as deprecation — entities stay but become read-only.
Cancel	Don’t delete after all.

There’s no undo on the destructive path; back up first if you have data you might want later.

Where to go next

Common Pitfalls The customisation mistakes most users hit at least once.

Entity Types overview Step back and rethink whether a custom type is what you need.