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

[smjjames]

*bump*

And now I'm having that same issue with a ship section that I decoupled, switched to, deorbited that decoupled section, then switched back to the main ship, deltaV window doesn't work in the sidebar but does in blizzys toolbar. It hasn't done this behavior before.

Edit: Going to KSC and back fixes the issue apparently.

[briligg]

On Ubuntu 14 i can't get MechJeb to work.

Unzipped it into GameData.

Launched program by running KSP.x86.

There isn't any MechJeb pod or control item.

There isn't any tab on the toolbar.

I'm probably missing some simple thing, but can you help a poor noob?

[smjjames]

Do you have module manager? I'm pretty sure that it won't work without it.

Also screenshot of your GameData folder.

Anyways, can anybody tell for sure whether theres a memory leak coming from MJ while docking? Because I've been having lots of problems and crashes while trying to dock or after docking a ship from a station. I'm suspecting either MJ or Routine Mission Manager, or it may be KSP, but I can see the memory usage rise while in Taskmanager.

At least 1.0 will remove most of KSPs memory leaks (hopefully), so memory leaks coming from mods will be more easily spotted.

[Red Iron Crown]

Do you have module manager? I'm pretty sure that it won't work without it.

Fairly sure that's not the case, MechJeb is a standalone mod with no dependencies.

[smjjames]

Fairly sure that's not the case, MechJeb is a standalone mod with no dependencies.

I thought it did? Maybe not I guess.

What about the memory leak bit? I'm trying to find where the hell it's coming from, my only tool is looking at the memory usage in Taskmanager.

Edited April 16, 2015 by smjjames

[GraviTykillz]

I have never had Mj dock for me successfully.

MJ did however teach me how to land. and i still like using it to calculate transfers and such

[smjjames]

I have never had Mj dock for me successfully.

MJ did however teach me how to land. and i still like using it to calculate transfers and such

Balancing your RCS helps though and goes a long way, and yeah the docking AP doesn't always quite work, have to fiddle around with the options.

[briligg]

Re: MechJeb not working in Ubuntu 14

[smjjames]

Your link is broken.

[Threadsinger]

I have never had Mj dock for me successfully.

MJ did however teach me how to land. and i still like using it to calculate transfers and such

Balancing your RCS helps though and goes a long way, and yeah the docking AP doesn't always quite work, have to fiddle around with the options.

[smjjames]

I swear that there is a memory leak coming from MJ while using docking AP, can anybody else confirm this? While using it near a station (maneuvering a large ship), I'm seeing the memory usage rising fast, often in spurts.

Edit: Okay, I have docking AP off and it's still rising fast while it's off, ARG WHERE THE HELL IS THIS MEMORY LEAK COMING FROM!

Edit2: Okay, it's looking like it's coming from actiongroups extended, somehow.

Edited April 16, 2015 by smjjames

[sarbian]

briligg : writing it is not working wont solve anything. You need to give me logs and more info.

Post your Logs somewhere

Go to your KSP install dir and do a

find . -ls >ksp_install.txt

And post the ksp_install.txt file somewhere.

[Ethanadams]

The mech jeb capsule eye looks like a portal curupted core

[SpaceJuice]

No, but it does look like a portal space core...

Edited April 16, 2015 by Spacejuice

[smjjames]

This might not be new, but just noticing that the docking AP has redundant 'no docking port selected' warnings, I think one would be enough. I think one of them is actually a 'no docking port exists on vessel' warning though.

Edit: Also, that redundant message didn't appear on earlier crafts which did have a docking port, but the port just wasn't selected. Having the grabber may or may not have something to do with it.

Edited April 16, 2015 by smjjames

[SpacedInvader]

So, about a year ago I came here looking for a little help trying to figure out an issue with RCS overuse / control with Mechjeb and after an absence from the game, I'm back again with the same problem. The problem manifests itself when using only RCS to control vehicle orientation, wherein it will turn to the appropriate direction and then sit there blasting RCS fuel out of all of it's thrusters indefinitely until either RCS is turned off (leading to the vehicle drifting off of the desired orientation), or time warp is engaged.

I've come to the general conclusion that the issue rests somewhere in the interaction between Mechjeb, Real Fuels, and ModuleRCSFX, as the latter two both affect the general characteristics of the RCS thrusters. That being said, I'm at a total loss as to how to get around the issue. Yesterday, I spent about 2 hours tweaking the settings in the attitude adjustment page while trying to follow this guide, and, while I was able to significantly reduce the amount of overusage, I've been unable to completely stop it and the changes seem to have introduced the new issue of Mechjeb constantly overshooting the desired orientation (by a little or a lot depending on the situation) and oscillating back and forth slowly. Noticing some mentions of RCS adjustments, I've also upgraded to the newest stable dev build, which seems to have helped a little, but still leaves my craft oscillating in space if I try to use only RCS to control their attitude.

Is there some trick that I'm not getting here? I've tried searching for guidance on this several times now and it seems as if I'm pretty much the only person who's had this issue as the only search results I've been able to find are my own previous posts on the subject and that guide which seems to give rather outdated information about how to edit the values on the attitude adjustment page. Anyway, I really hope someone out there can help me resolve this as it's quite frustrating to watch all your precious RCS fuel get blown out into space just because you wanted a little help from Mechjeb holding an attitude.

Thanks.

[Nansuchao]

I don't know if this is a know issue, but while using MJ for interplanetary burn, it happens, not ever, that is seems you would intercept the target SOI, but in fact you will not.

[smjjames]

What TWR is the stage that you're using for the burn? The only times that I run into that issue is during longer burns due to the stage having a low TWR.

It can also happen due to the floating point error. You should make a correction burn about halfway anyhow.

[sarbian]

SpacedInvader : which version of MJ are you using ? There was some change in the dev release that impact RCS use.

Nansuchao : it is not floating point error but burn length that add some error. Best I can offer is to use the "adjust closest encounter" tool after the initial burn to correct the trajectory.

[Nansuchao]

What TWR is the stage that you're using for the burn? The only times that I run into that issue is during longer burns due to the stage having a low TWR.

It can also happen due to the floating point error. You should make a correction burn about halfway anyhow.

Random from 0.40 to 0.65 for far planet. Usually I make a little correction just over the SOI I'm escaping. So that's the problem? KSP shows wrong trajectories for heavy ships?

[SpacedInvader]

SpacedInvader : which version of MJ are you using ? There was some change in the dev release that impact RCS use.

I'm currently on the #429 (latest stable build) dev build. As I noted, switching to this build from the release build seems to have improved the situation slightly, but it still remains even after a lot of tweaking.

[futrtrubl]

Random from 0.40 to 0.65 for far planet. Usually I make a little correction just over the SOI I'm escaping. So that's the problem? KSP shows wrong trajectories for heavy ships?

No, it's that for ships with low TWR you end up on the wrong trajectory. KSP and MJ assume that maneuvers are instant, it's too hard to compute them otherwise. So the less instant they are (ie the longer they take) the more wrong they become. For lower TWR ships it is usually best to get onto a higher circular orbit before calculating your transfer burn, for accuracy. It is still usually more efficient to do your burn low and then correct once you get into the Sun's SoI. With very long burns however you may be so far off that MJ can't figure out a good correction.

[Nansuchao]

Ok thanks. I was trying it with some expensive burns to Eloo or Moho, cause I figured MJ make me spend less Delta/V. So it's not an issue with MJ, just with my ships...

[futrtrubl]

You can also use KSP Trajectory Optimization Tool to split a burn into multiple smaller burns if you have enough lead time before you have your transfer.

[smjjames]

No, it's that for ships with low TWR you end up on the wrong trajectory. KSP and MJ assume that maneuvers are instant, it's too hard to compute them otherwise. So the less instant they are (ie the longer they take) the more wrong they become. For lower TWR ships it is usually best to get onto a higher circular orbit before calculating your transfer burn, for accuracy. It is still usually more efficient to do your burn low and then correct once you get into the Sun's SoI. With very long burns however you may be so far off that MJ can't figure out a good correction.

That's usually compensated by splitting the burn in half and doing it on both sides of the node.