There's a bunch of rockets that we can't fly entirely correctly with PEG or autostaging because they need special things to happen which violating the "simple" Kerbal-style autostaging rules. For example:

• Atlas stage-and-a-half: At 164 seconds into the flight we need to drop the boosters even though no fuel tanks have run dry.

• Delta IV Heavy (and likely any similar looking things like Atlas V HSB or Falcon 9 Heavy): At +44 seconds the core engine throttles down to 55% and then at booster sep it throttles back up to 100%

• Delta II: I haven't researched this extensively but some variants airlight some of its SRBs halfway up and I imagine it uses throttle control similar to Delta IV Heavy.

So we need a way to do this. It might mean writing a MissionPlanner controller on top of the ThrottleController and StagingController, which PEG and FuelFlowSimulation would both query. Or it might mean being able to inspect the existing scripting module to see what it will eventually do (probably need consistent common APIs on top of the scripting controller that other controllers can query to get information about what staging events will happen.

This likely means breaking the correspondence between kerbal staging and MechJeb's staging display. This may be good because I'm running into some bugs around where the zero-dV stages land and where the non-zero-dV stages land in the FuelFlowSimulation.

The Delta II actually doesn't have any throttle. It simply stages off the ground-lit boosters after they've burned out, and ignite the air-lit ones a few seconds later. PEG seems to be able to handle this, although the optimal flight trajectory is a bit more convoluted involving sharp ascent before the air-lit boosters ignition, and rapidly leveling out after the air-lit boosters ignited.

The other thing which could be supported is shuttle-style throttle down and constant acceleration phases, along with progressively shutting down engines to keep acceleration reasonable.

For stock being able to say "throttle to zero after X seconds for a coast of Y seconds" right in the middle of a kerbal stage would be useful for any kind of PEG-to-orbit thing there.

Another thing from NK is that historically the way that early rockets dealt with termination of thrust randomly dribbling throttle and producing inaccuracies is that they would kill the main engine and then dribble on the verniers before shutting them off. PVG kinda does this with RCS, but not with verniers. And RCS has infinite relights and everything else, while if you converted a vernier to a ModuleRCS then it wouldn't function as a vernier correctly on ascent.

There has also been people trying to use verniers to ullage upper stages via having the uppers disabled manually and then pressing the button to light the upper stage manually during flight after it ullages up -- which of course completely destroys the ∆v analysis and PVG can't find any solution because none exists for getting to orbit on a vernier if it doesn't know anything about this ullaging-on-verniers process.

Also from @Starwaster on IRC: Have autostaging reserve X percentage or X amount of propellant -- for a boostback/reentry/landing burn of a recoverable stage.

So there's various issues here which could be handled fairly easily by having staging triggers based on time or triggered by prior stages burning out. So the airlit boosters and the stage-and-a-half kind of issues can be setup to be staged normally, but MJ's autostaging and the fuelflow simulation needs to know those events will happen based on different triggers.

But then there's stuff like fairing jettison which is based on heat flux, and it would be kind of nice to decouple that from the explicit KSP staging (although I've run into issues trying to do this based on the difficulty of determining what is a fairing-fairing and what is an interstage-fairing -- at least it isn't 100% straightforwards as searching for all fairings, and you need to see what parts will get decoupled or something).

And then there's throttling down center-core engines. That can't be done through KSPs staging at all, and requires the ability to say something like "at X seconds, throttle down engine Y" which requires some way of telling MJ which engine you mean.

Then there's also all the other events that can happen on the way to orbit, such as solar panels and antennas deploying.

Also there's a question of if this kind of declarative state machine logic could be reused not just for Ascent but for other modes of operation. Which raises the question of how it interacts with the scripting autopilot, and if these kinds of "profiles" should be sort of saveable-and-swappable.

[ The other thing I forgot here was spin-stabilization and the ability to spin up stages before staging and apply some deg / sec of roll target before staging ]

Ah yeah, I'm talking conceptually about "staging events" there not the StagingController. I think there needs to be some other object wrapping all this which is more of a MissionEventController which is really a controller-controller. The work would get done by the StagingController or the ThrottleController but the orchestration would happen at a higher level, and then the FuelFlowSimulation and the GuidanceController/PVG could get future events out of it.

why would you need KSP's staging to support independently throttleable engines? Do it the way MJ's differential throttle does it with the thrust limiter. (although KSP 1.7.3 does support independently throttleable engine... at least I saw something in the PAW to that effect)

So something that came up on channel of note was that when users try to manually stage for airlit boosters or something like that it causes interesting effects in PVG.

First of all on the pad the delta-V stats will necessarily be wrong due to MJ not knowing about the future staging event. When the staging event happens by the user pressing the spacebar then the delta-V stats will update with the better knowledge that they now have. This creates a LogicalStageTracking event and can introduce bugs into PVG's crazy update-or-removal of stage logic. You probably have a stage both being deleted early and new stage number being added, while at the same time the if (overburning) logic in Optimize() is likely active. The result is an overflow in Array because all of that together hasn't been considered as an edge condition. The best solution here is likely to throw out most of that code that tries to reuse old y0 solutions and patch them up. PVG should really just rebootstrap getting pv0 and pr0 along with the values for the guesses at the staging from the prior solution and thereby not have to deal with such crazy edge conditions and be more reliable. I'm trying to hard to be fast and reuse prior y0 solutions when I should opt for simplicity and reconstruct the problem from scratch and reconverge. The Solution object can be used to pull data off of, but the expanding and shrinking array management is poor.

Second of all, though this shows how we need to support this kind of autostaging and feed it into the delta-V stats so that the predictions are accurate and keep the inputs to the LogicalStageTracking module and the underlying guidance predictable.

High level architecture of the Orion Timeline Management Software is here: https://ieeexplore.ieee.org/abstract/document/5747472 (for inspiration probably).

More references:

• https://ieeexplore.ieee.org/abstract/document/5446722
• https://arc.aiaa.org/doi/pdf/10.2514/6.2008-7291
• https://ntrs.nasa.gov/search.jsp?R=20090029218

At the very least the heirarchical orgnization of the mission into phases, segments, activities and modes is interesting.

Also makes me wonder what a minimal kind of simulink for KSP automation might look like: https://en.wikipedia.org/wiki/Simulink (thinking that automation needs to be able to handle things like abort criteria and abort sequencing and not just a linear recipe)

ieeexplore won't let me download anything

Also, this sounds an awful lot like some sort of autopilot thing... guidance and stuff.... do you mean to tell me that NASA is cheating???

Yep, dirty cheaters, they should use maneuver nodes like everyone else.

making a note of SmartParts since that seems related: https://forum.kerbalspaceprogram.com/index.php?/topic/151340-17-smart-parts-continued/

i don't like the idea of extra parts, but i like the problems that is solving. want to play with that mod a bit and see how it behaves and see if that gives me some inspiration.

So I think I have a bit of inspiration around this. What would be interesting to construct would be an EventManager (working title anyway) that would allow hooking up various "sensors" to "do things" similar to smart parts, but not connected to any parts that need to be physically attached.

Possible triggers might be: altitude, time (after prior stage), speed, heat flux, etc. It should also be possible to click on a part and then craft particular triggers for the part such as "when fuel tank is < 50%" or something like that. The triggers should have options similar to smart parts to do them once, or repetitively or only going up or down as appropriate.

Possible actions would be similar to SmartParts and including staging, action groups, all the new stuff in KSP 1.8, plus actions crated by clicking on a part like an engine to construct something like "throttle down to 50%" (and like anything else you can poke on a part could potentially be added, so firing decouplers outside of normal KSP staging control or whatever).

When it comes to integration with autostaging, the interaction I think would go like if there was a "stage 30 seconds after stage 5" that if MJ would have otherwise immediately staged after stage 5 that the FuelFlowSimulation and StagingController would know to obey all those rules and insert a delay. The FFS could then use that to introduce delays for stage-and-a-half, along with throttle down of core stages, along with doing delta 3 airlit boosters. It could also take over for stuff like deploying antennas, fairing jettison and whatever else that we already do that I've forgotten while I'm writing this.

The FuelFlowSimulation interaction would be necessarily limited since "static analysis" of the rocket can't tell when it hits a speed or an altitude or a heat flux. But triggers based on time or on the state of fuel tanks would certainly work.

As an extended feature you could save multiple of these profiles, and be able to chain the profiles (so once alt > 140km you could active the im-in-space profile). There's some vague questions in my head about how to integrate this with the existing scripting autopilot, and certainly we can add this to the existing scripting autopilot so that when you setup your launch all the state of the EventManager is saved along with it, just like autostaging settings and everything else is already.

On separation it might be interesting to load another profile based on which commandpod was active, so that if you separated a booster and had a commandpod in the booster it could pop the chute based on conditions, that kinda thing.

There's a fuzzy idea I have of how you could do something more like a declarative scripting autopilot where you could activate MJ controllers (similarly to how the scripting autopilot does) based on activation of a EM profile or based on a trigger in the EM profile. This might be able to largely replace the scripting autopilot (with more reusable scriptlets).