SpacedInvader

I consider 0.1 to be the highest tolerance because it is the most restrictive. Anything less restrictive (0.7 or 3 from my examples above) is a lower tolerance because it's easier to achieve. If I set the tolerance right now to 0.1 m/s, the maneuver node will start to move up towards "Radial +" at about 2-3 m/s left on the node, and then will never get lower than 0.2 m/s, leaving MJ to burn fuel radially until there is no fuel left to burn. EDIT: I just put together a little imgur album to show exactly what happens when I try to use 0.1m/s tolerance currently: As you can see, everything is fine until MJ gets to the end of the burn, at which time the node slides up and pegs itself on Radial+ with 0.2m/s left on the node. MJ will continue to burn like this until there is no more fuel left. This behavior is the same across all of the craft that I've tried to use since this problem has cropped up.

So this inability to successfully execute maneuver nodes with MechJeb is really starting to frustrate me. I've reduced the node tolerance down to 0.7m/s which is better, but still permits the vehicles to turn in pursuit of the maneuver node before shutting off. In order to prevent any wild chasing of the maneuver nodes, I have to reduce the tolerance down to 2-3 m/s. While both settings are better than the alternative of MJ simply burning endlessly until it's either out of fuel or crashed, this doesn't explain any sort of why this is happening. Something has changed in the last couple of days and I've been unable to determine what it is and how to fix it correctly. I know for a fact that something has changed because vehicles which used to perform just fine with a tolerance of 0.1 must now have their tolerances reduced to the previously mentioned 0.7 or even higher. In response to what Sarbian said about larger ships needing a less restrictive tolerance, I have the following two pictures: As you can see, neither of these is what I could consider a large ship, clocking in at under 10t, and yet both need relatively low tolerances for dV (the latter has been to the mun 4 times with a tolerance of 0.1m/s and yet now it wasn't even working correctly with the 0.5m/s of tolerance seen in that picture) despite their small sizes. I should also mention that in both cases, attempts to achieve specific orbits were often as much as 2-5 km off where in the past MJ had been able to produce nearly perfect orbits. I don't think that MechJeb is to blame here, as I've completely uninstalled / reinstalled the addon several times, and have tested it alone on a stock installation and it's worked just fine. That being said, I'm at a complete and total loss as to what else might be affecting it's ability to properly execute maneuver nodes. Here is a list of my installed mods: 000_Toolbar 000_USITools AIES_Aerospace AJE AnimatedDecouplers ArcanumIndustries ART ASET B9_Aerospace BackgroundProcessing-0.4.0.1.dll blackheart Chatterer CIT CMES CoherentContracts CommunityResourcePack CommunityTechTree ConnectedLivingSpace Contract_science_modifier ContractConfigurator ContractPacks ContractsWindow CrossFeedEnabler CrowdSourcedScience CustomAsteroids DDSLoader DeadlyReentry Diazo DistantObject DMagicOrbitalScience EditorExtensions EngineIgnitor EnhancedNavBall ExtraplanetaryLaunchpads FalconTech FASA FerramAerospaceResearch FieldExperience FinalFrontier.dat Firespitter FreedomTex FS_License.txt.txt ftmn_new Fusebox GCMonitor JSI KAS KerbalConstructionTime KerbalJointReinforcement KerbalStats KerbalStockLauncherOverhaul KineTechAnimation KittopiaSpace Klockheed_Martian_Gimbal Kopernicus KOSMOS KSPAPIExt KSP-AVC KWRocketry license.txt LICENSE_DDSLoader.txt LICENSE_KittopiaTech.txt LICENSE_Kopernicus.txt LICENSE_KopernicusTech.txt LICENSE_ModuleManager.txt LICENSE_OuterPlanetsMod.txt MagicSmokeIndustries MechJeb2 MechJebAndEngineerForAll.cfg MM_License.txt modlist.txt ModuleManager.2.5.1.dll ModuleManager.2.5.13.dll ModuleManager.2.5.8.dll ModuleManager.2.5.9.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleRCSFX MunarSurfaceExperimentPackage MyMods NASAmission NavyFish NearFutureConstruction NearFutureElectrical NearFutureProps NearFuturePropulsion NearFutureSolar Nereid NovaPunch2 OpenResourceSystem OPM OPT ORSResourcePack OuterPlanetsMod.version PlanetShine PreciseNode ProceduralFairings ProceduralParts RCSBuildAid RealChute RealFuels Regolith RemoteTech ResGen RLA_Stockalike Sane Strategies SCANsat ScienceAlert SDHI SETI SETIgreenhouse ShipManifest spacetux Squad StageRecovery StationScience StockBugFixModules TechManager TextureReplacer ThrottleControlledAvionics ThunderAerospace ToadicusTools toolbar-settings.dat Trajectories TriggerTech TweakableEverything TweakScale UmbraSpaceIndustries UniversalStorage VenStockRevamp Virgin Kalactic VNG WaypointManager WildBlueIndustries WombatConversions Yarbrough08 000_FilterExtensions I know it's a long list, but I'm really hoping someone here might know if anything in there could have a negative effect on the way MJ handles manuevers. Again, I know for a fact that this is something that has changed recently, though as far as I can remember, the only recent variable changes to the mix were some edits to MJ's attitude adjustment page. That said, if I can't find the culprit, I'm going to have to start again from fresh installation of the game and start working back to where I am now. I feel like it's going to be a headache, but considering all of the different mods I like to run, I'm probably going to have to start obsessively keeping a changelog for my installs so that when something like this crops up, I can identify quickly all of the recent changes that could have caused it. On that note, I'm really hoping someone can help me out here as I'd really hate to lose weeks of game progress because I can't track down the source of this issue. Thanks. PS: Before someone tells me to just accept the lower tolerances, I don't actually think that is an option. I rely heavily on MechJeb because the bulk of the fun in KSP for me is in designing the vehicles rather than hand flying them everywhere. At these reduced tolerances I can only imagine the difficulties in trying to match orbits with an asteroid or other celestial body, especially when I've got a limited number of engine ignitions thanks to the Engine Ignitor mod. As I see it, I must find a way to correct for this issue or I'll be forced to start over from scratch in the hopes that I'll be able to track the variables well enough to revert it back to working the next time it occurs. PPS: @Sarbian, I know you're pretty busy with getting MJ ready for v1.0, but as a request for some future release, I'm wondering if you might include some sort of break on the number of times MJ ignites / kills the engine. While using engine ignitor, you have a limited number of ignitions, but MJ doesn't make any accounting for this, sometimes rapid firing the engine 10-15 times in a row while on a descent trajectory and leaving you without an engine at a point in the flight where that will guarantee you're going to become a crater. Again, this is just a thought for some future release, but I'm sure I'm not the only person who uses MJ who might want something like this to exist. Thanks.

The reinstall was a completely fresh install of the game from the 0.90 zip provided by Squad. Also the MechJeb, Real Fuels, and ModuleRCSFX installs were all fresh downloads.

I just put up an edit to my last post in that thread. I created a fresh testing install to see if there were other factors beyond MJ, RF, and ModuleRCSFX. It seems that even MJ by itself in an otherwise stock game exhibits the same behavior, though with much less usage. Then Real Fuels / ModuleRCSFX seem to exacerbate it significantly when they are added into the mix. I do hope you guys are able to figure it out, as I'd really love to be able to make a vehicle that doesn't rely on reaction wheels heavily, but I also understand that this is crunch time for mod developers, so it will just have to wait.

This is the case even for a 4 part ship consisting only of an alcor pod, a reaction wheel, fuel tank, and engine. I should also note that ships that performed flawlessly for me in the past are now exhibiting this behavior so it is something more general than node tolerance. EDIT: It also appears to be something limited to a specific install of the game and not really the fault of MJ in particular as a test install I put together to try and narrow down the cause of my RCS issue does not display the same behavior. I guess I will have to figure out where this conflict comes from before continuing. EDIT2: I can also confirm that the original RCS issue is directly related to MechJeb as using RCS only to make attitude changes through MJ results in the same overuse of monopropellant as I was experiencing in a fully modded build, though at a much lower rate. I think that the core issue lies with MJ, but then it is drastically exacerbated by the changes that Real Fuels brings to RCS thrusters / fuel.

So now I'm faced with a new and perplexing problem. Whenever I try to have MechJeb execute a maneuver node, the autopilot will work just fine right up until the last 0.2m/s at which time, instead of the engine shutting off, the maneuver node slides up to sit perpendicular to the horizon, with MJ following it up there, and then will not complete ever, with MJ constantly thrusting at minimum power until for at least several minutes, or even until all fuel is burned and without ever shutting off automatically. This is a new effect which I have never seen before, and for which I can't think of any cause except my attempts to tweak the attitude adjustment. Unfortunately, though, I can't get it to go away at all now. I've deleted and reinstalled MechJeb several times now, deleted and rebuilt several ships to ensure there weren't any old MJ modules sitting somewhere in the craft files. None of this has corrected this new problem at all. I'm unsure if it even relates to MJ directly or if I'm getting the issue from somewhere else, but the only variable I've changed recently was Mechjeb settings, so if there is any other possibility, I'm at a loss to know what it could be. Any help with this new issue would be greatly appreciated as I rely too heavily on MJ to simply go without at this stage.

The problem exists somewhere in the interaction between Mechjeb, Real Fuels, and ModuleRCSFX as MJ had no problems until I installed the latter two. Where I'm getting lost is why I'm having so much trouble with this, but virtually no one else has ever seen the same issue... I can't be the only person to install Real Fuels with ModuleRCSFX, Stockalike configs, and then try to use MJ with RCS control only...

Here is the .craft file I'm doing all my testing on. I've currently not set correctThrust or fullThrust as neither seem to have had any effect at all on the control issue. https://drive.google.com/file/d/0BzPO9eXfO6xGdXA0NVdoMjlUVjQ/view?usp=sharing

I'll probably try this as well, though from the readme, it seems that false for fullthrust is the stock game setting, so if MJ works correctly in stock, I'm not sure taking that away from stock will help. Again though, I'm still unclear on it's these modifiers exact usage within a part config file, so I could be sticking the lines in entirely the wrong place and they'll have no effect whatsoever...

Right, but where in the config for said part should I insert it? Also, what syntax is required? I tried inserting it into the ModuleRCSFX block and so far it doesn't seem to have changed anything, currently waiting on load to put it into the engine configs block.

Can someone please tell me where the "correctThrust" entry would go in a part config? I'm having some trouble with Mechjeb being unable to control my vehicles though RCS wherein a desired attitude will be achieved, only to be followed by endless corrections by the system firing out of multiple RCS thrusters, only stopping if Mechjeb attitude controls are turned off. I've been asking on the Mechjeb thread, but this seems to be a problem only I have ever seen for some reason, so I'm trying to work through all of the possible causes to see if I can't find a way to fix it. Considering the fact that this issue didn't arise until I installed Real Fuels with the stockalike configs (and along with it, ModuleRCSFX), I have to assume that the issue lies somewhere in the interaction between MJ, RF, and ModuleRCSFX. As a result, I'm really hoping that I'll be able to correct this issue with a simple / easy tweak to one of the components rather than just being forced to accept the issue as is Anyway, like the first line says, how would I go about setting the correctThrust parameter to false for an RCS block to see if that has any effect? Thanks

It does have SAS, but the torque has been disabled for testing purposes. That said, I'm using SETI so most of the reaction wheels have been either disabled or significantly scaled down, leading to the need for good control through RCS. EDIT: Turning off the ability to use RCS for rotation disables all RCS control except for translation...

I build all of my craft with RCS build aid to make sure they are balanced out of the box. That being said, yes, I did try using the balancer, but it did not fix the problem. EDIT: Something I want to add after some more playing around is that the primary problem seems to lie in roll control, though pitch and yaw do seem to exist as well. It seems that after a vehicle arrives at the desired attitude, it's the roll thrusters that are left constantly blasting while the pitch and yaw only seem to fire occasionally.

@sarbian Do you have any thoughts abouthe what could be causing my control problems and/or how I might be able to get around them (suggested settings for attitude adjustment page)? I don't like to bug, but I'm currently unable to use mechjeb with a vehicle which doesn't include a strong reaction wheel due to the constant oscillation around the desired attitude when using RCS as the primary control mechanism.

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.

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.

This is the method I've used in the past multiple times. The problem is that the leading / trailing relays leave a small section on the surface and the poles without coverage. This is easy enough to account for, but I had hoped to get something a little more effective into place this time since I'm planning on really building up my Mun presence in this save. This is good to know, at least if I'm able to get them into a decent position with a controlled orbital period I can leave them there indefinitely without them decaying.

There shouldn't be any unbalanced forces that I'm aware of, though that doesn't always mean that much in this game. After work today, I'll try launching new design out to the Mun to see if there is any difference.

I too am often in time warp, but keeping it there permanently just isn't really feasible. I wonder, though, if craft that are being background processed in real time are still on rails or if they are getting physics calculations along with the active vessel. I'm currently trying this method, though I do consider it to be a little bit cheaty. I'm hoping that I won't have to revisit this network for a while as a result though. I am indeed trying to get perfectly circular orbits for my relay networks, mostly because they look better that way, but also because minimal eccentricity is a requirement for the RT2 relay contracts. They want it to be less than 0.004 which doesn't leave much room for stability eccentricity, at least until the network is up an running long enough to fulfill the contract. If I keep having troubles, I might try adding a little eccentricity into the orbits to see if that stabilizes things. I meant what I wrote. I had the first satellite in my Munar relay network in a circular orbit with a period of 12 hours. I then left my game running to do a few things around the house and after about an hour, I returned to find my orbital period had decayed to just under 11 hours and 40 minutes, leading to the statement that my orbital period was dropping by as much as 20m / hr.

I'm in the process of setting up a Munar relay network for RT2 and have been running into lots of instability in my orbits, leading to my orbital periods dropping by as much as 20m / hr. I've done some looking and the only explanation I've been able to find is that this is due to floating point errors in the physics calculations when not on rails. I can accept this, but I'm still left wondering how I can correct for these errors without having to babysit the network constantly. Would lower, faster orbits be affected less potentially (I've set up for a 12 hour period, but I could half that without too much trouble), or should I just give up on the idea and set up leading / trailing relays as described in some RT2 guides. Thanks. PS: Can someone explain to me why this is such an issue for the Mun, but is hardly noticeable, or even non-existent for Kerbin?

Sadly, that's exactly what I'm often wanting to do, offset one proc part into another to give the appearance of being built into the surface rather than just slapped on top. I haven't thought about that, but I'd probably want to offset the strut, which brings me right back to where I was before...

This wouldn't actually surprise me as I've had some interesting things happen on loading a PP heavy craft. I'll go on that thread and see if there is something I'm doing wrong or something I'm missing that might resolve the issue.

I'm betting that is the same thing happening to me. I use PP heavily so most rotated / offset parts are attached to something procedural. Have you found any way around this?

I've done some searching and can't seem to find a solution to this. Any time I use the offset or rotation gizmos to edit a part on a craft, it will stick just fine until I try to load that craft again from a saved file or after reverting to the VAB where all of the rotations / offsets are completely gone. Is this a common problem? Or could I be having a mod conflict? If the latter, what would be the best way to identify the culprit? Thanks.

I'll give that a try to see if there are any changes in loading. I already have MKS, but I'm sure I've overwritten the firespitter.dll with the most recent one from the release thread.