Acceleration limiting by engine shutdown

[TheGrover]

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

[Noiredd]

I was thinking about this feature as well, engine shutdowns would come in particularly handy for very powerful first stages. But at this moment I don't have a good idea how to solve it; by good I mean:

• doing the job in a general, extensible way,
• being easy to use,
• not ruining existing features,
• not requiring an additional facility on top of the existing ones.

Best solution would do it in a way that allows shutting down engines both in the passive and active guidance phases. The only facility PEGAS has for doing things in a phase-independent way is sequence. And it's easy to think (and implement, really) of an "action group" event, that would allow executing given AGs at given time. The thing is, as you noticed, UPFG also needs to know if and when will a shutdown happen, in order to insert a new stage (just like it does now for the acceleration-limited mode). Worse yet, it need to know which engines are we shutting down - engines (as entries in the stage struct) need to have an additional key to identify them. Bonus: no more combined entries for engines like (...), "THRUST", 5*67000),, one will need to separate the ones that burn till the end from the ones to shut down.

So it seems that these are the options:

1. Use the existing gLim entry in each stage of the vehicle struct, but add an additional gLimMode key to specify whether this should be done via throttling or shutting down an engine, and one additional key to specify which engines to shut down. At this point I'd be folding this into a separate Lexicon, this is too much mess. The obvious disadvantage is that this does not work in passive phase.
2. Use the sequence, but hack it from the UPFG side by checking if there are any shutdown events, if so when do they happen, then which stage is burning at this time, then which engines should be shut down, to finally insert a new stage. Ugly! But at least it does the job in both phases. Except that doing it in the active phase would shift the work of calculating the shutdown moment onto the user - and good luck with that if your vehicle does it more than once (Saturn V, anyone?). I'm pretty sure this would become a feature nobody uses because it's too much effort (on top of all the effort PEGAS already is).
3. Use separate solutions for passive and active phases:
   • introduce an "action group" event type to allow executing any AGs anywhere during the flight, and recommend this as a primary way to shut down engines during passive guidance,
   • follow solution 1 for the active phase; here I'd be more willing to use tagged parts rather than AGs as this provides a cleaner interface between the physical vehicle and the script. Engines to shut down at each stage would have a unique tag, their corresponding entries in the vehicle struct would share it, and the gLim lexicon would also know it, binding everything together.

I will admit, my largest concern right now is not "how to do it with the least amount of code", but "how to do it so that it's clear enough to everyone that I don't have to spend twice as much time on making separate tutorials about it" :P

PS: I allowed myself to change the name of this issue so it better reflects what it is about.

[Patrykz94]

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.

Edit: It may have been better to post this as a separate issue really.

[Noiredd]

Thank you @Patrykz94, this is a very important find. I never knew RO worked this (imho, broken!) way.
And yes, it would work better as a separate issue so I created one, referring to your comment.

[Noiredd]

@TheGrover @Patrykz94 PEGAS now allows you to shut down engines by tag, using a sequence event (so option 2 from my earlier message). This works both in the passive, as well as the active guidance phase. See commits: 19a4025 for the feature, da9cce2 for the documentation, and 28d110c for in-depth explanation. Or just jump directly into the code and documentation.

Thank you for your patience. It has taken me a while, but as a wise man once said: if a man says he'll do it - he will do it, no need to remind him every two years 😅