How your own art gets in,
and why it does not ship as a PNG.

Both are set from the Definitions workspace, in the same forms you already know — the art fields were always there, holding these icon: and model: values. For a long time nothing read them and every exported reference was a base-game constant; the asset lane is what connects the two ends.

Note the extensions here: you name a real file, with its extension, because you are pointing at something on your disk. What comes out the other end does not have one, which is the next lesson and the single most common source of confusion.

When the game wants a texture it appends .png; when it wants a mesh it appends .glb. So what goes into the definition is <modid>/<path> with nothing on the end, and the same reference serves an icon and a mesh in different fields without ambiguity — because the field decides the extension, not the value.

Here is a real exported item, produced for this page. One reference, used three times:

icons/ui/crate.png becomes Assets/ui/crate.ashtex and is referenced as <modid>/ui/crate. The lane could have flattened everything into one directory and it deliberately does not, for two reasons worth knowing.

First, flattening renames an author's files behind their back, and a pipeline that quietly changes your names is one you cannot reason about. Second, and more seriously, two icons called crate.png in two different folders would collide silently — one would overwrite the other and the mod would ship with the wrong art and no error. Keeping the structure makes that collision impossible rather than merely unlikely.

The export reported it plainly: ships 1 icon, 1 mesh, 1 material of its own, and closed with an audit line — 3 references into this mod's own namespace, all of them served. That last number is the one to read: it counts references that point at your mod and confirms each one found a file.

Notice what the mesh did not do: beacon.glb is copied unchanged. Meshes ship as they are. Textures do not, and that is the whole of the next tutorial.

When a texture is uploaded to the GPU it has to be in a format the GPU can sample directly. Most engines will compress one for you on the way in. This game cannot — the capability is checked every launch and is unavailable — so a PNG lands as raw pixels, four bytes each.

The arithmetic for a single 256×256 icon:

That is one icon. A mod with fifty of them is paying for two hundred that it does not have. And the cost is invisible from inside the game: the art looks right, nothing errors, and the only symptom is a memory budget that ran out sooner than anyone expected.

This is why the two facts that look contradictory are both true. Your definition holds <modid>/beacon, the game turns that into a request for beacon.png, and the loader — which sits between the game and your mod's files — hands back beacon.ashtex. The game never learns the difference.

It also means you cannot get compressed textures into this game any other way. There is no setting, no import flag and no alternative path: the substitution is the mechanism.

So the format does two jobs at once. It stores the texture already in the form the GPU wants, which is the part that saves the memory, and it then deflates that for storage, which is why the file on disk is smaller than the memory it will occupy. Your download gets smaller and your video memory gets smaller, from one conversion.

★ A small confirmation worth mentioning, because it is the kind of thing that catches a bad pipeline: the size the file claims it will occupy — 87,408 bytes — matches an independent calculation of what a 256×256 compressed texture with a full mipmap chain should be, exactly, to the byte. The file is not merely well-formed; it is arithmetically consistent with what it says it is.

The demo mod's material is 148 bytes and holds four things: a base colour, a roughness, a metallic value, and the path to its albedo texture — which is a separate file, converted the same way as any icon.

That is why an item that ships one mesh can end up with two texture files in Assets/: the icon you see in a list, and the albedo wrapped around the model in the world. They are unrelated images doing unrelated jobs, and forgetting the second is why a model can appear correctly shaped and completely untextured.

The material is read out of your .glb automatically. ⚠ If the mesh cannot be read, no material is produced and the definition keeps its base-game one — which loads and renders, so the failure looks like "my model has the wrong texture" rather than like an error.

A storage building shows how full it is by swapping mesh; a plant shows its growth stage the same way. One field in your definition therefore stands for four files or three, named by convention, and the game dereferences them without checking they exist. A missing one is not an error — it is a bright magenta placeholder in the world.

The signing gate refuses a mod in this state, which is the right place to catch it but a late one. If you are modelling a stockpile or a crop, plan for the whole set from the start, because discovering it at signing means going back to your modelling tool.

So "placeholder" in the report is a statement of fact, not an accusation. The question it asks you is simply: did you mean this one? Nothing else in the pipeline can answer that, which is why the report lists them for a person to read rather than failing the export.

The potato is doing more work than it looks. An item with no icon at all does not fall back to a blank square — it fails to draw, so the item exists, can be picked up and crafted, and is invisible in every list. Substituting something absurd and visible is far better than that, and it is why these constants exist rather than being left empty.

⚠ If you see wood and potatoes in game, the export told you. It is in the report every time, and it is the most common reason a first mod looks nothing like the author expected.

It would be easy to substitute a generic grey surface and carry on. The lane refuses, and its reasoning is worth quoting because it applies to far more than materials: substituting is for a preview; shipping needs the truth.

So a mesh that fails to load leaves the definition on its base-game material, which loads and renders. The consequence is that the symptom you see is "my model has the wrong texture" rather than an error — but the alternative is worse: a grey material that looks deliberate would have hidden the fact that your mesh never loaded at all.

The export writes .ashforge-provenance.json beside your assets, listing each file and where it came from. It fills in the local path automatically; what it cannot know are the fields that actually matter for release:

You supply these by putting a .ashforge-origin.json in the folder each asset was downloaded into — once per folder, not once per file — and the export carries it through. Art you made yourself still needs one; "I drew it" is a perfectly good origin, and the gate only checks that an answer exists.

★ Note what this is and is not. It cannot tell whether you had the right to ship something. It checks that every file is accounted for, which makes an unlicensed asset a deliberate act rather than an oversight. That is the honest limit of what a tool can do here, and doing it well is worth more than pretending to do more.

That is the habit this whole ladder comes down to: the report is generated, so read it, and the dec is the truth, so check it. Between those two files there is nothing about your art you cannot find out before a player does.