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.