Runtime behavior
This page documents how V-SwiFT behaves after the authored data has been loaded.
Plugin startup
VSwiftPlugin sets up three important things:
the shared logger
the shared UI implementation
the Patch Manager mixin library
During initialization it also loads the popout-window UI assets used by VariantSet.IsPopout workflows.
Module lifecycle
Module_PartSwitch adds a Data_PartSwitch module-data instance if one is not already present, then routes initialization based on backing mode:
OAB: builds controls, creates predefined dynamic nodes, and applies active variants
flight: validates active variants and applies the flight/common phases
OAB behavior
In OAB, each VariantSet becomes either:
a dropdown property, or
a popout-window action if
VariantSet.IsPopout = true
When a selection changes, the module:
updates
ActiveVariantsresets tracked reversible state
reapplies common and OAB transformer phases
recomputes OAB mass values
queues a PAM refresh
Flight behavior
In flight, the module validates the active variant list and runs ApplyCommon plus ApplyInFlight on the active variants. Most current built-in transformers do their real work in OAB or common phases, not flight-only logic.
Tech-lock filtering
Variant dropdowns and popout selection states follow the tech tree. A tech node unlocks a variant when its UnlockedVariants list names it. A variant that no node names is always available. When parts are unlocked by science, the dropdown leaves out a variant whose node is still locked. The popout marks that variant unavailable and names its node.
Reverters and reset
Before variant application in OAB, V-SwiFT stores original state for unique IReverter instances. Later reapplication resets that tracked state before applying the currently active variants again.
Extra refresh hooks
Some transforms trigger follow-up refreshes:
mass changes feed into
Data_PartSwitch.MassModifierand then OAB mass recomputationmaterial changes queue a delayed color refresh
dropdown changes queue a PAM redraw coroutine