Setting pre-stage delay to zero does not remove the delay before auto-staging. In fact, any value under 1 seems to have approximately the same delay effect, on average.

Looking at the StagingController code, there appear to be one or two possible reasons for this.

First, it will not check if the countdown has expired in the same update when the countdown begins; it either starts the countdown OR checks to see if the time has expired. Assuming updates happen once per frame (correct me if I'm wrong), this is probably not of great significance, but would still impose a minimum delay of the inverse of your framerate.

Second, the comparison is ">" rather than ">=". After seeing that I paid closer attention to the timing of stages dropping off in-game... I think it may be always triggering it on the updates where the clock has just ticked from one whole second to the next? If this is correct, the delay would effectively be rounded down, and the staging would occur between zero and one seconds after the resulting time had passed, depending on when the countdown began (that is, what fraction of that second had already elapsed).

My FPS is not so low that the first item could account for the full delay, so whether the second is correct or not, there seems to be something strange going on.

Is the post stage delay set to 0 as well? I could be wrong (I'm working off of memory) but mechjeb seems to apply post stage delay to the stage that ran out.

No, but both experience in flight and analysis of the source suggest that post-stage delay works properly and has no effect on the pre-staging delay. If it's activating multiple stages in a row that's a different matter than the cases I'm referring to.

@Tallinu, I think you'll find that this is, in fact, related to the 'post' delay. I just looked into this, and the bug was that the post delay was applying to the pre delay, too. With pre and post both set to 0, staging should be instant, and it is. With pre set to 0 and post set to 5, staging should still be instant (assuming you're not activating multiple stages in quick succession), but instead you'll see that a burned-out stage will not be jettisoned for 5 seconds.

The commit above should fix this for the next release.

@Tallinu, here's a dev build that contains the 84f127e change mentioned above, if you want to test it: http://jenkins.mumech.com/job/MechJeb2/28/

Hmm, yes, this may explain some things I've been seeing as well.

Hmm, the location lastStageTime was being set made the delay happen as a lead-up to a stage rather than following it, eh? Thanks, I'll grab that build and give it another try. :)

Yeah, that definitely took care of it. Back to insta-staging for me, heh! Or maybe the 0.1 second I'd been trying to use since that feature was added.

@Tallinu, I haven't seen that problem, and I'm pretty sure I would have during my testing, but it's definitely possible that I missed something. If auto-staging is enabled, it shouldn't depend on whether the ascent autopilot is running or not. Can you give me a series of steps to perform to see this problem?

@gmcnew I think there's a new bug - MJ won't stage at all until something has been decoupled at least once with the AP active. Is lastStageTime not getting initialized?

Scratch that - two things going on: It won't decouple a tank that has ANY oxidizer left in it even if the liquid fuel is spent and there's nothing else consuming the oxidizer except the engine which can't provide thrust because of the lack of LF. And it won't decouple this nosecone even though it needs to do so in order to get to the stage containing the upper stage engine.

Apparently the LF / O ratio isn't quite right on these Energia boosters. I have no idea what's causing the nosecone issue though. I'll see if I can duplicate it with stock parts.

... so yeah, I thought that 'close' button was to close the 'new comment' form after I accidentally clicked the 'comment' button. XD

@gmcnew I've been testing this with a stock ship and I've been able to reproduce both issues, as well as another minor quirk I'd like to see go away. I'll post a couple versions of this example craft in a minute, just need to restart KSP and make sure the booster separation still works right after I fix my edited decoupler forces back to stock values. 😄 I'd had them set really high previously to test decoupler issues, and forgot to fix them once that was resolved.

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.

@Tallinu, thanks for being so thorough — do you mind moving your comment above into a new issue? I think the original issue (the auto-staging "post" delay affecting the "pre" delay, too) has been fixed, and it sounds like you're describing different bugs (which are quite similar to each other, but not necessarily to the original issue), so they should probably be tracked and discussed as a separate issue.

Oh, and on the third issue you described, could this be corrected by using the "Stop at stage #" field?

Yes, stop at stage works correctly, assuming you set it to the right number. It just seems bizarre for MJ to activate stages beyond the last set of engines, regardless.

I thought the change to fix this issue might have been responsible for breaking the second one, at least, which is why I posted these here. I'll make a new issue now - do you want that description removed from here, or just copied over?

That's reasonable. I'm pretty confident my fix for this issue is unrelated to the new ones you described, though, so thanks for creating issue #74. You can leave your comments above alone.

Err... reopening until 2.0.8 is released.

2.0.8 is now released, closing this.