Expanding flight computer: pop conditions, "keep speed" mode, autostage and possibly ignoreRotation for pitch, roll, yaw, orientation

[JDPKSP]

(warning; wall of text inbound:)
Since the flight computer is currently being overhauled, it might be time to build in a bit of simple programability.
I suggest replacing the current system of extraDelay with a more fleshed out system of different conditionals. The main functionality would be for any command to only pop if the pop time has occured && the pop condition is true.
From the top of my head I can think of the following pop conditions:

• None (would simply always return true)
• Time (could be both in supplied gametime, or something functionally identical to extraDelay)
• Altitude
• Height from terrain
• Speed
• Surface Speed
• Vessel landed or splashed
• Time to apoapsis
• Time to periapsis
• Apoapsis altitude
• Periapsis altitude
• Orbital period
• Semimajor axis

Combined with a keep speed functionality, this would make it possible to program the flight computer to do a complete landing maneuver. For example, in an atmosphere, in pseudocode the following commands could be queued after using the existing maneuverNode system to place the periapsis within the atmosphere:

• orient: surface, retrograde. Condition: none
• ActionGroup: deploy parachutes. Condition: Surface speed = 20 m/s
• Orient: Pitch=90, Yaw=90 (more on the absence of roll later). Condition: Surface speed = 2 m/s
• Extend landing gear. Condition: Distance from terrain = 10 m
• ActionGroup: Deploy solar panels and antennae. Condition: Vessel landed or splashed

of course "=" here would actually more likely be something like:
(val > targetVal && prevVal < targetVal) or (val < targetVal && prevVal > targetVal)
since the precise moment where val = targetVal would probably not coincide with a tick.
An estimated time at actual pop would be good to have for timewarp throttling. For this I we could possibly just assume a linear function, and continuously calculate it from val and prevVal (provided a known time for each value). This would be a very changing and rough guess. But should be enough for timewarp throttling to work as intended.

Note that making conditions also apply to cancel commands it would be possible for the player to designate at which precise condition to terminate a command. so a "burn 100% until altitude = 1km" command would be possibly without having to build in a whole new system of conditionals.

A keep speed mode would be advantageous to have in cases where powered landing is required. Possibly, since this mode would only be used for landing (or possibly early launch within atmosphere), it should assume the player is interested in keeping a certain surface speed, and not orbital speed.

Another small suggestion would be to ignore any pitch, roll, yaw value set in the GUI if the field is left blank. The blank values would simply be set to whatever pitch, roll and/or yaw the vessel currently has.
The flight compyter tends to wobble quite a bit at low speeds when orientation is set to retrograde, for this, simply telling the vessel to point straight up would be preferred. Since we wouldn't want the vessel to rotate, we simply wouldn't specify any roll.
This feature could also make launching vessels that have been rotated within the VAB less of a hassle.

And as a side. side note: having a autoStage flag would make multistage launching under signal delay a lot more feasible.

Regarding implementing this in the GUI. For the conditions, it should be a somewhat easy matter of having a combobox where we currently have the label for extraDelay, from this the player would be able to switch condition modes. Possibly, the default selection could be something functionally identical to extradelay. Whatever is selected in the combobox would define which kind of parsing would need to be done with the textField (time, speed, lenght).
The main idea though would be for conditions to be as unoptrusive as possible, so that players who want to go complicated can do so easily, and players who don't, can wholly ignore the feature.

Regarding "keep speed" and autostage, some extra room would be needed in the main flightComputer GUI. "keep speed" could possibly have its own tab, provided tabulation is implemented to account for the rover computer, but an autostage checkbox should probably be present on any flight related tab.

[neitsa]

See also @JDPKSP comment in #123.

[muppet9876]

Just in case it's not already covered by the above:

allow more than one maneuver node be queued ahead of time.

Looking at #123 I see this got asked for back in 2014 ;)

[YamoriYuki]

@muppet9876 If you look at #123 you'll see that there's a reference to a possible duplicate #73 where Peppie23 implemented this feature into 1.6 and it's there to this day. Unfortunately it's a little awkward to use (like most of Flight Computer features) and is only available to vessels without local control (why? beats me ...). If these conditions are met, you'll see a very dark blue button labeled FC+ to the lower left of the red "remove maneuver" button when you right click the expanded maneuver node. Beware, it only queues up the "execute maneuver" command, not the "keep node prograde" command. You'll have to add that manually into the queue before the next execute or it may fail (spin out, waste all fuel and whatnot).
So take a probe core, tank, engine and antenna to orbit and see for yourself.