Sixteen categories, one form,
and four that go nowhere.

Verified: sixteen categories, sixteen distinct files, no two sharing one. That matters more than it sounds, because each category is described by a small record — its file, how to count its entries, how to name one, how to create, duplicate, delete and load — and the list, selection and auto-save machinery around that record is shared.

So the workspace is not sixteen editors that happen to look alike. It is one editor being handed sixteen descriptions. Learn the interaction once and the only thing that changes between factions and biomes is which fields are on the form.

Mod is a singleton: your mod has exactly one identity, so the category shows a form with no entry list beside it. There is nothing to create, duplicate or delete, and the workspace's whole left-hand column simply does not apply to it.

It is also the one category the workspace marks not editable here. Your mod's name, id and version are set where the mod is created rather than typed into this form — the workspace shows them so you can confirm which mod you are editing, not so you can rename it mid-session.

Verified against the running workspace: a freshly opened Definitions workspace has no active mod and reports exactly that string. Nothing is lost — the JSON is written and it is still there next time — but it is not in your mod, so it will not be exported, packaged or seen by any other tool in the suite.

This is the same shape of problem the other tools have with user:// destinations, and it has the same one-line fix: open the mod before you author anything. The header at the top of the workspace tells you which case you are in, always, in plain words.

The debounce is the right design — without it, typing a description would rewrite the file on every character — but be clear about what it means: the form is not the file until the timer fires. If the application dies inside that 0.6-second window, the last edit was never written.

The workspace protects you at the obvious seams: switching category flushes anything pending first, so moving from Weapons to Items does not strand a half-second of typing. What it cannot protect you from is closing the lid mid-sentence.

The adapter states the consequence plainly in its own report: an unresolved name fails the whole dec. Not the field — the definition. A biome whose animal list contains one typo does not load with three of its four animals; it does not load.

This is why the adapter would rather remap or drop a reference it cannot vouch for, and write down that it did, than pass your text through and let the game reject the result. Every line in UNMAPPED.txt is a place it made that choice for you.

The field defaults to "Crafting", which reads like exactly the right answer and is the one word the game does not use. Its twelve skills include Mechanics, Cooking, Tailoring, Melee and Research — but nothing named Crafting.

So a recipe you created and never thought about carries a dangling reference from birth. The adapter does not ship it: it remaps to Mechanics so a colonist will actually pick up the bill, and records the substitution. But it is worth knowing that the untouched default is the broken case, which is the opposite of the usual arrangement.

This is the nastiest failure on the page because it is not an error anywhere. The dec loads. The recipe appears. The workbench shows the bill. Nobody ever works it, because the three task workers each dispatch on one exact skill and no other — so a recipe attached to Construction or Medicine is a permanently pending job.

The adapter's remap exists precisely to stop this reaching a player, and it says so in the report: mapped to Mechanics so a colonist will actually work the bill.

And one behaviour that is not a reference at all but catches people the same way: IsBuildable is derived from the build costs alone. Terrain with build settings but no costs is treated as natural ground that nobody can build — so the category, work and icon you filled in are left out rather than emitted as a build that could never start.

Two more things the adapter will substitute silently unless you look: a terrain with no texture of its own draws with the base game's soil, and one with no edge mask meets the world on borrowed edges. Both load and render perfectly. Both look like ordinary dirt.

An item called Hammer and a weapon called Hammer are two obviously different things to you, and the bundle is right not to complain — it only refuses duplicates inside one category. But a weapon definition is a kind of item definition to the game, both reduce to the dec name Hammer, and the game ends up with two definitions answering to one name.

★ The other half of this is slugging. Names become dec names by being reduced to a safe form, so "Iron Bar" and "Iron-Bar" are two entries you can happily create in two rows of the same list — and one dec. The collision is created by the conversion, which is why the adapter checks for it by reading back what it wrote rather than by inspecting what you authored.

The probe biome exported for this page names three terrain, three plant, two rock and two animal definitions. Every one must already exist — in the game, or in your mod — and a single unresolved key fails the entire BiomeDec at load. A biome is therefore the category where a typo costs the most, because it is the category with the most names in it.

⚠ And one hard limit worth knowing before you plan around it: a mod cannot practically ship its own animal. A concrete agent needs a rigged model, a named animation tree and a per-bone collider skeleton — so the animals in your biome should be base-game names. The plants, rocks and terrain are yours to make; the wildlife is borrowed.

⚠ The export does not land in your mod. It is written under the application's own user data, at export/aoa/<ModId>/ — on the machine this page was written on that resolved to ~/.local/share/godot/app_userdata/AshForge/export/aoa/ExportProbe. That is where UNMAPPED.txt is too, so "read the report after every export" means going there and not into your mod folder.

The probe export written for this page produced eleven XML files — the ten categories above plus a Tags.xml the adapter derives rather than takes from you — alongside mod.json, an Assets/ folder and UNMAPPED.txt.

The Mod category is the sixteenth and does not appear in that table because it is not content: it becomes mod.json, the identity block the loader reads.

This is not an oversight in the adapter so much as a fact about the game: there is no counterpart among its definition types for a quest, a status effect or a scripted event. Those are behaviour, and behaviour arrives in a mod as compiled code, not as data. The suite reached the same conclusion independently when it triaged which tools could reach the game at all.

Vehicles sit slightly differently — there is nothing conceptually impossible about them — but the adapter has no mapping today, and a category with no mapping and no warning is indistinguishable from one that will never work. Treat all four the same way until told otherwise.

Both are correct modelling rather than compromise. A recipe in this game is not a free-standing object — it is a property of the thing produced — so emitting a separate recipe definition would be inventing a concept the game does not have.

The practical consequence is small but real: time spent writing recipe descriptions is time wasted, and equipment that exists only in your head rather than in your Items list cannot be handed to a character.

★★ A ranged weapon's damage lives in its ammunition's projectile, not on the weapon. The probe sidearm is chambered for the base game's handgun ammunition, and that is where its damage comes from — so the bundle's damage of 12 has, in the adapter's own words, nowhere to go.

Firing rate is the same story told differently: the game models a burst count and a cycle time, not a rate, so a single rate number cannot be translated into it without inventing one of the two.

This is worth internalising because the form does not hint at it. You can tune a ranged weapon's damage all afternoon in the Mod Kit and change nothing in the game. What you can change is which ammunition it is chambered for.

That last row is the one to plan around. Your raiders exist, they are correctly equipped, they belong to a faction — and no code path brings them into a game. The game ships one event to copy, which is an assembly, not a definition. So a character in the Mod Kit is content waiting for behaviour, exactly like the four categories in lesson 02.

The probe export ends with a line that is not a warning but a refusal: one shipped asset had no origin record and cannot be cleared for release. Signing will not accept a mod it cannot account for, so every asset needs a small origin file in the folder it was downloaded into. An export with unaccounted assets is a mod that will package and never sign.

Alongside that sit the placeholders — substitutions made so your definitions load and render at all. Items and buildings with no model of their own get the base game's wood mesh; research nodes and items with no icon get a stock one, and an item with no icon loads but never draws. ⚠ And one that is a limitation rather than a placeholder: a modded mesh cannot be textured yet, because the material is applied as an override and the loader answers a mod-owned material with a flat colour.