Sharing Craft

A KSP craft file is a list of part names and their arrangement. That is almost enough. What it does not say is which mod each part came from, which flag image the player imported, which recolour pack painted it, what its tanks were configured as, or what any of it was scaled to.

Handed to somebody with a different install, a craft with those gaps fails in ways that are hard to diagnose: parts silently missing, a flag that errors mid-load, an engine that is the wrong size, a tank full of a propellant that does not exist here.

So a craft leaving your save is packed with everything the file cannot express, and a craft arriving is reconciled against the local install before KSP ever sees it. Every export path in the add-on runs the same chain, and the install path unpacks it in exactly the reverse order.

rescale bake  ->  flags  ->  scale version  ->  paint  ->  fuel configs  ->  mod list  ->  thumbnail

TweakScale stores a scale factor and lets exponents derive everything else at load time. Those exponents differ between TweakScale versions and forks, so the same file rebuilds differently on two machines.

Instead of carrying the factor, the sender copies the values already computed on the live part: the model scale, the dry mass, the module stats. A craft that leaves this way needs no TweakScale at all on arrival, which is why TweakScale is deliberately left out of the dependency list a submission reports.

Baking fixes three things, not one, which is why skipping it broke craft even for people who did have TweakScale:

• The scale itself.
• The position of surface-attached parts on a scaled parent, which KSP serialises in an encoding that only reads correctly if the recipient has KSP-Recall.
• A layout pin re-asserted at runtime, because KSP re-seats surface-attached parts a few frames after load and on every undo.

Custom flags travel with the craft as embedded images, written into the add-on’s flag folder on arrival and injected into the game’s database so they render without a restart.

They are named by a hash of the image rather than by the name KSP gave them, because KSP names player-imported flags with short random ids and two people’s identically named flags are different pictures. That hash can only be computed from the bytes, so a flag reference of that shape in a craft is proof the sender actually held the image.

A reference that does not resolve is reset to the default flag at both ends. Left alone it is self-perpetuating rather than cosmetic: re-exporting finds no file, embeds nothing, and ships the same dead reference onward, while every module trying to resolve it throws. A broken mission flag in particular surfaces as a ConformalDecals exception partway through loading, which names neither the flag nor the craft.

Textures Unlimited adds zero parts, so every part-based mod detection path is blind to it. The recolour data itself already rides in the craft file, but which pack defines the texture set does not, and that is only knowable on the sender’s machine.

So each referenced texture set is resolved back to the folder of the config that defines it, and that manifest travels with the craft. It is what makes a painted craft tag correctly on the marketplace, and what turns a missing recolour pack into an installable CKAN modpack.

On arrival, every recolour module the local prefab accepts is kept and the ones it cannot are dropped, so the craft arrives either fully painted or in stock colours, never with orphaned modules. The texture files themselves are never embedded: they are the pack author’s art, far too large for a craft transfer, and not ours to redistribute.

Reforged Materials Redux (the in-editor painter built on top of Textures Unlimited) is carried the same way, with one difference that matters. It keeps its paint in its own part module and needs no manifest at all, because it is a single mod in a single folder. But it patches that module onto every part in the game, painted or not, so a craft only counts as painted when a setting is actually off its default. That is the test behind the marketplace tag, and it is why an unpainted craft built on a Reforged install still lists as stock.

RealFuels also adds zero parts, configuring existing ones instead. Two RSS-RO players already exchange working craft with no help at all. What the manifest adds is the part a file cannot express: the sender’s RealFuels version, whether their install runs Realism Overhaul, each tank type resolved to the folder that declares it, and the selected engine config names.

Where a part is genuinely the same object under two names, it is swapped. The motivating case is Making History’s inflatable airlock against ReStock+’s stand-in for it: the same object, because ReStock retextures the DLC part using the very asset ReStock+ builds its DLC-free version from.

That is also how the substitution table was built, mechanically rather than by eye. Two parts are listed as the same thing only where ReStock’s DLC patch and the ReStock+ stand-in resolve to the same model asset, which proves identical geometry and attach points.

Substitution runs in both directions, because ReStock+ hides its stand-ins when the DLC is present and a career save treats a hidden part as unpurchased and refuses to launch. Switching substitution off in settings still scans and reports; it just offers the advice instead of acting on it.

A missing part cannot be traced back to a mod on the recipient’s machine, because the part is exactly what is absent. So the answer is worked out on the sender’s side and carried with the transfer, then turned into a CKAN modpack file the recipient can open.

A GameData folder is not a mod, and the whole thing is built around not confusing the two. Some mods install a parts folder next to a plugin-only companion, and several ship a core split where a parts mod and a library live under one name. So parts are resolved through install paths rather than folder names, and a path two mods share is left out rather than guessed at.

The stock expansions are treated as dependencies rather than as stock, keyed separately from each other, because they are bought separately and owning one says nothing about the other. A missing expansion is reported but never written into the modpack, since CKAN can detect a DLC and can never install one.

Kerbals transferred into someone else’s save are tagged with the owner’s name while they are there. The tag is reversible and is stripped when they go home, which makes an untagged roster name the test for whether a kerbal is yours.

A modded profession that this install cannot define is not invented. The kerbal is given a valid local profession instead, the swap is reported once, and the original profession is kept twice over: in the craft’s own crew data so a re-import elsewhere resolves it, and in a local repair record so installing the mod later hands those roster entries their job back.

Part substitution, texture transfer and fuel config transfer each have their own setting, all on by default. Switched off, each one still scans and reports; it simply stops changing anything. See Mod Settings File.