Anyone who (tried to) read PEGAS code will notice its extremely convoluted system for executing events. For practical vehicles it's hard to grasp what's going on at all times, even for myself. There are 4 main reasons why is that the case:
there isn't really any single predictable "list of events": at any one time, only a single event is scheduled (i.e. its WHEN trigger is set), which - at the time of being handled - schedules the next event, daisy chain style,
the above is in fact a lie - there are in fact 3, not 1 individual event queues: user events (for sequence), staging events (for staging, obviously), and mysterious system events which for now only handle the launch countdown,
the above is also a lie - these 3 queues are not really individual: after virtual stages were introduced, sequence and staging are actually interleaved in a way,
on top of all, staging is non-trivially mixed with UPFG (look at transfer of control over the steering vector and the stagingInProgress variable).
The consequences involve:
difficulty in following what's actually going on at any one time,
desynchronization problems which can occur for sufficiently (but still practically) complex vehicles,
difficulty in displaying a flight plan (#37).
Therefore I propose a complete refactor of this whole system. What I imagine is:
unification of the events pipeline into a single entity (something akin to a priority queue),
manual handling of events instead of relying on WHEN (interrupts are not predictable),
maximum de-interleaving of staging and UPFG.
I'd intend this to be a piece of highly negative code, removing LOTS of existing bloat, possibly factoring everything to a separate module (events are far too central to PEGAS by now to be tossed into "utils" along with stuff like Rodrigues rotations), but most of all simplifying the system to reduce the conceptual burden of understanding it. Of course, all existing vehicle designs would work as they do at present, without any need to reformulate the configs.
I'll tinker on this in a separate branch and see if it's even possible (given my limited free time to work on this). Leaving this note here so that everyone interested was aware of my plans for the nearest future.
Anyone who (tried to) read PEGAS code will notice its extremely convoluted system for executing events. For practical vehicles it's hard to grasp what's going on at all times, even for myself. There are 4 main reasons why is that the case:
WHENtrigger is set), which - at the time of being handled - schedules the next event, daisy chain style,sequence), staging events (for staging, obviously), and mysterious system events which for now only handle the launch countdown,sequenceand staging are actually interleaved in a way,stagingInProgressvariable).The consequences involve:
Therefore I propose a complete refactor of this whole system. What I imagine is:
WHEN(interrupts are not predictable),I'd intend this to be a piece of highly negative code, removing LOTS of existing bloat, possibly factoring everything to a separate module (events are far too central to PEGAS by now to be tossed into "utils" along with stuff like Rodrigues rotations), but most of all simplifying the system to reduce the conceptual burden of understanding it. Of course, all existing vehicle designs would work as they do at present, without any need to reformulate the configs.
I'll tinker on this in a separate branch and see if it's even possible (given my limited free time to work on this). Leaving this note here so that everyone interested was aware of my plans for the nearest future.