Is this the scene you were referencing?
I'm remembering now that I was explaining that the swap could be done with a set of native triggers alone.
The scene is overly bulky as is, but I could remove all but the persons and buttons.
There's still the question of what you want to swap between the characters - eg. appearance only - appearance + plugins / behaviors. There are different types of swaps,
If I remember correctly, the only difference between using all native triggers vs. using SimpleStateMachine is that (I believe) the native trigger method requires two writes to the 'hard' disk (to do the swap efficiently - else you're waiting on writes & reads to the same file). I'm looking into whether using SimpleStateMachine still required one write to disk, or if I had found a method to do it all in memory...
If you want to use native triggers, for example, to only change the appearance presets, "live", as they are before the swap, you can use these...
,
where Person2 would Store with the name ending in 'ecxtmp2', then Load with the name 'ecxtmp'.
This is a good place to compare SimpleStateMachine state slot contents with the concept of native presets and SubScenes. If we ignore the "playable" features and iterating/indexing/connecting states to other instances/etc... and just focus on the data, the following comparisons can be made:
Changing the Receiver to 'Preset' in the native trigger (pictured above) in theory includes 'everything', and would work like an 'All' state in SimpleStateMachine - main difference between SimpleStateMachine "All" state slots being that everything is in memory, and saved with the scene vs. saving every "preset" / "state slot" to disk. These states/slots have only a negligible impact on scene load because they aren't applying themselves to the containing Atoms until they are "Restored To" via a "Next/Prev/RestoreToIndex" call.
Changing the Receiver to 'PosePreset' would work similarly to 'Controller' state types in SimpleStateMachine - main difference here being SimpleStateMachine Controller states are built on a per-Controllers basis. They do not change/include the state of all Controllers on the Person like a pose preset would - allowing for multiple state machines / other plugins to decide the state of every non-selected controller, while it iterates through states to "animate" its selected controllers only.
Changing the Receiver to 'PluginPreset' should be pretty similar to SimpleStateMachine 'MVRScript' state slots, with differences being the same as the "All" state slots. This, surprisingly, acts like setting triggers for a plugin's settings/options, even if that plugin doesn't provide a trigger. SimpleStateMachine slots then can act like triggers for scripts on the same Atom, and/or on child Atoms. Again, just act as though you are going to create a preset for the plugin(s) you want to change at some point in the scene, but instead of naming and saving a preset to save/load from disk on every change, you create a state slot, and use the 'Edit' and 'Play' modes along with the navigational triggers to control the "script preset triggers (if you will)".
This is also a good place to note that the "Others" state types for SimpleStateMachine will always include "everything" except for whatever other singular type or collection type options are available. So currently, they exclude controllers, scripts, and/or pose morphs, depending on the context.
