# Persistence and generated part data

This page documents how V-SwiFT stores variant-driven override data and replays it into generated part definitions.

## What gets stored

`Data_PartSwitch.GetStoredVariantInformation()` walks the currently active variants and collects only transformers where `SavesInformation = true`.

The stored structure is keyed by variant-set index and transformer index, and each entry records:

* the loader type as an assembly-qualified name
* the saved JSON payload

## Write path

`StoreVariantPartData` pulls that data from either:

* a live `Module_PartSwitch` in OAB, or
* a `PartComponentModule_PartSwitch` / `Data_PartSwitch` pair

It then writes the result into `SerializedPart.PartSwitchOverrides` through the V-SwiFT serialized-part extensions.

## Read path

`LoadVariantPartData.GetVariantPartData(...)`:

* reads the stored overrides from the serialized part
* clones the original `PartCore`
* sorts the saved set and transformer keys numerically when possible
* recreates the corresponding `IInformationLoader` instances from the saved type names
* applies those loaders into the cloned `PartCore.data`

## Variant-name caching

V-SwiFT also derives a current variant string by joining `ActiveVariants` with `+`. If that string is present, the generated `PartCore` is cached under `partName + "+" + variantName`.

## What this means for authors

If a transformer saves information instead of directly mutating the live OAB part, its effect will usually show up through this persistence pipeline rather than through the immediate editor object alone.