UI: Event timeline

[Noiredd]

It was said to be "definitely cool" to have sort of a launch event timeline with a marker showing where we are in the sequence. Since I've been thinking about revamping the UI a little bit, that could be a central feature around which the redesign could take place. The idea is to merge the vehicle and sequence information into one single structure that could be displayed in the UI, perhaps like this:

TIME  | EVENT
T+0   | Liftoff
T+80  | UPFG activation
T+120 | Switch to constant acceleration mode
T+139 | NOW
T+150 | Stage I jettison
T+155 | Stage II ignition
T+180 | Payload fairing jettison

The NOW entry would be continuously updated (T+...) and moved down the list as the launch progressed. Alternatively, only the future events could be displayed to keep the list shorter. Something to think about.

One obvious problem with this concerns the sustainer stages. Their burn time is not really known until the UPFG kicks in, so some of the vehicle-related events cannot be precisely scheduled until that moment, making it rather difficult to create such a table.
With that out of the way, it's just a matter of going through two lists and creating a single, ordered list for display purposes only, and synchronizing that with what's actually going on.

TODO:

• [ ] how to deal with sustainer stages?
• [ ] backend: create a list of events
• [ ] frontend: nice printing
• [ ] timeline synchronization

[Noiredd]

This last bit, "timeline synchronization" is tougher than it seems. We're already running out of sync with the virtual stages thing sometimes (UPFG-side stages vs events that generate them) - courtesy of the complexity of the existing system - and this timeline thing would only further complicate everything.

I feel like PEGAS has grown too large to grasp fully, or maybe was overengineered from the start. This addition would be another patch on top of the already multiply-patched system, and I can't help but think that maybe what's really needed is negative code? A sort of refactor of the existing event handling system as a whole? But then again, do I have the time to do it, test it, retest it, document it, all the time preserving backwards-compatibility with the existing user designs (and my own)?

To make this more concrete. Do we either:

• add this timeline thing as described, attempting to monkey-patch everything we need to make this work, OR
• refactor the event handling facilities, e.g. unifying "staging" and "user" queues into a single body, e.g. free of WHEN statements but using an explicit, manually handled timeline that would be (1) less convoluted, (2) easier to debug, (3) ~~easier~~ possible to display in the GUI?

[Noiredd]

With #43 done, this is coming next.

[Noiredd]

Done in 6d8ea04, 0822615 and 5c0baea.

To briefly answer the bullet points from the original post:

• how to deal with sustainer stages: it's fundamentally impossible to predict everything before vehicle is initialized for UPFG, and that cannot be done too early (sustainer stage mass calculation vs having SRBs or stuff); what we do instead is stick with the basic sequence entries during passive guidance, and display the full plan only when everything is initialized,
• backend: create a list of events: a separate list is used; instead of operating on sequence directly, only the desired events are copied, with their messages pre-generated to reduce overhead,
• frontend: nice printing: simple, another GUI box is added to the bottom,
• timeline synchronization: we watch the last handled event (eventPointer ) and update the flight plan when this changes.

For details, check commit messages and code.