r4m0n

Pre-release 2.0.7 released! Lots of fixes with RCS and the ascent/landing APs, and some new features. Full changelog here.

What says your numbers are wrong, and can you send a screenshot of that?

mechjeb.core.part.vessel.mainBody.maxAtmosphereAltitude

Now it's easier. Just make sure the Center of Thrust lies as close as the Center of Mass as possible.

My fix was mainly on the wait() function, which doesn't appear you were using. De-syncs can happen anytime, so running heavy computing code is really likely to trigger it. I'll see if I can do something about it, but Unity doesn't support multi-threading, so it's possible that I won't be able to totally eliminate those. If you want to run heavier code, break it in pieces you can run through wait() and make them able to resume if the previous triggered the error in the middle. Update: I've checked around a bit, and this particular error happens when you are iterating through an table and change one of it's elements, were you doing it? It would help a lot if you could share the code that caused this exception.

Can't help you much there, as Unity's joints are quite messy, and then the game adds some extra complications due to the (undefined) units it use. The CFG parameters set the lowAngularXLimit and highAngularXLimit of the ConfigurableJoint to a SoftJointLimit with those parameters.

Duh, I should have thought about adding a box for the pre-circularizing burn lead-time. I'll do that until I can reasonably calculate the needed time. As for the max warp, it really shouldn't be going into 100kx unless there is plenty of time for it, I'll go back and correct the warp tables again.

It won't work as is, here is what I can see will fail: After the "Transferring to Duna", it will still be in Kerbol orbit, you need to warp to SoI switch, then probably correct the Pe, warp to Pe and THEN circularize. Else than that, the landing AP will probably crash the ship, as it isn't ready to account for the atmosphere of Duna yet, so you could start it, wait until you are at a safer altitude, say 15km, and engage the plain mechjeb.land() function, which ignores the atmosphere but is more reliable. You can't properly pick where it will land, but it won't crash you.

It wasn't made to detect anything else than the munoliths, and I'll consider the arches an added bonus. I'll see if I can convince Nova or Mu to add a few munoliths in other planets, but I don't think it fits with the "lore" of the detector to detect any of the new easter eggs.

We're moving the suggestions/bugs tracker to: http://idea.ksp.mumech.com/ The ideas currently in the Userecho forum will be eventually moved there, sou you don't need to post it again (unless you want to add/change something).

It's a random Unity GUI glitch, closing/opening windows or exiting the flight scene and coming back usually fix it. And MechJeb 1.9.3 has just been released! Here is the full changelist. Shard has also joined the project, and is adding new features and squishing bugs.

Where are you reading them reversed? I don't remember anywhere where 90 = west.

Last update for today, still in experimental status: http://www.mumech.com/uploads/MuMechLib.dll Features: Added a "Angle to Prograde" to the Orbital Information window. That is the ejection angle from Olex's calculator. Click on the label to change to "Angle to Retrograde"; Added a new Phase Angle window, to see the current phase angles (also for the calculator); More random fixes;

The TRANS module was never meant to go to lower orbits, I'll see if it can be changed without a total rewrite. In the mean time, another beta update: selecting the location to land is back again, MechJeb uses physical warp better and should stop losing the configuration. Download here: http://www.mumech.com/uploads/MuMechLib.dll

I will be adding some transfer times tables to start with, then adding full automation as time goes by. I have uploaded an experimental uncapped version here: http://www.mumech.com/uploads/MuMechLib.dll. Let me know if it doesn't decelerate fast enough.

MechJeb 1.9.2 released with 0.17 compatibility!

dofile("somefile.txt") should work if you want to keep the extension, but beware of mixing real text files with Lua code.

I'm guessing the launch to rendezvous function only works in the initial launch, I'll take a look at it.

The Variable family and other stuff are from here.

1 - mechjeb.core.targetBody 2 - http://svn.mumech.com/KSP/trunk/MuMechLib/MechJebCore.cs Note that targetVessel is a C# Vessel object, not a VesselState like the Lua "vessel" variable. What you wanted would be mechjeb.core.targetVessel.orbit.orbitalSpeed.

It would be better if you make a new DLL with just the camera module (and make that a new class, so to not conflict with the camera module). You can either reference mumechlib or just copy and alter the source, I'm OK with it.

Noticed this recently, the code is from Rincomp, I'll try to fix it soon. As-is, this would break compatibility with the Mac build, so I'll have to sit on it for a bit while I see if there is some way to integrate it nicely under all situations, but thanks for the patch.

am i missing something in my build configuration or something? i followed all the setup instructions on the wiki and have spent the better half of the last week searching the forum for a solution. Try building the DLL for .NET version 3.5. Just change the module of your part to MuMechJebPod.

I've highlighted the problem... If you don't replace the DLL with the 1.9.1 version, it won't work