With that #24 closed, would it at least be possible to make ascent AP able to ascent to non-circular orbits? Besides the general usefullness (I have circular orbits in KSP as they tend to jump back and forth in map view), this would allow me to get to like -10x100 orbit and get rid of ascent stage safely.

Thank you!

Much of the issue with auto-staging in both MJ1 and MJ2 is because the module does not allow any delay in staging after the current stage engines shut down. This is only exasperated by the MJ1 and sometimes MJ2 issue with zero decoupler force, but it is also a useful tool for launches when a slight delay before staging activates can be useful. Whether it be forced or selectable, there should be at least a 0.1-0.5 second delay prior to staging to allow the now expended stage to "settle" so that there is no odd stresses on the decoupler that can cause collisions with adjacent stages as occurs with the current auto staging behavior.

All autopilots doesn't play nice with vessels with unbalanced RCS, which translates vessel along with rotation due to this umbalance and/or glitchy physics - namely BobCat's Buran. It tries to pull out last <0.5m/s of maneuver forever as rotation induces translations, and so chasing down node direction causes this direction to change, it keeps trying to get perfect forever and ignores the fact that maneuver is long missed and it's no longer productive and even counterproductive to keep pursuing it (for example for plane alignments, once you fly away from planes intersection, no amount of thrust applied anywhere will fix the situation, the only way is to wait for next intersection). So there needs to be a way to setup a precision threshold to prevent this from happening - besides there is absolutely no need to be perfectly aligned, difference of <0.02° can be simply ignored.

Why did MJ2 drop to one decimal place on most readouts? Would it take much more space to add another couple digits? If most users are fine with low-precision information, could the number of digits be made a configuration option? Either globally for all info, or (perhaps too messy) per display.

When attaching fuel via an external tank with a radial coupler, Mechjeb doesn't recognize that stage's deltaV. The previous version did this correctly for each stage. Here's what I mean:

Upon executing a maneuver node, until the node is finished, editing or adding additional maneuver nodes, even years in advance, causes the current maneuver node's deltaV-remaining meter to return to 100%. This could cause an inattentive user (what you would expect if they are tuning future nodes) to way overburn.

Well, basically title says it all. I try to keep my space clean of debris, so often I'm forced to abort ascent AP sequence to make sure my ascent stage reenters. It would be great to have such an option in the autopilot itself, ideally with configurable periapsis at which stage is to be gotten rid of.

Thank you got considering this, and for the great work you do for all of us!

Would it be possible to program the ascent manager, so it knows how much atmospheric drag it will recieve while coasting to space, so MechJeb fires for a higher apoapsis, that get's lowered to the correct level by the atmosphere?

Around 7-8k Feet with any of my 7 engine craft (example linked below) it starts to slowly wobble into a complete loss of control. MJ 1 did not do this, and the craft is atleast well enough balanced for me to handfly without any issue. (not sure how to attach craft file)

This might be a bit too complex (what with staging and all the changing variables like CoM) but I think it would be really neat if MechJeb could automatically tune the PID parameters (in flight) based on the observed steering errors.

I wouldn't even dare call myself an amateur in controllers as I barely know anything about them other than their function, but he tuning sequence could look something like this:

1. Minimize ocillations
2. Minimize overshoot
3. Minimize settle time

The changing variables might be accounted for (post-tuning) by a user-specified error threshold. If the average % of steering errors (post-tuning) has exceeded the threshold, MechJeb could reinitialize the tuning process.

Maybe MechJeb could even predict the change in CoM by counting the parts, their mass and drymass, calculating the CoM and predicting how it will change based on fuel consumption / staging.

http://support.motioneng.com/downloads-notes/tuning/pid_overshoot.htm

You can see the issue on this craft: https://dl.dropboxusercontent.com/u/8244638/Fueler%205b.craft

When I select both "Manage air intakes" and "Prevent jet flameout" (the latter of which is a godsend BTW, probably my favorite new feature!), it seems to be getting confused and closing too many of the intakes. Not sure what could be causing this, but I haven't looked much at the relevant section of code yet. It might be getting confused with the nested-symmetry construction of my craft, KSP itself can get confused in the VAB with removing or setting action groups for parts attached this way...

With all but 2 intakes closed, the linked craft can't generate enough thrust to get off the ground. If I turn "Manage air intakes" off, it takes off fine as long as I wait until the engines are spooled up to > 90 kN before releasing the launch clamps. It does exhibit some control issues due to #21, Tallinu's workaround is effective for that problem though.

Edit: deleted side question (duplicate of #55), added the following
Feature request! New info item for total number of open intakes. Gets hard to figure out the total # open once you get higher and the time between successive openings decreases.

Things like inclination, orbital period, Ap/Pe - basically whatever was displayed on 1.9.x when you select the target.

You're probably aware of this already, hope you don't mind me posting it here for tracking. Delta-V expended and Current acceleration give incorrect values for jet engines.

All thrust calculations in MJ for jet engines are currently ignoring the velocityCurve's effect on max thrust. VesselState.ThrustAccel should really be a function of surface speed if there are any active airbreathing engines on the craft.

There's also a transient error due to the throttle spool lag. This would probably require querying the engines for their current thrust to fix.

During ascents and node execution, it can make sense sometimes to have MechJeb control attitude but manually control throttle. The closest approximation for that now is typing numbers in the "Limit throttle to %" box. The other places MJ controls throttle that I can think of are Translatron and Landing, for which manual throttle overrides are a bit less likely.

Likewise I don't always want MechJeb to time warp for nodes or landing (where else does it control warp? obviously the warp helper, overrides aren't meaningful there). I have some super-light ships with Kerbals hanging on to ladders, so standard time warp isn't allowed. If MechJeb weren't constantly trying to get into time warp though, I would be able to manually do physical time warp (alt-.) up to 4x.

Normally I'd pose this question on the forums, but... yea.

At the risk of looking like a complete noob at C# and Visual Studio (I am), could anyone give a set of step by step instructions on getting the source loaded correctly into a VS project and built?

I tried to do it myself and while VS finally reported no errors and I built a release branch mechjeb2.dll file based on the current dev branch source, copying that over the existing plugin dll resulted in mechjeb2 not showing up in-game at all. The parts were there, but they weren't loading the plugin.

Not at all sure what I'm doing wrong. I followed as much of the directions at http://wiki.kerbalspaceprogram.com/wiki/Creating_your_first_module as seemed to apply.

My ultimate goal is to get a Jenkins build system going but I want to understand C# and VS project files first. I have a decent amount of experience with Java coding and Jenkins for building those but nothing with C# and VS.

Dear reader,

I'd like to mention that, when using Rendezvous Autopilot, whenever you're pointing more than 10 Degrees away from the node while Autowarping to Hohmann Transfer Node it stops a million times to get the marker exactly right. This annoys me very much because this increases the huge amount of time (real time) by another 10%. Why doesn't he just warp to 10 minutes before the node, corrects, warps to node, corrects again and executes manoeuvre? This would decrease the time it would take to get to the node vastly.

Yours faithfully,

MmPMSFmM

Jeb takes the stick too eagerly, losing normalSAS contribution.
Need a configurable multiplier to the precision variable on line 267 of MechJebModuleAttitudeController.cs

If you (accidentally) create some double entry in Custom Window you can't select it. Both of them will be selected, but the buttons ("remove", "move up", "move down") control only the upper entry. So it makes impossible to delete accidentally created entry at the bottom.

It would be cool for the main mechjeb menu to display which MechJeb module is in control. The little square is shaded when the module is open, but maybe make it green or red to indicate if it is in primary (or secondary/auto) control.

The Smart A.S.S. module tends to remain in auto mode when:

1. You press abort on something like ascent guidance, or maneuver planner.
   Example: Use maneuver planner to create a node, and execute it. Before the system is finished, pressing abort on the planner does not bring back Smart A.S.S. buttons with the system still trying to orientate to node. Note: Manually deleting the node brings back Smart A.S.S. and stops the system from auto orientating.
2. You press "Off" on the Smart A.S.S. module itself. Example: Use the prograde button to align ship prograde, then press off. Instead of turning off the guidance, prograde guidance stays on, and the Smart A.S.S. module goes to "Auto mode."

Tested in KSP .19.1 with Romfarer plugin from Bobcat's Soviet Pack.

http://i.imgur.com/U6nvrOa.jpg

UI does this on every launch now, it used to do it sometimes when i was flying up to a ship that had an ISAmapsat on, but i've uninstalled that and now it just does it on every launch, can hardlies see most of the UI now to play.

This feature would be very useful for reentries with Deadly Reentry installed. Also for space shuttles.

When i reenter the atmosphere of a planet the game freezes and won't react to any input.
I've been searching all over the web but i haven't found any answers.

I don't get a crash log.

This only happens when i have mecjeb on the ship or a debris.

Sorry for bad english.

... which then means it can't dock

When >1 MuMechModuleHullCameraZoom are attached to a ship, any camera not the first one will not be able to zoom.

With the upcoming addition of re-entry heating effects, as well as the presence of mods that add this functionality now, I think we should be able to manually set our reentry path. I see something similar to the assent curve editor, where you could set the entry angle and see the projected path to target.

You could do a number of things to expand on this window, such as:

Varying the color of the line from blue to red dependent on g-force (as a reliable predictor of heating).

Use an orange/yellow border line of varied thickness to indicate estimated burn during a powered descent.

Display estimated remaining delta-V for each descent milestone on the line (end of de-orbit burn, end of course corrections, end of descent burn, touchdown)

Display countdown to major events on the line (start of each burn, touchdown)

Add toggle to designate either a powered or unpowered re-entry.

Add a slider to adjust mech jeb's priority during a powered descent between efficiency and accuracy (prioritised to efficiency = suicide burn).

Add fields so that we can have mechjeb autostage to a set stage upon reaching a set altitude

Predict the reentry path while accounting for the changes of drag and mass that occur because of said events.

Calculate impact speed (useful for unpowered reentry, as well as when using parachutes and low t/w engines)

Grey out all inputs after a decent has been started, but keep updating the screen live if it's open so we have an up to date monitor.

Example stock craft with similar maneuvering characteristics to many ships that MJ has problems with: https://dl.dropboxusercontent.com/u/203721/MJ%20Maneuver%20Example.craft

To illustrate one of the biggest problems with MechJeb's steering (after launching, of course - path 0, 50, 0, 75% always works well):

Set SmartASS to Surf, heading 90, pitch 0 and execute.
Wait for ship to stabilize, and roll so that ship is level with horizon.
Leave RCS off, or disable it now.
Change Surf to heading 270, pitch -45 and execute.

Expected behavior: Simple (albeit slow) pitch down maneuver, rotating the ship through a 135 degree arc around the pitch axis. (Pitch control should reverse after traversing 67.5 degrees to avoid overshooting.)

Actual result: Pitch up and yaw left or right, combined with about 45 degrees roll, until target is on or near the ship's yaw plane. Continued yaw maneuver, most likely missing the target and sweeping back around in an arc, possibly overshooting several times. Total travel arc of 180 degrees or more even without counting the overshoot.

If the target orientation was a maneuver node (including automatic node execution) or "TGT +" instead of Surf, the ship tends to constantly roll left and right as well, and often starts off with a large, utterly pointless roll.

Since any two non-parallel vectors define a plane, MJ should simply be rotating the ship around the axis perpendicular to that plane. If that axis is not perfectly aligned with the ship's pitch or yaw axes, that shouldn't be a big deal either. The angle difference between that axis and the yaw or pitch axis, fed into the Sin and/or Cos functions, should be able to provide the appropriate yaw and pitch ratio. Scale both up proportionally so that the larger of the two reaches the max steering signal.

Then it's just a matter of getting it to quit overshooting the target heading by up to 90 degrees. Update 4/21: The moment of inertia calculations (#59) seem to be responsible for the inaccuracies leading to most steering overshoot. With the latest dev build and symmetric pod torque or enough RCS control, it can completely eliminate overshoot, so the PID controller itself is clearly working just fine in that regard.

The ascent autopilot refuses to automatically dump empty stage, maybe a problem with sepratrons.

As noted in the forum thread, the tab on the right in VAB obscures part of the staging interface.

Also, the items in that tab in VAB are very glitchy: when I move the cursor over them the big save/load/etc buttons on the top right flicker (rapidly going between active and inactive), and it can take many tries for a click to be registered. I basically have to spam-click while moving the mouse in order to show the vehicle info window. Interestingly, only the tab is so affected: the info window itself works normally.

Finally, in the normal view, a click on a window shown in the top left corner in order to drag it away also goes through to the native warp control, causing unintended warp if it happens to be in the right place. The easiest work-around could be not to create windows exactly in the corner.

Had been running into issues with the MJ2 landing autopilot, so I performed a test by bringing a simple lander to a 100k orbit, then telling it to land at KSP.

Running with MJ2, the initial deorbit and correction burns were spot on. After it auto-coasted to the next correction spot, it just got further and further off, burning up fuel I needed for braking to "correct" in the wrong direction.

Swapping out the MJ2 part for the MJ1 one (same case, same location on the same ship, same orbit, etc), the landing autopilot gently set me down on the VAB.

Can you please bring these buttons back as they were very useful in times when there is no time to enter values manually (like descent with Deadly Reentry) :)

Thank you!

The path for ascent defaults to the standard one when starting the flight instead of remembering the last one.

Autostaging also resets back to off.

I don't know why anyone would care whether the plane-change happens at the AN or the DN, so the current two options make little sense to me. I would think that it would be much more useful to have the following two options: One that selects the next plane-crossing event regardless of whether it's ascending or descending, and one that selects the highest-altitude crossing to reduce the fuel required.

"At next AN or DN"
"At highest altitude plane intersection"

(And can we get the > arrow moved over next to the < arrow in all of these menus so that it doesn't jump around and it's easier to switch directions while browsing the options?)

Land at target seems to now know when it will need to start its braking burn and auto-warps there automatically. Can the same functionality be added to "Land anywhere"? Or if the user is time warping too aggressively, needing to start the braking burn is a good reason to drop out!

I suspect this doesn't happen when you first use MechJeb in a game and happens only from the next flight. The image showing the turn shape becomes garbled. Here is what it looks like:

Issue the first:

Window persistence is...limited at best. I have a custom window made that shows me all the info I need, contains a few key engine related controls, and nothing more. Replaces about 4 or 5 seperate boxes. Problem is it doesn't persist at all. If I go to the VAB? Remake it! If I switch to a craft that lacks MJ 2.0? Remake it! If I close KSP and restart? Remake it!

Doesn't sound bad?

Remaking that every five minutes tends to get a bit annoying. It'd be much appreciated if custom window persistence can at least be maintained from KSP start to KSP close.

Issue the second:

Orbital Operations was an absolute godsend. So easy to use. Yet we don't have it anymore. Instead we have to click through the maneuver planner. It makes doing basic things a pain in the rear, instead of two clicks it's five to circularize. Can we have Orbital Ops back?

Issue the third:

The Smart-ASS menu is great, but it can't make its mind up. Sometimes it has cool buttons, sometimes it's entirely transparent aside from the text. Still works just fine either way, only a visual issue. It also doesn't tend to display "AUTO" automatically, though the autopilot does kick in.

After clicking on PANIC button you can't stop MJ from doing it's panic program. Even if you click on "don't panic". Smart A.S.S shows you only "AUTO" button and it is impossible to stop it.
After clicking on "OFF" it stops burning, but does not stop moving around.

The rendezvous autopilot is great, but just like everything of mechjeb, has OCD. The rendezvous autopilot tries to get you within 100m, and most of the time tries to get as close to 0m as possible.
This is how I just lost half my space station in orbit around kerbin, because the rendezvous autopilot tries to "park" it inside.
This is actually very dangerous for people with big space stations, as the ship WILL get closer than 50m
I'd like a change which makes it possible for people to set the minimal distance to the target.

Custom Windows created in the editor or in flight aren't saving after closing kerbal space program
Edit: As well as after ending flights and starting new ones and when switching vessel

Basically the issue is that different vessels needs different ascent path, so I have to remember to change them every time I use different ship. Would it be possible to create some sorts of system that would allow me to save several presets and switch between them. Preset had to save apoapsis and ascent path form.

Ok, something fishy is going on over there. I'm on 109x111 km orbit, my target is on 142x150, target is 217 km ahead of me. Phasing step suggests me 225x225 km phasing orbit, which clearly not needed as my current one is just perfect. So I skipped the step and went to step 3 - Hohmann transter. I've pressed the button and here is what it suggested: http://www.asmitech.com/Stuff/KSP/MJ2/MJ2_TR1.png
And this is was I think it should have suggested: http://www.asmitech.com/Stuff/KSP/MJ2/MJ2_TR2.png
Note time to maneuver (suggested 8+ hrs vs a bit less then 14 min) and dV (suggested 30.6 m/s vs 25.2 m/s).
I've skipped both first step (because I think 0.2 Rinc is small enough to press ahead with rendezvous), and second one (as mentioned above).

I've seen this bug for as long as I can remember, and yet it's consistently ignored and people are told it's been solved, yet still I see it in the latest release (2.0.4).

For some reason, no matter what force you specify in part.cfg, mechjeb's auto-staging forces it to a minimal, if not nonexistent value. This causes parts being separated to remain next to the rest of the craft, with no clearances. Any angular motion causes collisions that tend to cause catastrophic failure. Even without angular motion, accelerating away from decoupled parts can still cause collisions.

Craft: http://pastebin.com/sacDfV6B
KSP: 0.19.1.54
Mods: Clean install + mechjeb 2.0.4

Reproduction:

Load craft, enter assent autopilot, enable auto-staging, launch.

Observe: the tanks fall off with no separation other than that of the decoupler part itself.

Load craft, enter assent autoppilot, DO NOT enable auto-staging, launch.

When external tanks empty, preform manual staging.

Observe: tanks are pushed away from craft, causing a noticeable spin in this craft due to force not being directly applied to CoM of tanks.

Behavior applies no matter what parts.cfg has listed.
Behavior becomes much more obvious with higher force values.

MechJeb doesn't calculate fuel flow properly when you have a powered external tank, that refuels an adjected internal tank, that is not drained directly by engines but has an inactive engine adjected.
My spacecraft is a Space-Shuttle like spaceplane with one middle atmospheric engine, that's not used during ascent. The external tank is connected to my middle fuel tank on the spaceplane. This middle tank has circular fuel flow with the both adjected side tanks, that store an aerospike each.

This prevents the ET to be jettisoned automatically when empty

When running the options to limit acceleration and/or max throttle, mechjeb does not compensate for this when performing maneuver node burns leaving your adjustments significantly far from their intended parameters.

ie; if you limit acceleration to a value or cap the throttle at less than 100%, mechjeb starts the burn assuming you are letting it go full throttle which ends up meaning it starts the burn too late and finishes the burn much later than intended.

Forget it, I wasn't aware this feature was implemented.

This is the same as in the previous version, but there was also the other radial part which didn't have this problem. Basically, in order to get the same orientation as the command pod, you have to stick AR202 on the left side of the rocket, instead of on the front.

Controlling from a radial mechjeb part attached to the heavy lower launcher stage can be useful to reduce wobble, and putting an appropriately rotated one on a rover allows setting navball to an orientation more appropriate for driving.

Before installing MJ I would have no crashes at all, but now I get about one every half hour. I was wondering if other people had this issue or is it just my computer causing issues.

Thanks

The launch phase angle rendezvous feature in the ascent autopilot seems to have no automated equivalent this version; meanwhile, the rendezvous guidance module displays none of the useful information the old rendezvous module did, and the surface info module is no longer there by default.

Would it be possible to add toggle for an acceleration limiter (especially during ascent)? I build a lot of large/nearly-structurally-unstable launchers which get torn apart once my stage fuel levels get low and my TWR is high (they can be manually launched with careful thrust control). I realize I could just not use the auto-throttle, but what can I say, I'm lazy.