Where art comes from, what survives
being written down, and what stops a bad mod shipping.

Verified end to end: an asset published to the library appears in the tab's tree by name, and its lineage survives the round trip through JSON — where it came from travels with it rather than being reconstructed. That matters later, when signing asks your mod to account for every asset it ships.

The tab reads the format through the shared reader, not a Vault object. That is not fussiness: the Mod Kit and Vault are separate applications and neither can reference the other's types. What they agree on is a folder and a file layout, which is the loosest coupling that could possibly work — and therefore the most robust.

The destination folder comes from what the asset is — a texture lands under textures/ — so your mod's asset folder stays organised without you filing anything. And because this is a copy rather than a reference, your mod is self-contained from that moment on: it will build, package and sign on a machine that has no Vault library at all.

This is the same lesson as the Definitions workspace's header, arriving through a different control: the tool tells you whether a mod is open, and it will not let you do the damaging version of the mistake. Where the Definitions workspace saves somewhere unhelpful, the Library tab simply refuses — a copy has to have a destination, so there is no "somewhere else" for it to go.

Verified: a library that does not exist yet reads as empty rather than raising. That is a deliberate choice with a reason attached — a tool that reports a normal situation as a failure teaches people to ignore its warnings, and the warnings here are worth reading.

So an empty Library tab means one of two ordinary things: nothing has been published yet, or you have not used Vault on this machine. Neither needs fixing, and neither is the tool malfunctioning.

Godot's maths types store X, Y, Z as fields — the fastest thing they can be, which is what you want in an engine that touches them millions of times a frame. The JSON writer, following the .NET default, serialises properties and ignores fields.

Neither is wrong. Together they mean a struct handed straight to the writer produces a document with nothing of the struct in it, and the writer reports success because nothing failed — it wrote everything it was willing to look at.

This is the merciful version, because once you have opened the file you cannot miss it. A position, a rotation and a scale all written as {} is unmistakable, and it explains the symptom exactly: every prop reads back as the default, which is the origin, and a scale of zero.

Verified in both directions — a raw vector still writes nothing, and through the correct path a scale of 2 does not come back as 0. That second assertion exists because the symptom people actually report is "my props vanished", and a zero scale is what makes a prop invisible rather than merely misplaced.

Unlike a vector, Color exposes a set of derived, read-only properties — an 8-bit red, hue, saturation, value, luminance, and more — and those are properties, so the writer takes them. What it omits is R, G, B and A: the four numbers the colour is actually made of.

★★ The result is the most dangerous shape a bad file can take: a payload full of plausible numbers that cannot restore the value. It does not look empty. It looks like a rich, well-populated colour record. A reader that asks for R finds no such key, falls back to a default, and hands you white.

That asymmetry is why the harness asserts both types separately. A check that only covered vectors would have passed the whole time the colour bug was live.

The importer case is the instructive one, because it passed review. Someone read that code, saw a reader with a sensible fallback, and moved on — the fallback was the thing hiding the fault. A default value is a good idea when the data is genuinely absent and a disguise when it should have been there.

Keep the individual numbers on the saved model, and expose the convenient struct as a computed value the writer is told to ignore. The file then contains real components, and the struct is reassembled on the way out — so code keeps working with vectors and colours while the document stores what it can actually restore.

Verified through that path: a vector round-trips, a colour round-trips with its alpha, real components and real channels appear in the file, and a colour written in the web notation still reads. The importer's reader recovers the colour it was given.

The muzzle rule is a ratio, not a distance, which is what lets one number cover a pistol and a rifle. It is a least-squares fit through the six weapons the game ships, and what it says is worth knowing on its own: the game spawns the shot roughly 22–23% beyond the barrel tip, scaled to the gun — not at the tip, and not at a fixed clearance.

The grip anchor is the opposite kind of number: absolute, not a fraction. The four long guns sit between 0.2706 and 0.2790 — an 8 mm spread across weapons that differ by 565 mm in length — while as a percentage of length those same six span 16.8% to 52%. There is no invariant in the percentage at all. What is anchored is anatomical: how far the weapon extends behind the hand. The 10 mm tolerance is simply that 8 mm spread with a little room.

That inversion is the whole design. If you count assets, a weapon whose mesh is missing or unresolvable simply is not in the list, and a hole in your coverage reads as a clean pass. If you count definitions, that weapon is a failure, because a definition that cannot reach its mesh is exactly the thing you needed to hear about.

The gate also reports the other direction: meshes no definition references. Those are not coverage, they are dead weight — files your mod ships and never uses. Reporting both numbers means neither can be mistaken for the other.

Those six are not there to be tested — they are known good by definition, being the things the convention was measured from. They are there so that if the gate ever starts failing them, you know the instrument has drifted rather than your mod being wrong.

Look at the spread: the shotgun sits 1.73% off and still passes, the PDW is within a tenth of a percent. That range is exactly why the band is ±2.5% and not ±0.5%. ★ The tolerance is derived from the ground truth's own scatter, not picked — a tighter band would reject one of the game's own weapons, which is a category error in a gate whose entire job is "conforms to how the game does it". The side-by-side shotgun is the only one outside 1%; drop it and the constant tightens to 1.224 with all five inside 0.5%.

This is the two ladders meeting. The definitions tutorial showed the exporter reporting that it had substituted a placeholder mesh; here is the gate refusing to let that ship. One tells you, the other stops you, and the mod in question is a test fixture that was never meant to pass.

Note also what the denominator line reveals for free: two weapons resolving to one distinct mesh. In a real mod that is a red flag on its own — not an error, but almost certainly not what you intended.

It says nothing about balance — and as the definitions ladder established, a ranged weapon's damage is not on the weapon anyway. It says nothing about how the mesh looks, whether the silhouette reads at game distance, or whether the thing is fun. And it cannot confirm the game loads your mod; that needs the game.

What it does is remove one entire class of defect from the list of things that might be wrong, which is exactly what a gate is for. Run it before you ship, and the forty-gun morning cannot happen to you.