I decided to go with #39 and this is what I came up with.
Things done here:
[x] system events removed
[x] user events reimplemented to use explicit timing instead of WHEN and a flag
[x] stage events merged with user events (from now on we're only talking about "events")
[x] events refactored as a separate module (also delegate event now has an :ISDEAD() check)
[x] stage time-to-go calculation fixed
[x] comm events handler reimplemented in the similar fashion
[x] clarifying the staging/UPFG mess
[x] clarifying the UI messages
[x] bringing back system events (countdown!)
[x] docs cleanup
What this gives us is that now the entire sequence - this time meaning both the user defined events in sequence and PEGAS-scheduled staging events from vehicle, so the complete "launch sequence" if you will - is pretty much exactly deterministic and explicit. The system becomes much cleaner (one does no longer have to track userEventFlag, which is not triggered in any mainline code but by a mysterious and untraceable WHEN) and less prone to errors (what about two events scheduled to happen in rapid succession? this is potentially problematic in the comms subsystem). But the main reason is that now we have one place to look for all things that will happen in the future. And this means #37 is now possible.
I'll be updating this with future developments and if all goes well, merge it later this week.
PS: @Patrykz94 if you're still around here somewhere, would you mind taking this for a spin and checking if your booster recovery missions still work? I've never used comms myself, and while I believe I've done everything right, it'd put my mind at ease if you confirmed that it indeed still works as intended.
I decided to go with #39 and this is what I came up with.
Things done here:
WHEN
and a flag:ISDEAD()
check)What this gives us is that now the entire sequence - this time meaning both the user defined events in
sequence
and PEGAS-scheduled staging events fromvehicle
, so the complete "launch sequence" if you will - is pretty much exactly deterministic and explicit. The system becomes much cleaner (one does no longer have to trackuserEventFlag
, which is not triggered in any mainline code but by a mysterious and untraceableWHEN
) and less prone to errors (what about two events scheduled to happen in rapid succession? this is potentially problematic in the comms subsystem). But the main reason is that now we have one place to look for all things that will happen in the future. And this means #37 is now possible.I'll be updating this with future developments and if all goes well, merge it later this week.
PS: @Patrykz94 if you're still around here somewhere, would you mind taking this for a spin and checking if your booster recovery missions still work? I've never used comms myself, and while I believe I've done everything right, it'd put my mind at ease if you confirmed that it indeed still works as intended.
Closes #39