[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread

[fatbrother]

Feature request: special support for long burns on low orbit

It is well known that best Delta-V to kinetic energy conversion is deep in gravity well. So when you try to do an escape burn, it is best to do on a low orbit.

When you have low TWR (like when you run a heavy ship with nuclear engines or not so heavy ship with electrical ones), time of the burn can be comparable to orbital period. I have seen posts of the people complaining on this, and the advice was to raise the orbit or make it more elliptical. But this is a loss of Delta-V.

Also, in this case, most of the burn ship is accelerating on high angle to its velocity vector. This is also a loss of delta-V. Optimal (in terms of DV to energy conversion) acceleration would be parallel to current velocity vector, like when you do a gravity turn on ascend.

Can we have a special mode for low orbit low TWR burns? I see two possible ways to implement this:

1. Split a maneuver node to several nodes placed along the trajectory.

2. A special "gravity-turn-like" mode of node execution, manually selectable or automatically engaged when burn time is > 10% of orbital period.

[MainSailor]

dtoxic : nope. I could add something do disable it and have only one global config. I ll need to look into the impact.

That actually begs an interesting question, what does, say, the Ascent Guidance use as it's defaults? Unnamed Spacecraft's config? I think it's odd that it seems like new vessels bounce around between a default config and last used.

[sarbian]

MJ has 4 source of config and for each module field we can set up where it's saved/loaded.

If a field is set to use all 3 config level then they load with this order of priority :

- the vessel config itself (in your savegame for that ship). Only present after you flew the ship once. It's the local config.

- The config file named after the vessel (in mechjeb subfolder). It lets you have a base config when you launch a new ship that share a name (and most likly a design) with a saved one. It's the type config.

- The global MJ config. (in mechjeb subfolder).

- The code default

For Ascent Guidance the config is saved in Type and Global. Which makes sense since ship that share a name most likely share and ascent profile, and since you just launched them they don't have any config in the savegame.

[Tahib]

Smart A.S.S - Surf - Sun does not always do what it should.

It seems that it points the vessel to the center of the ellipse, not to the sun directly when in Kerbol SOI. With limited solar panel efficiency, its crucial to point directly to Kerbol itself. Surf-Surf-Hdg:90,Pit:-90 works better while in Kerbol SOI.

[sarbian]

That remind me that I need to redo that code since I found a better way since. That should fix the bug.

Later today if I find the time, later this week if not.

[sarbian]

And it's fixed in dev.

[kholmar]

quick question, I follow your jenkins dev build page and stay right up to date with those.

on a normal day, all I need to replace is the .dll file which is why you offer it as a separate download...right?

or do you often make changes to the other files?

how would I know?

thanks!

Bill

[sarbian]

99% of the time only the dll changes. But from time to time we have to add a new file and there is no clear way of seeing it unless you look at github commit.

[kholmar]

99% of the time only the dll changes. But from time to time we have to add a new file and there is no clear way of seeing it unless you look at github commit.

very good, thank you!

[steve_v]

As much as I hate complaining, this has come to the point where it's really killing my enjoyment of the game.

MJ appears to have a significant performance impact.

I have been testing with a stock 0.25 +MJ (current dev build) install, stock 'albatross' craft rolling down the runway. No control input whatsoever.

GNU/Linux, both 32 & 64 bit builds.

Having a MechJeb module on any craft is causing regular lag spikes, both in framerate, and more importantly in physics rate.

This is most noticeable as a regular 'flicker' of the game clock into the yellow, with an otherwise good framerate (100+FPS), camera rotation also 'hitches' at these intervals.

This occurs with no mechjeb windows open, becomes worse as soon as _any_ MechJeb window is displayed, including the menu.

I have not found a way to log the physics rate but here are some graphs of the frametime, it's not as clear but certainly shows some impact.

Without MJ:

With MJ:

Logs are clean.

Any ideas what's causing this, or what I can do to alleviate it?

Are windows users seeing this too?

Edited November 20, 2014 by steve_v

[CatastrophicFailure]

Pix no worky. And for the record, win 7 & 8 I've always gotten a noticible lag with MJ windows open. Just accepted it as price of admission.

[steve_v]

Irritating, work for me. Re-hosted, better?

Low frame rates I can deal with, It's the 'stutter' for want of a better term that's driving me nuts, even on very low part count vessels.

This lags on rails warp too, everything freezes for a fraction of a second every few seconds. Camera movement stops, input is ignored etc. makes it a real pain to fly.

Remove MJ and viola, smooth framerates scaling as expected with part count.

I usualy run with ~40 other mods, including some computationaly expensive plugins (FAR, KER & trajectories spring to mind), nothing else has this effect. Some do drop the framerate a bit, but it's a constant hit across the board - not this 'everything stops while MJ does it's stuff'. There's got to be something more to this.

I dont have to have a window open - it's just worse if I do, besides, I don't believe just drawing a static window to the screen should be more of a performance killer than for eg. an aerodynamic simulation...

Edited November 20, 2014 by steve_v

[xytovl]

I have also noticed the stutter effect, but I have been unable to get the profiler to work http://forum.kerbalspaceprogram.com/threads/73586-Profiling-Debugging-Support-For-KSP-Plugins-%2822-Aug-Unity-4-5%29

It collects data, but then emveepee or mprof-decoder fail to read it with plenty of "Exception: ApplicationName='/usr/bin/nm', CommandLine='-n /dev/dri/card0', CurrentDirectory='', Native error= Out of memory" errors.

If anyone has useful traces I can try to analyze them, I think the .mprof file described in the ksp-devtools thread can be copied. It would help a lot to get that info and see where time is spent.

[steve_v]

Yeah, I never managed to get profiling working either

I'll try again over the weekend, though I generally know my way around compilers and libraries my experience with mono / C# is practically nill, so I probably won't know what I'm looking at.

Nevertheless, I shall attempt to get you a trace...

Edited November 20, 2014 by steve_v

[steve_v]

OK, so I have a trace, and I have emveepee opening it okay too (had to pass --runtime=v4.0 to mono to get emveepee to run)

But, as I suspected, It doesn't mean much to me.

Actually, there doesn't appear to be much information in it at all, but you may see different. Or I may be missing something .

Do I need to build MJ with debug symbols (or the C# equivalent) to get usefull data?

Edited November 20, 2014 by steve_v

[sarbian]

I had the profiler to work since I was more or less one of the beta tester, and I also used an other tool made by Faark. At the time I fixed a CPU bug that was easy to spot.

I have a few ideas about the problem origin, but I m not sure I can fix them easily. ATM I m pretty sure the spikes comes from the garbage collector, which would means that MJ create far too much short lived object. There is also a problem related to the mono version used by KSP and "foreach" use, but this one should not manisfest when MJ is built with VS or a recent Mono (as the jenkins server does).

An other problem could come from the dV sim, but it does not run all the time.

I ll look at your trace later from home since dropxbox is blocked at work. The profiler can be useful, but it does show an average picture and spike are lost in the average data. I need to find a new way to trace those, maybe with a new version of Faark tool

[steve_v]

My bet's on garbage collection TBH, it's awfull regular & about the right intervals (yes, I've been playing with GCMonitor).

Now, If I can just get the profiler set up for 64bit I might be able to see which of the _other_ mods I'm running on my main install are contributing...

The more mods installed (AKA lower framerate in general) the worse this gets but MJ is the only one that has a noticeable impact alone, and certainly appears to be the biggest culprit overall.

Edited November 20, 2014 by steve_v

[sarbian]

I could easily add some code in MechjebCore to track down which Module create the more garbage. I ll bet on VesselState ATM

[Vlos]

Feature request: automatic show/hide windows.

Docking autopilot when docking port is target, node editor in map view, rendezvous autopilot when vessel is target...

(and my english is so bad (google translator too)...)

[xytovl]

Garbage collector seems to be a good suspect, but there are some other functions we could check.

From the profiler traces, I see that MuMech.MechJebModuleMenu.WindowGUI is at 1.05% of total time, and especially System.Linq.QuickSort (0.57% for the sort, of which 0.52% in the DisplayOrder Compare method).

It is unlikely that it causes stuttering as it is a flat cost for every frame but we can improve it.

The next hot point is the VesselState.Update at 0.75% (the whole fixedUpdate is 0.80%). Inside VesselUpdate, AnalyzeParts is at 0.43%, UpdateMoIAndAngularMom at 0,20% and UpdateBasicInfo at 0,1%

Same comment regarding stuttering.

I'll see if I can make any improvement and submit them.

[sarbian]

The display order could be stored in a cache. It would need to be cleared when custom windows are added/removed.

As for VesselUpdate I m not surprised at all, it's here that most of the complex stuff is done.

I'll look more into the memory stuff.

[Somtaaw]

I'm sure this has been asked before, but I can't seem to find it in thread so I'll ask anyways.

While using Blizzy's toolbar, Mechjeb icon is not disappearing from the stock applauncher/toolbar, and the icon stays on the right side of screen. Is this intended, or did I mess up a file somewhere so it's not properly migrating off the stock toolbar to blizzys.

To clarify slightly further, MJ is sitting on blizzy toolbar, and works when I click anything I want from there, Im just wondering why the other icons are not disappearing like other mods do when placed onto the blizzy toolbar.

[hazens1]

I'm sure this has been asked before, but I can't seem to find it in thread so I'll ask anyways.

While using Blizzy's toolbar, Mechjeb icon is not disappearing from the stock applauncher/toolbar, and the icon stays on the right side of screen. Is this intended, or did I mess up a file somewhere so it's not properly migrating off the stock toolbar to blizzys.

To clarify slightly further, MJ is sitting on blizzy toolbar, and works when I click anything I want from there, Im just wondering why the other icons are not disappearing like other mods do when placed onto the blizzy toolbar.

There is an option in the MechJeb settings for this to remove the standard toolbar button.

[vpeonix0407]

I'm wondering if someone can help me.

I currently have 2 ships in orbit around Eve.

I want them to rendezvous with each other but for some reason the change inclination function on Mech Jeb 2.4 isn't working properly, at least not in this instant.

It appears to set up the node properly (with the predicted orbit as required), but the ship ends up facing in the wrong direction (usually away from Eve) and my ship ends up falling out of orbit.

No other Mech Jeb function has this problem and it is doing this with both ships.

It doesn't matter if I use "Change inclination" "Match planes with target" or "Rendezvous Autopilot".

I started a sandbox game, launched a ship into Kerbal orbit, went to change inclinations and it worked fine.

So either I did something wrong with both of these ships or there is something wrong with Mech Jeb in relation to Eve.

Can anybody help me?

[Eleven]

I'm wondering if someone can help me.

I currently have 2 ships in orbit around Eve.

I want them to rendezvous with each other but for some reason the change inclination function on Mech Jeb 2.4 isn't working properly, at least not in this instant.

It appears to set up the node properly (with the predicted orbit as required), but the ship ends up facing in the wrong direction (usually away from Eve) and my ship ends up falling out of orbit.

No other Mech Jeb function has this problem and it is doing this with both ships.

It doesn't matter if I use "Change inclination" "Match planes with target" or "Rendezvous Autopilot".

I started a sandbox game, launched a ship into Kerbal orbit, went to change inclinations and it worked fine.

So either I did something wrong with both of these ships or there is something wrong with Mech Jeb in relation to Eve.

Can anybody help me?

First and easiest guess would be that one vessel is not being controlled from the correct aspect....you know, it's being controlled from a part that has it oriented incorrectly to do what you want. Check each one and see that 'control from here' is where it should be