But I understand wanting to downsize the coding aspect of things.
It's not downsizing, it's having priorities, to focus our very limited resources. It would be nice to have the full ground flow, but IMO flight has priority. It would be nice to have full systems in the upper stages, complete with guidance, but having their meshes in the right place and having them deliver the expected performance to the user has priority. Etc, etc, etc...
Before we add a more sophisticated Centaur simulation (c.g. position shift, thermal rolls, etc), we could "hack" the PAM-D and PAM-D2, and we have the Centaur so why not the PAM-A as well. Even a simple standard switch panel à la Centaur, to control them would be a start. :shrug:
But before all that, we still need to "get there", and work has to be done on the ascent guidance and FCS* (so the MECOTool stops getting blamed for somebody elses errors), as well as the Orbit and Trans DAPs.
Plus, tons of small things, and details, performance increases**, reorganizations, etc...
If this wasn't enough, there is still the SSUWorkbench to finish... :facepalm:
PSA time: if anyone knows C#, your knowledge is welcome here. :hello: There is no need to know anything about the shuttle (or even Orbiter). It's just logic to load and write text files, show options in a window and make some calculations somewhere in there, and I can deal with that math, so there's no need to even know what 1+1 is. :lol:
*) having the FCS effectors and the correct command flow, will then make aborts possible, and some will have to dump the Centaur, so here's the way to that.
**) btw, still need to figure out if having the aero data in binary files is faster on loading.