Galane

I'm not getting the Kethane button in the stock toolbar nor do I get the Kethane control panel/window so I can't turn the grid on or off. I have the unofficial DLL installed.

Manual docking is easy, with the aid of Smart A.S.S. Control each craft from the docking ports you want to connect. After you rendezvous you need to get to 150 meters distance. Switch between the two crafts and rotate the view until you can see the other craft from each. Right click the controlling docking port then hit [ or ] to switch. Click the Set as Target button then right click the current craft and switch back to set the other port as target. Now open the SASS window and change to target mode and click the TGT+ button. Do this on both ships. Optionally, use the Force Roll function if the ships orientation to each other is critical. Of course you must do all this rather quickly as the ships will be moving relative to each other and you don't want them passing and moving apart, or worse, colliding uncontrolled. If they are on a collision course, they'll dock themselves - assuming they both have enough control power to rotate fast enough to stay aimed at one another. If they are moving together too fast, use some reverse RCS thrust to slow down. If they aren't on a collision course you'll need to use a bit of engine or RCS thrust to speed up a little. What you don't want is a sideways grazing impact of the ports. You want the direction of approach to be somewhat aligned with the orbital direction. With the Docking Autopilot the "trick" is to set the ship you are docking *to* to KILL ROT in SASS. That makes MechJeb attempt to keep the craft from turning in any direction. If you set both to TGT+ and try to use DAP, both ships will try to chase each other's targeting corrections and they'll both be wobbling all around. With a highly maneuverable docking craft, DAP is now good enough that it can usually figure out how to fly around another craft to a port on the far side or otherwise not in line of sight or directly aimed at it. If the default safe and starting distances are causing trouble, use the overrides. I generally use 5 for safe and 10 for starting. Starting the docking from too close can cause DAP to try to fly past the port. Back up a ways then try again.

That's the way it has always worked, due to limitations of KSP. It *could* be worked around but would require lots of calculation to generate the orbit coverage ships with Kethane scanners have flown while you're not actively flying them.

Another one of those sometimes things. Did it to me last night lifting off Moho. It did the circularization burn then instead of stopping it cut the throttle to just off the bottom and pointed the engines at Moho. I disengaged the autopilot, then removed all nodes with Maneuver Planner. Then I went to Rendezvous Autopilot and it persisted with the same end of burn issue. F5 is your friend, always. Always quicksave before liftoff, starting to land, starting a rendezvous etc. Seems to be that once MechJeb starts not ending burns properly it will keep doing it until you reload the last quicksave.

Just needs a sanity check to compare the thrust vector of the engines against the up/forward direction of the active control part then pop a warning if they're opposing directions.

I did a rendezvous in Moho orbit last night, all the same setup and ships as the previous attempt where it insisted on screwing up every maneuver, but this time it worked perfectly. I know it's a PITA to find intermittent bugs but it would be nice to know some attempt is being made to address this problem that becomes more frequent at smaller diameter orbits.

Anyone else having issues with Rendezvous Autopilot around Gilly or Moho? I was attempting to see if an old failure of a Kethane lander for Duna (not efficient, could barely lift enough to make more fuel than it took for the trip down and back but was better than great for Ike, still have two of them there in my main save) would work with the lower gravity and no atmosphere of Moho. Landing from 75km went perfectly. Liftoff to a 100km orbit also went perfectly. What did not go anywhere close to anything remotely like perfectly was an attempt to rendezvous with the craft standing in for a transfer vehicle. At EVERY part of the maneuver instead of correctly finishing the burn then warping to the next maneuver, Rendezvous Autopilot would instead drop the throttle to just off the bottom stop and point the engines at Moho while continuing to fire the engines at "idle". This has been a problem in Rendezvous Autopilot and Maneuver Planner for a very long time and the smaller the orbit radius the worse it gets. So far I've only done orbits around Kerbin, Mun, Minmus, Duna, Ike, Eve, Gilly and Moho - with "real" missions (not getting there with Hyperedit) to all of them except Moho. I do a lot of testing to develop the crafts then fly a full mission there and back to Kerbin. (I went to the moons of Kerbin before ever using Hyperedit.) The Aim Engines at <body> and Idle Burn Instead of Properly Concluding Maneuver has for me been far as I remember next to nonexistent at Kerbin. It's happened some times at Mun and Duna. Don't recall it cropping up at Minmus. Never happened to me in Eve orbit. Flight maneuvers around Gilly *required* quicksaving before every attempt at making any change because it was extremely likely it would go wrong in any way one could imagine. Even if I hyperedited two crafts into perfect equatorial orbits around Gilly, Rendezvous Autopilot would insist on doing at least two un-necessary plane changes. It would also often after doing a burn to change apopapsis as step 1 of changing to a higher orbit, decide that partway to the new apoapsis that it had to change it again. IIRC once it wanted to do that three times in a row instead of just raising apo, coasting to there then circularizing like it's bloody well supposed to do it before orbiting into phase for the Hohmann transfer. Now in testing at Moho, with .25 this problem would crop up now and then but tonight in .90 with the latest dev build of Mechjeb it just wasn't possible to do a rendezvous. If I aborted the burn as soon as the lander began to twist its engines toward Moho then immediately re-enabled the autopilot it would begin the next maneuver - with added correction for its just prior screwup. But it would finish that maneuver by aiming the engines at Moho instead of cutting the throttle and orienting for the next burn. So with fuel about to run out I gave up on the test. Might have been that saving before lifting off from Moho then F9-ing back to that *might* have knocked sense into its bits, but I was just wanting to get in *one* test run, not having to repeatedly save and reload to force it to limp along. I don't have a log, unless you really want 14 megabytes of accumulation because I didn't delete the old log because I did not expect such a spectacular failure to function, especially not after landing and ascent on and from Moho worked so well, in fact, the best of them I've ever had there. What is the problem these parts of MechJeb have as the radius of the orbit gets smaller? Why is it flaking out by not correctly ending burns instead of doing what it is supposed to do? It's not due to a sluggishly turning craft, the lander I was using can flip 180 degrees in a couple of seconds.

I used the dev build last night, docked and undocked two craft in Kerbin orbit without a problem.

Yeah, on the Mun. It wasn't always that accurate without atmo. On one Kethane mining site on Mun I was lucky if they came down within a couple kilometers of the Okto 2 probe core I dropped for a target beacon. I dunno the height for the second but that lander is capable of coming down from at least 200 KM, as are the other two stock landers I've been using since .21. Without deadly reentry and only deployed solar panels taking entry heat damage without a mod to do that, the starting altitude doesn't matter, though at times MechJeb has had issues starting landings below a specific altitude. Dunno if it varies with the body but for Kerbin it had had problems starting below 100 KM that didn't happen at 100 or higher. When I went to Eve and back (after a huge amount of testing there with Hyperedit) MechJeb had a terrible time with the small orbits required around Gilly. http://imgur.com/a/2C8Iw#0 Lots of quicksaving and reloading.

I put this rover down on Eve without parachutes. http://imgur.com/a/2C8Iw#75 In testing I tried a single chute on top but that made it swing back and forth and crash. On this landing MechJeb put this lander http://imgur.com/a/2C8Iw#77 down and only popped the two small chutes where every time before it had also used the two radials and four large chutes. No damage despite punching the legs through the surface. I think I'll add some Landertrons and give it a go with no chutes, except the two radials on the can which are needed to land on Kerbin.

You want accuracy? I'll show you accuracy. IIRC these two screenshots are from KSP .21 with some version of MechJeb that was contemporary with it. Rover on Rover by g_alan_e, on Flickr I was able to drive the second one off the first then flip it onto its wheels with RCS. No damage. Two-Step-returned by g_alan_e, on Flickr It set the lander down on the crawlerway but the last booster stage it put down nearly dead center on the pad. I was kinda hoping it would crash the booster into the lander.

Replaced the SDF 1.1 DLL with that one. No change in how Landing Guidance doesn't work with SDF.

This is what I get in the log, and after the last line here it quits logging. AddonLoader: Instantiating addon 'StockDragFix' from assembly 'StockDragFix' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) noseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) noseConeAdapter switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) rocketNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) standardNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) avionicsNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) shockConeIntake switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) HighlightingSystem : Edge Highlighting requires AA to work! (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Note that it's enabling conic drag model despite the cfg having enableConicDragTypes = false I just did a couple of test flights after running the cfg through Wordpad to fix the line breaks and now the log doesn't quit. Still can't land with MechJeb with SDF. Still has the switched to CONIC Drag Model lines in the (now normal 2 megabyte + log).

Having a problem with a mod in Windows? Find any text files that come with the mod, especially .cfg ones, and open them in Notepad. If it's all run together and has odd characters in it like inverse zeroes, it's been written with Unix style line breaks and KSP for Windows is going to look at it and go "Huh?" then odd things will happen. Fortunately it is easy to fix. Simply open the file in Wordpad then save it. Wordpad will automatically fix the line breaks to what Windows (and DOS before it) has used for the past 34 years.

I found a problem. The CFG file included with Stock Drag Fix doesn't have the right type of line endings for Windows. Open with Notepad and it's all on one line with inverse 0 characters appearing where the lines are supposed to break. Open with Wordpad and save and that gets fixed. Can't show the problem here because when pasting the file's contents into the post box it interprets those characters as line breaks and displays as intended instead of as it actually is. I've run into this same issue with some other mods where a critical text file isn't processed properly because of not using the right type of line breaks. Now that I've run the CFG through Wordpad I need to test it to see if it works.

I didn't enable it or change anything in SDF, just extracted its folder to Game Data. *looks at the SDF_Settings.cfg file* STOCK_DRAG_FIX_SETTINGS { dragScale = 1 // Do not enable. Experimental and only partially functional. enableConicDragTypes = false } What may be a problem is that file is not written with the line endings that are standard for Windows. Open with Notepad and it's all on one line with the inverse 0 characters where line endings should be. Open and save in Wordpad and it fixes that. I've noticed that causing issues with other KSP text files in Windows. Oddly, copying and pasting the file contents as-delivered, to here, it pastes with the appearance of being correctly formatted. I'll test this and see if that helps. *after test* Well, logging no longer stops after Stock Drag Fix loads but I still get the switched to CONIC drag lines in the log and MechJeb still can't land on Kerbin with SDF. I did two flights. First run it looked like it was going to work. It did the high deorbit then a proper single correction burn. Then it jumped right into braking burn with ever increasing target speed until it went to the window full of zeros and quit. Second try I got the "correcting" in random directions, rather than only in the existing orbital plane.

Nothing except 1980's micro computers with their operating systems in ROM chips. Ready to go the instant the power was turned on. I used to have a PC running Windows 98 SE, much slower hardware than what I have now with Windows 7, that was fully booted and ready to go in only 45 seconds. That was years before the first SSD hit the market. A lot of that speed was the 7200 RPM hard drive. Now I have a 3.2 Ghz dual core with far more everything in speed and capacity than that one from the end of the 20th century, and it boots up *much slower*. Progress? What? Back then I also had an old 300 Mhz Pentium II laptop (Toshiba Tecra 800) that with its original 4200 RPM hard drive took well over 5 minutes to boot Windows 98 SE. When I upgraded to a 5400 RPM drive of much larger capacity it reduced the boot time to under 2 minutes and it was far quicker at everything else.

Something has logging messed up. I checked to make sure it's enabled (even though that disable option has never actually worked) but it ends after this AddonLoader: Instantiating addon 'StockDragFix' from assembly 'StockDragFix' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) noseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) noseConeAdapter switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) rocketNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) standardNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) avionicsNoseCone switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) shockConeIntake switched to CONIC Drag Model (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) HighlightingSystem : Edge Highlighting requires AA to work! (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) I did a run where I let it go all the way to landing. After the high deorbit, it performed a proper correction burn then suddenly it showed it needed an almost 400 m/sec "correction", pivoted and popped a little burst. The correction dropped instantly to 0 then back up to almost as much as the first one. It kept flipping back and forth, each time the bogus "correction" requirement kept getting smaller. Eventually it quit doing corrections and began a braking burn but instead of decreasing the target speed number was increasing and went up until it popped to 179769313486232 followed by a lot of zeros. (Got a screenshot). Instead of aborting the landing I let it go to see what would happen next. It recovered after coasting down and soft landed in the ocean. That's one misbehavior I get. Another one is after a few flips back and forth it turns sideways to burn all the fuel doing an inclination change, with the "correction" required steadily increasing. The third way it goes worng is apparently random direction thrusts that like the other ways produce very large changes in m/sec readout from tiny puffs of thrust. Sometimes that way settles down into doing the never ending inclination change. Quicksave of starting from orbit after launch. I use SASS to do NML+ then manually decouple the lander while it's swinging so the boosters are out of the way. http://partsbyemc.com/pub/quicksave.rar Persistent from the latest run where it landing guidance decided it had to do a huge inclination change. http://partsbyemc.com/pub/persistent.rar Album with two shots of the one run where the target speed number went crazy and where it recovered to do the braking burn. The rest are from the other run with the initial incorrect corrections and several showing it stuck trying to change inclination. http://imgur.com/a/zwt84#0 So until it's figured out what/why/how Stock Drag Fix is giving Landing Guidance fits when it's not even in atmosphere, I can't use Stock Drag Fix. Will be returning to my irregularly unscheduled attempts to design a lander and other stuff for a trip to Moho and back, with the mods I normally have installed. P.S. Putting the Abort Autoland button in a fixed location relative to the top of the window might be a good thing. When it's going wonkers like this with data above it rapidly changing, it's difficult to click on Abort as it's bouncing up and down.

So with the right mods you can play Kerbal Space Program with your KIDS NEAR HOME.

Did you put them all in at once or one at a time? Do a clean setup of KSP then put in Mechjeb, then your mods one at a time and try landing on Kerbin after adding each mod. I've been too busy lately to try the last 3 or 4 MechJeb dev builds to see if any of them have fixed the issue with Stock Drag Fix. I have a clean KSP .90 setup with no mods except MechJeb and Stock Drag Fix and MechJeb cannot land on Kerbin. Works fine without SDF. Same tale with my working setup with a lot of mods. No SDF and it does the high deorbit burn and usually one correction burn then coasts down to do the final "suicide burn" like it is supposed to. Nothing useful shows up in the log but MechJeb just twists and turns the ship all over the place, firing off short bursts of thrust after doing the high deorbit burn. With .25 and Stock Drag Fix it would only do this some of the time. Usually reloading the quicksave would cure it but in .90 it has flipped out EVERY landing I've tried on bodies with atmosphere. Here again is a log from my modded install http://partsbyemc.com/pub/output_log.zip I deleted the log then ran KSP. If I have time tonight I'll put in the latest dev of MechJeb and try it again with the vanilla KSP with only MechJeb and SDF then will post here if it works or not, and post another log if not.

Is there a debug version of MechJeb that will create its own log of everything it does, including every maneuver and engine thrust?

I'd like to see a video of launch, orbit and landing of the Stearwing. Must take some very careful flying to stretch out the fuel. I launched the Learstar straight up with SAS on, until it began to get unstable. I cut throttle, dumped the SRBs and big tank then managed to glide it to land on the ground near KSC. Nearly crashed into the ocean before getting it to pull out of the dive. If KSP had effects for air/water interaction it would have thrown up a rooster tail from the woosh. Had no mods installed in .90 yet, I was intending to just let it crash but decided to see if I could glide it. I tried a few times but could not get the Stearwing to do anything but act as a lawn dart without being under power. Stick on a couple of canards and it will glide unpowered. The problem I have with bringing spaceplanes down from orbit is losing altitude fast enough, while not getting too low and hitting that pesky mountain range. MechJeb's landing guidance is not at all suited for spaceplanes. It might work to get down to a starting altitude and distance to switch over to Spaceplane Guidance with the right target coordinates. I have used Ascent Guidance to get various planes to orbit, though usually after a manual takeoff and several times manually flying quite high before engaging the autopilot.

Stock, without altering them? There's a distinct lack of YouTube vids on both stock craft.

How about a COBRA H.I.S.S. tank? http://www.yojoe.com/vehicles/83/hiss/

Or launch with the new MechJeb that has a differential throttle function for automatic thrust balancing. :-) One of the first things I did in .90, before installing any mods, was to toss the Learstar on the pad, hit T and launch it straight up until it started to get unstable. I cut throttle, dropped the SRBs and big tank then manually flew it back to land near KSC. If KSP had aerodynamic water interaction effects I would've blown up a rooster tail from how close I came to not pulling out of the dive over the ocean. The craft that *is* impossible to glide is the Stearwing. Without power it's a lawn dart. It doesn't have enough fuel to circularize after reaching orbital altitude and it has a bunch of Vernor engines under the back and in the cargo bay that can be used for a vertical takeoff, at the cost of a lot of fuel and oxidizer. If any of the stock craft is a lesson in how to build a cool ship that nearly works so figure out how to fix it, it's the Stearwing.