[Answered] Persistent Fields and Revert to VAB

[Wheffle]

I've got a mod that allows you to tweak some of the fields in ModuleProceduralFairing. It also sets these fields to persistent so that on vehicle load those changes will, well, persist.

When you load a vessel in the VAB, everything's fine.

When you fly, return to the space center, and load from the tracking station, everything's fine.

When you revert to launch, everything's fine.

...

When you revert to VAB, all the fields revert to their default values.

Is it normal for persistent values to act weird when reverting to VAB/SPH, or could this be a mysterious quirk with ModuleProceduralFairing?

Edited June 23, 2015 by Wheffle

[NathanKell]

Doesn't sound like a problem with persistence but rather with determining when to poke your stored values at ModuleProceduralFairing?

I.e. your module's values may be fine but if you don't always apply them to the MPF module you sit next to then sometimes it'll look like the values don't get saved. Or am I misreading?

[Wheffle]

Well, i actually set ModuleProceduralFairing's own fields to persistant. I guess there might be code somewhere that only fires on Revert to VAB that doesn't expect those to be persistant, but that sounds weird to me.

You didn't misread, i just didnt clarify

Edited May 25, 2015 by Wheffle

[Wheffle]

Still no luck finding out what's going on here. Although manually re-loading the vessel after a revert-to-VAB is a reliable work-around, I'm still haunted by the apparent secret code that gets fired (or not fired) specifically with revert-to-VAB. I would assume all it does it change the scene to the editor and then load the autosaved vessel, but in that case you'd think manually re-loading the vessel wouldn't help anything.

I'm not well versed in this, so any insight would be appreciated. Otherwise I think I'm going to shelve this unsolved mystery.

[Diazo]

I just had a thought, how are you saving your data exactly?

One quirk of KSP is that when you click the "launch" to go VAB-Flight and "rever to VAB" to go flight-VAB, KSP does not actually use your saved vessel as named, rather it uses "Auto-Saved Vessel". This is why if you don't click the save button before launching, you sometimes lose changes because KSP saves to "Auto-Saved Vessel", not your named vessel, on launch.

Because you mention that manually reloading the vessel is a reliable work around, I wonder if this is the issue (or part of it) that you are running into.

D.

[Wheffle]

I just had a thought, how are you saving your data exactly?

One quirk of KSP is that when you click the "launch" to go VAB-Flight and "rever to VAB" to go flight-VAB, KSP does not actually use your saved vessel as named, rather it uses "Auto-Saved Vessel". This is why if you don't click the save button before launching, you sometimes lose changes because KSP saves to "Auto-Saved Vessel", not your named vessel, on launch.

Because you mention that manually reloading the vessel is a reliable work around, I wonder if this is the issue (or part of it) that you are running into.

D.

You know, that could have something to do with it, but I'm not sure.

All I'm doing is setting fields (which already exist) in ModuleProceduralFairing to persistent and hoping the dev's code behind the module does the rest. So far it works as expected in every tested case except revert to VAB. Does auto save have some kind of issue with persistent fields?

//pretty much what's going on
pf = getProceduralFairingModule();
pf.Fields["fieldNameHere"].isPersistent = true;

[sarbian]

When do you do that ? Start, Awake ? It may be that the even order is different when comming back to the VAB and you set the field as persistent after the loading is done

[xEvilReeperx]

Well, i actually set ModuleProceduralFairing's own fields to persistant.

This is your main problem. Your code works in the editor because the changes it makes to persistence are in effect every time the craft gets saved there. But they're lost whenever a part is instantiated (until your OnStart runs). You might think you could just edit the ModuleProceduralFairings field persistence on the part prefab but unfortunately each module seems to recreate its own fields when instantiated and any changes to the prefab's fields are lost.

That's why you're seeing oddness in revert. When the vessel gets loaded in flight, a snapshot is created before any PartModule OnStarts are run and saved to ShipConstruction.ShipConfig which is what gets used when reverting to VAB. Since your code hasn't run yet, the fields you want to save aren't yet persistent and don't get saved to this config so when the player reverts, any changes are lost

[Merill]

I tried to do that with reflection (to attack the KSPfield). But it's not possible.

Instead, in onSave, i create nodes from the other module data. In onLoad, i load the data from my node and set them to the other module's fields.

[Diazo]

But are you doing anything in the OnStart() method?

In the editor, when loading a vessel from file, the partModule's OnLoad() method runs before the OnStart() method does. If you have any initialization or setup code in OnStart(), it can wipe the data you just loaded in the OnLoad() method.

Note that in flight, afaik the OnStart() method runs before the OnLoad() method does just to make things extra confusing.

D.

[Wheffle]

Thanks for the replies! Really super appreciated.

This is your main problem. Your code works in the editor because the changes it makes to persistence are in effect every time the craft gets saved there. But they're lost whenever a part is instantiated (until your OnStart runs). You might think you could just edit the ModuleProceduralFairings field persistence on the part prefab but unfortunately each module seems to recreate its own fields when instantiated and any changes to the prefab's fields are lost.

That's why you're seeing oddness in revert. When the vessel gets loaded in flight, a snapshot is created before any PartModule OnStarts are run and saved to ShipConstruction.ShipConfig which is what gets used when reverting to VAB. Since your code hasn't run yet, the fields you want to save aren't yet persistent and don't get saved to this config so when the player reverts, any changes are lost

Forgive me, I'm still a little bit lost. The changes remain when you launch the vessel, revert to launch or focus a vessel from the tracking station, as well as when you load the ship from a file in the VAB. What's happening different that only happens specifically on revert to VAB?

In other words, if ModuleProceduralFairing's fields become non-persistent again (and ignore saved persistent values) every time the part is instantiated, then my code shouldn't work on launch or in any of those other circumstances, because I'm setting them to persistent in the OnStart() method which is running after ModuleProceduralFairing does its thing (I think).

Maybe I'm not understanding the exact order in which modules load and perform their OnStart()/OnAwake()/OnLoad() methods?

[xEvilReeperx]

Forgive me, I'm still a little bit lost. The changes remain when you launch the vessel, revert to launch or focus a vessel from the tracking station, as well as when you load the ship from a file in the VAB. What's happening different that only happens specifically on revert to VAB?

The short answer is that reverting to the VAB causes the editor to load from a ConfigNode that was created when the fairing module's fields weren't set to persistent.

This happens because when you enter flight, the vessel gets created from the various part prefabs which wipe your persistence changes, and then that instance of the vessel is saved before any OnStarts run. Why doesn't the game just use the ConfigNode it must have loaded from disk instead? I have no idea

In other words, if ModuleProceduralFairing's fields become non-persistent again (and ignore saved persistent values)

That's not what persistent means. Persistence simply means "write this value to the disk when object is saved". All KSPFields will load data from a ConfigNode if it contains a name-value key for it. Non-persistent fields won't normally have this value saved in a ConfigNode and instead will end up with whatever their clone-source field value is.

Anyway, to solve your problem, move your persistent attribute changes into OnAwake and set your slider initial values in OnLoad (instead of alongside your persistence changes).

Edited June 6, 2015 by xEvilReeperx

[Wheffle]

Thank you for taking time to thoroughly explain! It's been a learning experience. Now that I understand a little better I'll make some changes and see what happens.

[Wheffle]

Just to follow up, switching over to OnAwake() seems to have worked. Thanks for the help