LC2-POD had reverted/changed to 'no ascent tanks' in an existing career game. Will likely need to pull the persistence file to see what is (not) being saved.

Thinking more on this; this particular case may have been caused by changes to the modules/ordering in the part causing the module to lose its persistent data state.

Will know more after I can look at the craft in the save persistence file and see what the current persistent data state is.

Overall the code looks like it should be functioning just fine...

Indeed, this must have been an error that occurred when some modules got added/removed from the part. Manually fixing the values in the persistence file restores the proper model state, and that state persists properly on load/reload.

Will keep an eye on this and see if I can duplicate the issue during module changes and find ways to fix it.

Possibly related:
-Launch Game and enter VAB
-Add LC2-POD; Variant is AscentTanks
-Change variant to Standard then back to AscentTanks
-Launch
-Model is Standard variant however resources (fuel + oxidizer) reflect Ascent variant
-Return to VAB
-Variant and model is Standard however attributes reflect fuel + oxidizer present
reproducible with LC3 and LC5

SSTU 0.4.31.110
KSP 1.1.2.1260 +
KerbalEngineer
NearFutureSolar
Tantares

Thanks for the information; will see if I can duplicate the problem with the above steps.

Sounds like there may be some... inconsistencies... in how the persistent data is being updated/saved/reloaded.

Can confirm the above steps will reproduce the problem. Testing the 'fix' now, will update shortly.

Turns out this was related to an 'early return' statement when disabling a variant with no actual model data; it would return before it toggled the internal 'enabled' flag to false, and thus it would think that the 'standard' variant was enabled at the same time as the 'ascent tanks' variant. Upon part reload it would process the first one (ascent tanks) and enable its model, and then process the second variant (standard) and disable the ascent tanks model.

Fixed in dev, will be available with the next published update (later today or perhaps tomorrow).

Tentatively fixed in dev code. Will need to test/verify that the issue can be duplicated with the above steps prior to testing the 'fix' code.

Apparently part/partModule saves data to config node for fields prior to calling PartModule.OnSave, thus when I was updating the persistent data in the OnSave method it would not actually save the updated data but only whatever was present before.

Am now manually updating the data for the field with the current field value whenever OnSave() is called for the PartModule. This should ensure that the current 'live' data is always saved to the persistent file for the game/craft.