The way that the scripting module duplicates all of the state of the ascent autopilot and then has serialization / deserialization in readModuleConfiguration() / writeModuleConfiguration() is not very maintainable as the underlying autopilots are updated.

The scripting module probably needs to use the ConfigNode pulled directly off/on the modules in question. Then the problem, though, is wrapping this ConfigNode for the state of the actual scripting module itself. If we can just have a ConfigNode object (or 2 or 3) hanging off the MechJebModuleScriptActionAscent class then the problem is solved.

May want to have a rethink about how I've been semi-randomly hanging config off of different modules.

lets call this one closed.