Issue 1: Stages containing unbalanced resources are not auto-decoupled until all resources are empty

Expected behavior: As soon as all engines which would be decoupled by a stage are missing one or more resources necessary to generate thrust, that stage should be decoupled.

Actual behavior: If any resource type consumed by the engines is present, stage will not decouple until it has been fully drained, even if there are no fuel lines transferring that resource to other tanks.

This can occur in several situations: If fuel tanks in a stack do not contain the proper 0.9 to 1.1 ratio of liquid fuel to oxidizer (old mod parts, or stacks including both airplane fuel and rocket fuel); or if engines consume fuel in proportions other than 0.9 to 1.1 (mod parts, stages including both aircraft engines and rockets).

Unless there are no engines decoupled by a stage (as in 'drop tanks', which do appear to behave properly), the most likely intended behavior is for the stage to decouple as soon as the engines burn out, even if there are some quantities of a resource left. And if there are no fuel lines transferring resources from this stage to operating engines or the tanks supplying them, then 'likely' becomes 'absolutely' - inoperative engines are dead weight, and waiting until the remaining fuel or oxidizer has been dumped is inefficient.

Issue 2: Non-functional decouplable stages 'block' further auto-staging until manually staged

Expected behavior: Such stages remain attached until all running engines have expired. At that point the non-functional stage is decoupled in order to progress through the staging sequence and activate other engines.

Actual behavior: User must manually activate such a stage before auto-staging will resume.

Issue 3: Auto-staging activates additional non-decoupling stages (such as parachutes) even when there are no engines in or subsequent to those stages

Expected behavior: Unless there are more engines that can be activated without decoupling anything, staging should not progress until the current engines have burned out.

Actual behavior: Anything and everything gets staged, including parachutes (bad thing to activate during ascent), only stopping once it reaches a decoupler or the 'stop at stage' value.

https://dl.dropboxusercontent.com/u/203721/StagingProblemExamples.zip

The first craft file included exhibits all of these issues. The second shows that the first issue is not a necessary precondition for the others to occur. Removing the decoupling nosecone/escape-tower from the second rocket shows that the third issue also occurs on its own.

Ascent autopilot settings used: All options enabled, 40m/s/s limit, delay 0.5 and 1.0, stop at stage 0, 300km orbit, path 5, 50, 5, 75%.

When launching the first craft, alt-right-click the booster fuel tanks and observe the fuel levels. The oxidizer runs out before the fuel (although the problem can also occur the other way around; the Soviet pack's Energia boosters contain too much oxidizer, for example). The engine stops producing thrust and visibly cools off several seconds before the 'fuel' runs out and the first stage decouples. The time before the second stage is even longer due to the asparagus staging fuel pumps. The third pair of boosters are not decoupled for a very long time despite being nothing but dead weight with no fuel pumps drawing from them. I've tried setting the auto-staging delays both to zero instead and it has no effect.

In the second craft, a Kerbal who was not fresh out of engineering school has corrected the original designer's mistaken use of aircraft fuel tanks, and moved the escape tower jettison sequence to before the third booster separation so that it would occur in the atmosphere instead of being sent flying into orbit. Notice that the third boosters will not auto-stage at all. The nosecone must be manually staged, then MechJeb will continue as usual. Once the orbital stage engine is activated, however, it immediately triggers the parachutes even though there is no reason to activate any further stages. It should be smart enough to realize there are no more engines and stop there, at least until that tank is empty.

Can resolution to issue 1 be toggleable? There may be situations where you'd want to keep the resource with you even if it means dragging a dead engine along.

example: space plane with limited oxidiser on board, only enough for circularisation, small orbital maneuvers, and deorbit onboard. Drop tanks carry small rockets to help boost the tanks themselves, and main rocket draws off of external tank's oxidiser even after external fuel is out. Tanks are dropped at apoapsis before burn.

Issue 2. Non functional stage sounds either deliberate (actually want it there and not skipped/dumped prematurely), or failure in design. I don't believe mechjeb should be expected to compensate for gross misdesign, but in the intrest of flexibility, this could be a setting?

Issue 3. I agree wholeheartedly. I've been running into this one myself as I help test a plugin. Multiple launches and sometimes I forget to deactivate the auto staging. Mechjeb should only stage forward when dumping empty tanks or progressing to the next useable engine. doing otherwise can cause problems (parachute deploys during reentry before firey death plunge is over, potentially burning/tearing and certainly altering test conditions, with no way to un-stage it) For those who do not agree, this could be another option?

Issue 3 is a feature, not a bug, in my opinion — MechJeb is just trying to jettison all dead weight. =) If you don't have engines beyond stage X, you can just type X in the "Stop at stage #" field.

Staging based on the presence of fuel is easy. Staging based on the supposed usefulness of the rest of a stage is hard. Do you still want those winglets? Do you still want those landing legs? What about the air intakes?

Consider a ship consisting of a single 1.25 m core, with some wings on the sides and a detachable pod+parachute on top. Stage 2 ignites the engine, stage 1 decouples four wings that are on radial decouplers, and stage 0 decouples a pod+parachute from the engine and fuel tanks. Once your fuel burns out, how is MechJeb supposed to know if you want to detach the wings and activate stage 1? How is MechJeb supposed to know if you want to detach the engine and fuel tanks (and any wings still attached to them) and activate stage 0? You might want to keep those wings as long as possible for a more controlled descent.

I don't know of a good solution other than "check the 'Stop at stage #' field".

@gmcnew The situation you described is more like issue 3 than issue 2. I actually agree with the behavior you describe for your example, as this is what I would want to happen when there aren't any more engines to activate.

But that's the difference - your example has no inactive engines after those jettisonable parts. In the example craft I gave you, in order to activate the last engines and complete orbital insertion, that nosecone must first be dropped. The idea with placing it in that position in the staging sequence is that it should be dropped in atmosphere so that its separatrons won't send it into a stable orbit. But unless you actually combine those stages so that the decoupler and separatrons are in the same stage that separates the last boosters, Jeb will just let the boosters and main stage burn out and then sit there doing, nothing instead of dropping it, dropping the boosters, dropping the main stage, and lighting the upper stage engine to finish its ascent.

@Aquilux On issue 3, yes, exactly. On 1, that's a good point. I haven't used spaceplanes much - everything I design that can take off ends up losing control before it can reach orbit, no matter how perfect it seems in the SPH - and hadn't considered that they might be non-SSTO. I think a toggle option for the staging controller might indeed be useful here. "Stage on burnout" perhaps (instead of resource depletion). It would only apply to stages that would decouple engines, and instead of checking that all resources were empty, it would check if it was possible for the engines to run given the resources contained in the accessible tanks, or some mechanism with similar effect.

@gmcnew If "engine can no longer run" (ignoring things like intakeAir and electric charge) is harder to determine than "all resources empty", then perhaps that one can be a future enhancement? I know it's a bit of an uncommon situation, but giving the player more options to control how it deals with it would be nice.

Okay, so, having it trigger the parachutes in other words?

If there were additional engines mixed in with the parachutes, or in a subsequent stage, it would be understandable for it to stage through them (when not blocked by proper decoupler logic) unless you set it to 'stop at stage X' to prevent that. I'm not suggesting any changes to that.

Let me see if I can clarify: I would not expect MechJeb to perform any further auto-staging, for any reason, once the final set of engines in the staging sequence have been activated. That is, if there aren't any more engines to activate, what's the point of having it trigger stages at all?

Mechjeb is primarily concerned with running the ship's engines to perform maneuvers. Auto-staging is designed to ensure that there are as many active engines as possible and that dead engines are dropped as quickly as possible. So I shouldn't have to worry about telling it to stop at any stage after the last stage that contains engines, because there is no reason for it to activate such a stage. It shouldn't matter whether or not it would decouple anything. (Note that your previous comment was talking about decoupling things "unless set to stop at stage X", but actually MechJeb already doesn't do that. As in the example craft, the parachutes get activated, but not the decoupler, even if the final engine is out of fuel.)

It's always possible that I'm the one who's missing something, though. Is it not possible for MechJeb to tell the difference between engines and non-engines? It clearly treats decouplers differently from other parts. So far the only thing I've seen it do this with is parachutes, though, as in the example craft, although if I create an empty stage during flight, it tends to instantly get cleared by auto-staging, making it tricky to rearrange staging.

Another way to look at it: Checklist!

If a fuel tank would be decoupled by next stage: Is it empty?
(Optionally: If engines would be decoupled by next stage: Is one or more of the required fuel mix exhausted?)
If no engines with fuel remaining are active: Are there any other engines to activate (in an allowed stage)?
If there is another set of engines available in the staging sequence: Could they be activated without decoupling anything?

It seems to me that unless the answer to the first applicable question is 'yes' there's no reason for Jeb to automatically trigger the next stage.

@Tallinu, pardon me if I'm missing something, but I was referring only to issue 3 in my last comment. I don't think it's a bug, so I don't think the behavior you describe as issue 3 should be changed at all. Are you suggesting that the issue 3 behavior should be something other than simply checking "Stop at stage #"?

Issue 2 does sound like a bug, on the other hand. And I'm still thinking about issue 1.

I personally would like to see MJ release parachutes or even lower landing struts (which it used to but now doesn't seem to) piloting is about more than engines!

It does deploy parachutes. It just does it as soon as it reaches them in the staging sequence, which can lead to them being activated in space or during an ascent depending on your craft's staging setup, which I find highly unintelligent, unless you properly set up a 'stop at stage' limit - and if you have more staging to perform after parachute deployment, you can't have it both ways.

Like gmcnew said before though, how is MechJeb supposed to know when you want the parachutes deployed? In my opinion, unless they're mixed in with components that MJ will trigger at a known, predictable moment, they should not be auto-staged until necessary to activate other engines, if at all.

I've had parachutes eject in space but only as a result of a staging error,
it's quite simple for MJ to know when you need parachutes - you're in an
atmosphere targeting a landing site and you don't have engines or have run
out of fuel...

On 26 April 2013 08:41, Tallinu [email protected] wrote:

It does deploy parachutes. It just does it as soon as it reaches them in
the staging sequence, which can lead to them being activated in space or
during an ascent depending on your craft's staging setup, which I find
highly unintelligent, unless you properly set up a 'stop at stage' limit -
and if you have more staging to perform after parachute deployment, you
can't have it both ways.

Like gmcnew said before though, how is MechJeb supposed to know when you
want the parachutes deployed? In my opinion, unless they're mixed in with
components that MJ will trigger at a known, predictable moment, they should
not be auto-staged until necessary to activate other engines, if at all.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/74#issuecomment-17059502
.

Disclaimer:
By sending an email to ANY of my addresses you are agreeing that:

1. I am by definition, "the intended recipient"
2. All information in the email is mine to do with as I see fit and
   make such financial profit, political mileage, or good joke as it
   lends itself to. In particular, I may quote it where I please.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality
   that may be included on your message.

You might want to stage parachutes opening even if you do have engines, and you may want to design your craft so that you first slow down with a parachute, then cut that loose and activate some landing engines. The only solution as I see it is a proper "stop at stage X" setting prior to launch and a craft staging setup that doesn't require automated staging during reentry.

For context, here's the current staging algorithm, simplified:

1 if staging won't drop an active engine/tank:
2     if staging will drop a deactivated engine/tank
3         ... or staging doesn't involve a decoupler:
4         stage()

Definitions:

• active engine: an engine that's enabled and hasn't flamed out
• active tank: a tank containing at least one burned resource
• burned resource: a resource that could be used by at least one enabled engine (even if that engine is not active)

Note that an active engine must be enabled, but not all enabled engines are active (since resources may not be available). An engine is not enabled if it's in a stage that hasn't been activated yet.

Issue 1 is explained by the "burned resource" definition. A tank with liquid fuel and no oxidizer will be kept, since it has at least one resource that at least one enabled engine could use, even if that engine is not active, and even if fuel can't flow from the tank to that engine.

Issue 2 is explained by line 2 above. A non-functional stage would satisfy line 1 (no active engine/tank is dropped), but not line 2 (a deactivated engine/tank is dropped).

Issue 3 is explained by lines 1, 2 and 3. A stage containing deactivated engines/tanks will be dropped (and parachutes in the next stage activated) even if there are no additional engines/tanks in the next stage.

Yes, ok, I do agree with mechjeb not being able to intuit every possible staging combination. At the same time, I don't think it should stage forward unless it has good reason to do so. I'm working on what I think the logic should be.

These are the changes I think will improve this:

• "valid" tag. Applied to engines that are capable of burning fuel even if not enabled yet, and fuel tanks that can supply to any "valid" engine.
  • All "active" items are "valid"
  • Not all "valid" items are "active"
  • An empty fuel tank can still count as valid if it is, in turn supplied with fuel.
  • Example: Rocket, empty tank, full tank, pod. All tanks in this scenario are "active".
• "Active" tag is applied to any engine that is currently enabled and "valid", as well as any "valid" tanks that supply "active" engines.
  • Engine loses "active" tag if:
  • It lacks a supply of a required resource.
  • It is deactivated for whatever reason (context GUI, etc...). This can also cause tanks to lose their "active" flags.

Loop

IF stage# > stagestop#
    IF tank loses "active" tag OR engine loses "active" tag
        IF all items to be dropped are -NOT- "valid"
            WAIT: "prestage delay"
            !!STAGE!!
            WAIT: "poststage delay"
    IF no current "active" engine exists
        IF "valid" engines exist in other stages
            WAIT: "prestage delay"
            !!STAGE!!
            WAIT: "poststage delay"

END loop

Here's another odd case I just ran into.

My most recent super-heavy launch vehicle design drops its last pair of boosters during the circularization burn, putting them in a stable orbit of about 100km by 400km. I decided to add a MechJeb unit, a probe core, and either a RT-10 SRB as a retrorocket, or a FL-T400 fuel tank inaccessible to the engine so it would be retained and could later be transferred into the main tank, so that these boosters can be "legitimately" deorbited. Unfortunately, either configuration causes MechJeb to refuse to stage those boosters.

While pondering the situation I had another thought for a way to get around this dilemma. Could a toggle option be added that changes the logic for determining if a "burned resource" is present so that instead of "a resource that could be used by at least one enabled engine (even if that engine is not active)", it only considers resources used by active engines which actually have access to that fuel? Something like "Allow unusable fuel dump" perhaps? This would at least partially solve the issue with unbalanced fuel components as well (for cases where the tank isn't connected by fuel lines to still-active engines), while preserving the existing conservative behavior unless the user enabled the option. For example, even if this option was turned on, @Aquilux's example spaceplane would not drop the tanks. But the soviet pack's Energia boosters with the useless excess of oxidizer would be jettisoned upon flameout, and the boosters of the SHLV I just described (in either form) should get tossed as well, since the small fuel tanks would not be accessible to any active engines and the SRBs wouldn't be active to begin with.

Another possibility is to have a setting with three staging modes: The classic / conservative "All Fuel Depleted", the "Accessible Fuel Depleted" I just described, and "On Engine Shutdown" like what I originally tried to describe - that is: Behave like classic if no enabled engines are present on the stage to be decoupled (as in drop tanks); otherwise, if all enabled engines have flamed out, drop the stage regardless of remaining fuel. These three options would cover all the use cases I can think of for issue 1, without forcing non-default behavior on anyone who didn't want or require it.

Ah, you just reminded me of some logic I forgot to include in my suggestion. It's also a toggle, and has to do with situations like the ones that occur with the Energia boosters. With it off, it works like I wrote above, with it on it'll dump a stage that still has valid fuel tanks, but only if the stage does not have the required resources to use what's left.

Another way to put it.

On a spaceplane that has jet fuel, just a little oxidiser, and liquid boosters (fuel/ox correct mix) to be dropped:

Jet flight burns fuel off of booster tanks, leaving imbalance. Rockets ignite to take spaceplane into orbit, drawing off of imbalanced tanks. Part way through burn, fuel on boosters goes dry, but oxidiser is left.

With toggle off: rockets continue burn, drawing off of external oxidiser and internal excess fuel, until oxidiser is gone and boosters are dumped.

With toggle on: Boosters are dumped , wasting unspent oxidiser. Main rocket continues to burn, but quickly uses up limited internal oxidiser. Left in suborbital flight, best case. Stranded in orbit, worst case.

We can't assume to know which one will be best for everyone. But if we leave the option there, we can leave the choice to the user on a case by case basis.

Definetely want to sign the issue regarding auto-deployment of parachutes resulting in the craft unable to aerobrake because of the chutes deploying. Please fix that issue ASAP, MechJeb should not stage anything after the last active engine as those stages are commonly used for parachutes or lifting assist mechanics. (Like sepratrons pointing upwards to provide lift)