noiredd / pegas Goto Github PK

In its current implementation, the program allows G limiting only when engines are sufficiently throttlable, and doesn't allow throttling similar to Apollo's Saturn I stage, which shutdown a central J1 engine to reduce acceleration.

I suggest using action groups to set the program to shutdown one or multiple engines during flight to reduce acceleration

This would be done by setting the action groups up in the VAB, then an entry in the "vehicle" list along with the g limiter setting:

[String] for "throttle" or "shutdown (throttle setting works as current
[Number] for action group number
[Number] for new thrust after engine shutdown

Now I don't have a good understanding of how the UPFG algorithm does its magic, but I believe that for the algorithm to work, it would need to know exactly when the engine shutdown occurs in order to converge properly, so it may be necessary to program the engine shutdown to occur at a given time, rather than when a certain acceleration is achieved, then have the algorithm treat this as two distinct "stages" to converge correctly

This happens when you try to combine a upfg activation and separation of side boosters for a sustainer stage.

Since the mass calculations for sustainer stages are done around 5 seconds before the specified upfg actiavtion time (upfgConvergenceDelay), if you try to combine side boosters separation and activating the sustainer stage, pegas will include the mass of the still attached side boosters and treat it as extra fuel mass. This messes up the deltaV and burn duration of that stage.

Detecting those situations is quite easy, you can check if ignition is FALSE and jettison is TRUE. As for fixing this, maybe re-calculate the masses again after separation?

In game UI still says v1.1

UPFG in the current implementation assumes that all the burns are executed immediately one after another, but in reality some time is needed between stages to let them separate and ignite. This time is user-input and thus predictable. Lack of handling those small coasts isn't usually a big issue (any error that it generates is eventually accounted for in the next stage), but in some cases this might cause weird behavior. Example of such case is the Saturn V, where the final stage (S-IVb) ignites only for a few seconds to circularize, but before it does, the vehicle is in ballistic flight for a while. Since PEGAS isn't aware of that coast, it doesn't prepare for it, so there are several seconds during which the vehicle is coasting but all the calculations were done assuming it would be thrusting instead. This is the potential cause to the resulting problem*: after the stage ignites, attitude rapidly changes and the vehicle makes two sharp pitches.

In the original implementation, UPFG is able to handle at least one coast stage (period after jettisoning the Shuttle's External Tank, before the OMS burn). The thrust integrals potentially could handle more than that, and implementing it would make PEGAS more robust to coasts, potentially even allowing longer coast periods.

Marking this as future enhancement, since 1) it is not a dire issue, 2) it might be difficult to implement, requiring alpha-test in a prototype environment.

* - this problem has at least one alternative cause: the convergence check could be still imperfect and allow PEGAS to take steering even though the UPFG isn't actually ready yet.

Hello.
Is it possible to use this algorithm for executing on-orbit non-impulsive burns (i.e. to change orbital parameters of the relatively low-thrust spacecraft which is already in orbit)?
And if the answer is yes - any suggestions on how to implement this using existing code?

Hi Przemek,

I contacted you on Space Exchange (Mitch99) regarding the PEGAS porting - thanks for responding! Please contact me at [email protected], and let's discuss further!

Thanks!!

So for ullage, you can choose none, srb and rcs. But a hotstaging option where it presses spacebar a bit before the staging event to ignite the engine and then again at the staging event to jettison the previous stage would be nice

I want to use UPFG to achieve spaceX booster landing.

I have tried to directly change the existing pegas code but it did not succeed. I also read NASA's documentation and found that Shepperd, S.W., Robertson. W. M., "Conic Required Velocity Determination", Space Shuttle GN&C Equation Document No. 26, Draper Laboratory 1973 is the key in landing mode.

Do you have this document, or can you give me some advice on how to write a landing code?

Also may I get your email address so that I can contact you directly

Do you plan to add this in the future?

It would be useful in cases where you'd like to launch directly to a transfer orbit, mostly because engines in RO usually have limited ignitions while some of them have only 1, so launching to a parking orbit and then re-igniting for transfer orbit can sometimes be a problem.

It would be useful, if only for demo purposes, to have a free-LAN mode, that is, a mission type where LAN is unconstrained.

Without going deep into UPFG (which requires both INC and LAN to constrain the target orbit) this might be easiest solved by calculating a launch in e.g. 1 minute from activation, using a process reverse to orbitInterceptTime function.

From my own experiences, half the time of developing a launch script (that is, the vehicle, sequence, controls structs) is tuning the verticalAscentTime and pitchOverAngle values to get a good atmospheric ascent (going too much "up" increases the apoapse so much that UPFG has to burn downwards to cancel it out, in extreme cases the algorithm fails to converge; going too much "forward" doesn't gain enough altitude and UPFG has to burn up more than otherwise necessary, in extreme cases the vehicle RUDs).

It could be useful to have more control over the early ascent, for example by using control points: "at time T rotate to pitch P" and a soft interpolation (kind of how the old PEGAS worked). On the other hand, this increases the overall complexity of the system, which was designed for simplicity to begin with.

EDIT: This is being put on hold as I do not have enough free time to actively work on this anymore.

Similarily to #6, it's a small quality of life feature so that entering the inclination is not necessary. Instead, if inclination is not defined, set it to the launch site latitude.

There are many situations, particularly if you play RP-0 career, where the orbit inclination doesn't matter. Usually those "First Artificial Satellite" or "Have X number of Kerbals in orbit for X amount of time" don't specify anything other than orbit periapsis.

I have a second stage with gLim and minThrottle set to the appropriate values, but wherever the throttle reaches the minimum the engine just shuts down instead of holding that throttle value. I assume this is because the throttle keeps getting lowered in order to retain the configured g-limit, but I was wondering whether this is a rounding error that can be fixed by just setting minThrottle to a slightly higher value (without loss of precision in orbital insertion).

As first observed in #47, RO engines sometimes take so long that the thrust watchdog mistakes this for a lack-of-thrust event and terminates the flight. This is however only the most extreme variant of a more common scenario.

PEGAS does not account for engine spool-up in any way. This means when the ignition sub-event occurs, it is assumed that the engine is "on", produces maximum thrust amd consumes maximum fuel. This is obviously untrue, as several seconds can pass between "ignition" and "max thrust". As a result of this delay, vehicle uses less fuel per unit of time than PEGAS calculates. Consequently, the actual burn time of the stage will be longer, potentially causing issues with staging (e.g. accidental hot-staging).

Potential solution might involve adding an extra key to the engine config to allow specifying the spool-up time per engine. PEGAS could obey this by introducing an additional flag, e.g. engineIgnited which would be set after this spool-up delay, triggering all the internal calculations (i.e. keeping track of fuel consumption) which would otherwise be suspended until then. What do you think about this, @theLXMB?

(Now perhaps I'm reaching too far into the future but this might just allow determining the complete flight plan even before lift-off - at least for all non-sustainer vehicles. I've always wanted to do away with initializeVehicleForUPFG or execute it as early as possible, something that would be even more cool from the point of view of the flight plan print out 🤔)

It has been pointed out that simple steering locked to a vector calculated by UPFG breaks for some vehicles. The solution is to apply a vehicle-specific transformation of the steering vector that accounts for the vehicle center of mass, and then locking the steering to that.

This should be easy to implement using an additional layer of abstraction between UPFG output and kOS cooked steering. An additional function would input the raw UPFG steering vector and output a real vector that steering would be then locked to. This function would default to an identity transform:

FUNCTION nullTransform {
    DECLARE PARAMETER inputVector.
    RETURN inputVector.
}

But it could be overridden by the user in the form of a delegate, for example passed through the CONTROLS lex.

Seems like a simple fix, but help with testing would be appreciated.

PEGAS crashes if the resulting flight plan is shorter than 5 items. Problem is on line 480 in pegas_misc.ks.

Another crash occurs if all sequence events occur prior to UPFG activation. Relevant line 406 in pegas_misc.ks.

Fixes seem simple and I'll implement them soon, just posting here to notify that I'm aware of the bugs.

Not really an issue, but having a few more sample files would help noobs like me trying to learn how to use PEGAS. I got my Saturn V working on PEGAS for the most part (occasionally pitches down) but I'm currently trying to shut down the centre engine and I can't figure it out because I got no example to refer to.

TestFlight and TestLite mods add in-flight engine failures like ignition failure (engine fails to start), loss of thrust (thrust is roughly halved so stage will burn for longer than planned), loss of performance (ISP is reduced and therefore thrust too), engine shutdown and engine explosion.

There are some cases where PEGAS could either complete the mission by automatically adjusting some parameters or trigger an abort if it knows it can't do anything.

Some examples:

• Engine fails to start or has some other kind of failure on the pad - PEGAS could abort the launch at that point as long as the rocket hasn't lifted off yet.
• One of multiple engines shuts down or looses thrust during ascent - PEGAS could probably try to recalculate the ascent with currently running engines.

This could be a separate module, kind of like comms that only works if TestFlight/TestLite mods are used. I'll play around with it to see what's possible.

May i port your UPFG Code to kRPC ?

Instead of using "until false...break" loops, it is a much better programming practice to use proper "until " loops. Not only that, but it saves memory by not making the computer constantly create and delete the same process repeatedly.

Found by @Patrykz94 and posted as a comment in #10:

I noticed that the gLimit doesn't seem to hold the acceleration at the specified value, instead the acceleration is slowed down a bit. I'm guessing that's because Pegas doesn't take in to account the engine throttleability. This isn't a problem in stock as all engines can throttle down to 0 but it is in RO.

The throttle setting and the throttle indicator (by the NavBall) and even the thrust limiter slider in right click menu are not setting/showing the "actual" engine throttle, they control the usable range of the engine (range between minimum throttle and maximum throttle), with the exception that setting it to 0 will cause a shutdown. What I mean by that is if an engine can only be throttled down to a minimum of 50% then when you set the "throttle" via kOS or using the keyboard to 0.5 (slider exactly half way through the scale) then the engine will actually produce 75% of it's max thrust, which is 50% of it's throttle range. You can verify this by looking at the "Current Throttle" field in engine right click menu. You can see it on this video here.

I suggest adding another (optional) parameter to "engines" where users can specify the minimum throttle of an engine and Pegas could calculate what throttle setting it needs to use to acheive the desired result. In the script used in video above, I just made a multiplier (1 / (1 - (minThrottle * 0.01))), minThrottle being a percentage, then I set throttle to (multiplier * desiredThrottle) - (multiplier * minThrottle), desiredThrottle first being clamped between minimum and maximum values.

This essentially breaks constant acceleration mode.

I was convinced that RO clamps throttle setting, in the sense that if an engine throttles in 50-100% range and I set 70% then it goes on 70%, and if I set 30% then it stays at 50%, and 0 causes shutdown. But the scaling logic is just baffling... I have to admit, I can't imagine why is it designed this way 😕

Now I understand why my const-acceleration stages were often a fraction or even a few seconds off (predicted vs actual burn time).

One feature that I feel would be useful is being able to set what happens after PEGAS has completed the ascent.

This could be done by adding some kind of optional parameter to the mission file to specify what to do once PEGAS has done it's job (successfully?), i.e. PEGAS CPU could run a program, send a message or simply stage.

This would make it possible to automate the whole mission by having PEGAS do the launch and after that run a program responsible for on-orbit operations, or send a message to the payload confirming that it's safe to decouple.

To simulate real Space Shuttle launches, or any vehicles with asymmetric TVC, roll control is a necessary feature.

Simplest solution would be to add a controls entry containing a desired roll and time of executing the roll maneuver. A more powerful solution would be via sequence, allowing rolling at any time - but would that be ever useful?

When coding the throttle and roll user event types I thought about having more general kinds of events, mainly:

• action group calling events,
• delegate events.

The first kind would allow easy automation of tasks like solar panel deployment.
The second would be a powerful tool for advanced users to allow PEGAS execute arbitrary code via function delegates.

Labelling this as a future enhancement until a more clear vision of those features emerges. Comments?

Is it possible to pull off true or mean anomaly targeting? If so, how?

As of kOS v1.4.0.0, the default behavior of kOS does not allow for variables to be named the same as a built-in function. In particular, this breaks scripts that use r as a variable, as that conflicts with the function R() which creates a direction based on an Euler rotation. As PEGAS uses r as a variable, this causes the script to crash on newer versions of kOS.

Alongside this change, the @CLOBBERBUILTINS directive was added, that restores the old functionality and lets variables overwrite the built-in function. In order for PEGAS to work on newer versions of kOS, either

• A: The @CLOBBERBUILTINS on directive must be added to the top of any of the files that require the use of the r variable (similar to the @LAZYGLOBAL directive), or
• B: The variable r must be changed to not conflict with the R() function. This is the recommended fix by the kOS devs.

Current release only supports launches in the northern direction, implicitly assuming this direction. Interestingly, mission has an undocumented key launchAzimuth allowing the user to make somewhat of a dogleg ascent by constraining the initial azimuth (which would otherwise be calculated) or a southerly launch. Unfortunately, orbitInterceptTime assumes the launch always happens in the northern direction and if someone actually tried forcing the southern direction, the whole algorithm would think it's going the opposite way than it should and try to correct that.

This one seems easy to implement:

• mission should have a direction key of type String, allowing the user to choose the direction,
• orbitInterceptTime should respect that setting.

Rest of the algorithm should handle without need for further changes.

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

Currently the program allows targeting for the moon or other spacecraft orbiting Earth, but has no support for launching to a parking orbit in preparation for an interplanetary transfer.

Not knowing how to set up the inclination and LAN myself, is it possible for a mission file to be created for such an orbit?

Would be a nice addition if PEGAS could either kill time warp when launch time is approching, or add an alarm via KAC mod and let KAC handle it. Documentation page for KAC here.

I wouldn't really recommend starting a timewarp but killing it would be useful. Easy to overshoot when doing it manually.

I'm trying to setup a custom function that shuts down vapor vents just prior to lift-off, but I can't get PEGAS to recognize it. As recommended by the tutorial, I defined my delegate within pegas.ks near the top of the file:

GLOBAL _PEGAS_VERSION_ IS "v1.3-alpha".

//	Check if all necessary variables have been defined, exit early otherwise.
RUN pegas_precheck.

// Delegates

FUNCTION shutvents
{
	FOR vent IN SHIP:PARTSTAGGEDPATTERN("pp.vv") 
	{
		radEng:SHUTDOWN.
	}
	WAIT 0.
}
SET aaa to shutvents@.

...

and tried to reference it on the boot file through the following sequence:

GLOBAL sequence IS LIST(
	LEXICON("time", -25, "type", "delegate", "function", aaa, "message", "Shutting down vapor vents"),
	LEXICON("time", -7, "type", "stage", "message", "RD-180 ignition"),
	LEXICON("time", 0, "type", "stage", "message", "LIFTOFF"),
	LEXICON("time", 90, "type", "stage", "message", "SRB jettison"),
	LEXICON("time", 180, "type", "jettison", "message", "PLF jettison", "massLost", 1108),
	LEXICON("time", 260, "type", "roll", "angle", 0)
).

This obviously won't compile because aaa is not defined at this point - the boot file runs before PEGAS. What am I doing wrong?

In the negative guidance program, the spacecraft will keep the attack angle zero. However, when I was running the program, the angle of the spacecraft pitch over too fast and pitch over about 90 degrees at the altitude of 20km. would you like to tell me how to fix it?

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.

If you configure your vehicle to follow a pitch program (which potentially flies at a high angle-of-attack at some point), this setting will be disregarded when PEGAS is about to switch to active guidance. Offender is line 935 in pegas_util.ks - since it wasn't changed to account for the new pitch program mode, it still assumes that the only correct way of flying in the atmosphere is min-AoA.

Solution: replace this with a call to atmosphericSteeringControl.

Hey, updating from v1.2 to v1.3 for most of my rockets the g limiter disengages between fairing separation and burnout of the first stage. This happens to all rockets where the fairings separate after PEGAS throttles the engines for constant acceleration.
Nothing in the boot scripts changed, although I have changed the PEGAS code in a few ways:
In 1.2:

• pegas_settings.ks - "upfgConverganceDelay" from 10s to 5s coming from 1.1. With some launch vehicles PEGAS never converged with holding attitude for this long between sequence events.

In 1.3

• pegas_settings.ks - "upfgConverganceDelay" as above. Doesn't appear to make any difference here if it's 5s or 10s, probably because of holding AoA while converging. So I reverted it back to 10s.
• pegas_util.ks - line 1032 from "IF TIME:SECONDS < twb_timeOfStaging + 2 { RETURN. }" to "IF TIME:SECONDS < twb_timeOfStaging + 5 { RETURN. }" as some upper stage engines take so long to spool up, adding to staging wait times, thrustWatchdog always terminated the launch.
• pegas_misc.ks - line 477 to 484. Subtracted 1 from every number except "0" to fix the crash in issue #45

This is the same launch vehicle with the same script, just going from 1.2 to 1.3 including everything mentioned above. The scaling is different, but the sudden throttling is easily noticable:

And here the boot script as it originally was:

GLOBAL vehicle IS LIST(
		LEXICON(
			"name", "Seeotter-I Hauptstufe",
			"massTotal", 350767,
			"massFuel", 129898+158765,
			"gLim", 4.5,
			"minThrottle", 0.4,
			"engines", LIST(LEXICON("isp", 339.0, "thrust", 5939700)),
			"staging", LEXICON(
					"jettison", FALSE,
					"ignition", FALSE
					)
			),
		LEXICON(
			"name", "Polarfuchs-I 1",
			"massTotal", 42773,
			"massFuel", 6149+28931,
			"gLim", 1.6,
			"minThrottle", 0.0,
			"engines", LIST(LEXICON("isp", 468.0, "thrust", 240000)),
			"staging", LEXICON(
					"jettison", TRUE,
					"waitBeforeJettison", 0.5,
					"ignition", TRUE,
					"waitBeforeIgnition", 0.5,
					"ullage", "rcs",
					"ullageBurnDuration", 2,
					"postUllageBurn", 4
					)
			)
).
GLOBAL sequence IS LIST(
		LEXICON("time", -1.5, "type", "stage", "message", "Zuendung"),
		LEXICON("time", 0, "type", "stage", "message", "Start"),
		LEXICON("time", 155, "type", "jettison", "massLost", 2214, "message", "Abwurf Nutzlastverkleidung")
).  
GLOBAL controls IS LEXICON(
			"launchTimeAdvance", 150,
			"verticalAscentTime", 7,
			"pitchOverAngle", 5,
			"upfgActivation", 89
).
SET STEERINGMANAGER:ROLLTS TO 20.
SWITCH TO 0.
cd(seeotter).
CLEARSCREEN. 
run seeottertest.

With this rocket I could mitigate the problem by moving fairing separation within seconds of burnout without losing an appreciable amount of payload, as there is a around five second delay from jettison to 100% throttle. But with some vehicles it's immediate and I'd need to carry the fairings to way outside the atmosphere.

Apart from that, the ascent trajectory is so much smoother in 1.3, so really good work on that! I (mostly) really enjoy using PEGAS. ;)

Getting a strange bug during launch. i had the procedure working correctly, and I don't know what i have done differently to bring on the bug.

Launch goes fine at first, atmospheric flight is normal, boosters drop and the guidance takes over shortly before first stage burnout, then just as the second stage lights, the third stage separates (igniting 3rd stage engines) causing a catastrophic failure at the top of the atmosphere.

Files attached:
Craft File, vehicle and mission plugs for the Pegas and image of the bug

Plugs.zip
Craft File.zip

Any help would be appreciated

In very specific circumstances PEGAS can fail to perform the final engine shutdown.

Example of this behavior can be observed for a 2.5 stage vehicle where the last stage is only minimally expended (think an S-IVb which only ignites for a few seconds to circularize). To illustrate, let's assume the following vehicle staging sequence:

• UPFG is initiated for the sustainer 0.5-stage at T+100, the stage burns for 300 seconds
• stage 1 activation is thus scheduled at T+400, its burn time is 400 seconds
• stage 2 activation is thus scheduled at T+800, its maximum burn time is 600 seconds.

The actual burn time of stage 2 will depend on payload mass and final velocity (vgo). It can happen that this time is very small, suppose 10 seconds. UPFG will schedule the final MECO at T+810 (or is it T+~815, accounting for stage activation time?). At T+800 the final staging sequence commences and the vehicle begins to coast. This makes the vehicle status begin to rapidly diverge from what UPFG expects, so the algorithm takes much longer than usual to converge on the final guidance. At T+805 the engine is ignited, but the guidance has not yet converged. At T+810 the target velocity has been reached and the engine should be shut down, but UPFG still has not converged - and at this point it never will - and so PEGAS is stuck in staging mode. All the time the orbit grows arbitrarily far beyond the target values (limited only by the amount of fuel in the stage, and the user's patience before they abort the mission).

Stuff to look into:

• does UPFG-predicted shutdown time include the stage activation routine delays?
• can we detect a situation where MECO is just around a staging event? (and if so, what should we do then?)
• should we include the final coast phase in the calculations (remember: UPFG has the capacity to include even long coasts)

I was just wondering if anyone has had any success with Asparagus staging. I have tried to do something like (mass 3*(1000000+7500000)) then after separation divide the thrust by 3 then add the difference of full tank to the amount left in the center stage. I have had no success with a lot of trial and error. Just wondering if anyone has tried to make a working script. Flying the Atlas heavy is not worth it unless you can Asparagus stage.

Discussion on #31 raised an interesting idea of creating a system for custom add-ons, i.e. modules that could be added to PEGAS to enhance its capabilities without modifying its own code. Let's discuss whether such a system could be useful, how practical could be its implementation without a thorough rewrite of the core, and how could it be implemented.

I'm imagining something akin to how Python's modules work: you can put .py files in a directory and then load them by name (import my_module) or use importlib to do all kinds of magic and e.g. automatically import specific objects/classes/functions from all modules in a given directory (example). If this could even be done in kOS, the system could work like this on the initialization side:

• scan the addons directory on the PEGAS volume,
• RUN each file in the directory,
• each addon performs its own initialization and calls a register_module function exposed by PEGAS' addon interface,
• register_module receives a delegate from the calling addon and adds it to some internal registry.

This way adding a new add-on would be as simple as putting its .ks file into the addons directory - no modification of any core module neccessary. What I definitely wouldn't want is to need to add a line to pegas.ks every time I want to integrate a new add-on.

Then during PEGAS' runtime, the subsystem would periodically call all of the registered addon delegates, which are neccessarily lightweight so that each loop over addons doesn't take forever. These functions could check conditions and call heavier handling functions if needed (interrupt-style), or even schedule their execution (event-like). Such a handler could basically hack anything - all of PEGAS is built on global variables and kOS does not limit the scope of such vars (as far as I remember) so just knowing their names should be enough to monkeypatch anything the user would want.

However, my kerboscript is quite rusty by now so I don't know how practical this is. Maybe it cannot be done this way? Let's talk about this. And let's talk about what potential uses this system might have - it's important to keep in mind the practical problem that we want this to solve.

I'm working on this functionality on my fork which would allow another CPU to request a stage separation while in the atmospheric guidance mode (before UPFG converges).

This feature is useful in my project (landing a rocket booster) because I need to separate before the fuel runs out in the first stage and I don't know the separation time in advance (well, I can figure out a few seconds in advance). Not sure how useful (if at all) it would be to anyone else but if you want, I can send a PR when it's done.

In case this is something you'd like to add to the main PEGAS script, I wanted ask what would be a good way of implementing this?
My current plan is to add a WHEN trigger running in the background and checking if the message queue is not empty. Once it receives a message with staging command, which could be either a string "stagingRequested" or maybe a list/lexicon which also contains the staging time, it would change the control["upfgActivation"] to the new desired staging time (either now or a few seconds in advance), and also change the nextStageTime global variable to the new value.

I haven't had a chance to test this yet but looking at PEGAS code, I guess that would hopefully work.

Would you be interested in this to be added to PEGAS?