Galane

You have to put the AR102 or the Eye Pod on your rocket or plane - or use module manager and a cfg file to patch MechJeb into the control pods.

All mods all go into GameData folder. The toolbar is Blizzy's Toolbar. It's not *required* but many mods have come to rely on it. http://forum.kerbalspaceprogram.com/threads/60863-0-23-5-Toolbar-1-7-1-Common-API-for-draggable-resizable-buttons-toolbar

KSP runs into the same problem old CP/M and DOS programs did with their limited amount of available RAM. The common solution was loading "overlays" or modules with a small core program always loaded to manage it all. For example a word processor would load the core part and the editor module. Then when you went to print it'd kick the editor out and load the printing module. Spell check, word count and other functions all separate modules and if the document being worked on was too large for the remaining RAM (remember, 64 kilobytes for CP/M, the word processor program and the document!) it'd get loaded in chunks from floppy disk then changes, if any, written back before loading the next chunk. Speed wasn't too bad. If the computer had a hard drive it could be pretty darn quick since it was only displaying and working with plain text. Programmers have gotten a bit soft and spoiled with gigahertz of speed and gigabytes of RAM and storage. The first hard drive I owned was five megabytes and with DOS and all the software I had installed it was only half full. I work with single images and documents every day that wouldn't fit on that hard drive. This PC is a 2.5 Ghz AMD 7550 dual core with 6 gig RAM and a nVidia 9800 GT video card with a gig of RAM, running 64 bit Windows 7 - yet to get tolerable performance out of KSP I have to disable anti aliasing, disable the VAB/SPH crew and terrain scatter, use Active Texture Management and run at a lower resolution AND turn off the logging. But as has been shown by various mods like ATM it is possible to help the performance. Would be nice if Squad would take a break from adding more features and do an optimization/performance release to clean up loose ends, shrink over-large textures and whatever else they can find to speed it up. I'd bet they'd find a lot of things to prune and tune.

Yes, it's supposed to be 0 bytes. You can safely delete it. The only reason it's there is in case someone overwrites a much older version with the new one instead of deleting the old version like they should.

Two more tests failed. Set a lander with deployed legs to gently drop from a launch clamp with engine running, then cut throttle followed by HyperEdit to 20 KM Mun orbit. Same setup but used MechJeb to launch and at about 3 KM disabled ascent guidance then HyperEdit to 20 KM Mun orbit. Didn't use RCS but with it on the outcome is no different, failure to work right. In each case I set maneuver planner to change orbit inclination to 2 degrees at the equatorial AN. In each case it initially aligned correctly but partway through the burn it began to cut throttle to idle, aimed the engine at Mun and sat there with the gauge stuck at 0.3 M/sec to finish, gently wobbling about and slowly increasing altitude. This is in a KSP install with only build 257 of MechJeb (only the DLL), the current HyperEdit, ReStock Reloaded (but none of its parts used), Module Manager 2.1.0. This craft, http://pastebin.com/jCUE8Gsn built in .21, no crew. Or this craft, built in .23.5 http://pastebin.com/WMam2AKD Same results with both. Using this MM cfg to add MechJeb @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } }

Two more tests failed. Set a lander with deployed legs to gently drop from a launch clamp with engine running, then cut throttle followed by HyperEdit to 20 KM Mun orbit. Same setup but used MechJeb to launch and at about 3 KM disabled ascent guidance then HyperEdit to 20 KM Mun orbit. Didn't use RCS but with it on the outcome is no different, failure to work right. In each case I set maneuver planner to change orbit inclination to 2 degrees at the equatorial AN. In each case it initially aligned correctly but partway through the burn it began to cut throttle to idle, aimed the engine at Mun and sat there with the gauge stuck at 0.3 M/sec to finish, gently wobbling about and slowly increasing altitude. This is in a KSP install with only build 257 of MechJeb (only the DLL), the current HyperEdit, ReStock Reloaded (but none of its parts used), Module Manager 2.1.0. This craft, http://pastebin.com/jCUE8Gsn built in .21, no crew. Or this craft, built in .23.5 http://pastebin.com/WMam2AKD Same results with both. Using this MM cfg to add MechJeb @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } }

A problem I've had using Hyperedit has cropped up with MechJeb build 255 and later is that when I use Hyperedit to take a ship from the pad to orbit, MechJeb's rendezvous autopilot and maneuver planner cannot correctly control the ship. They'll do anything except the right thing, most of the time all they do is aim the engine(s) at the body being orbited and barely crack the throttle open. But sometimes it will start to do the maneuver and burn correctly but at the last bit of the burn will cut throttle to idle and aim the thrust downward. Some times it will just go to a full throttle escape trajectory. I've tried putting ships on the pad with and without launch clamps. No difference in how it's not working. If I launch the ship and ascend to Kerbin orbit under MechJeb control then use Hyperedit to move the ship, MechJeb works like it should. If I fly to the destination without using Hyperedit at all, MechJeb works correctly. I wonder if there's something new that .23.5 does with a normal launch that Hyperedit is missing with just teleporting off the pad, and it's confusing MechJeb? It's acting like the KSP .23 bug where it (KSP not MechJeb) wasn't correctly setting control to a part after decoupling or undocking so the player had to manually set control from here for Mechjeb to control the ship. That is NOT what is causing this issue. Manually setting control from here doesn't change anything. How I happened upon this is I have a Kethane mining lander using Infernal Robotics parts. Since IR .16 is going to completely replace all the old parts, and KSP .23.5 already broke old ships with IR (unless some heroic persistent file editing is done *before* flying any ship with old IR parts), I wanted to salvage the 32K Kethane in the lander's tanks. Launched it to a 20KM Mun orbit then built a recovery tanker and flew it out to the Mun. Had a brain fart and only gave it 16K capacity. Doh! Since I'd already done the salvage flight I gave myself permission to cheat out a modified tanker with 32K Kethane capacity. That's when the "fun" began where I tried many different configurations, then tried just doing rendezvous with the lander using all stock parts ships. Until then, I had not used Hyperedit at all with .23.5 so I don't know if MechJeb builds prior to 255, compatible with .23.5, exhibit the same issue. Most of my .23.5 action has been with adding parts to ReStock to work with the Kerbodyne and ThunderMax parts, and the even larger ThunderMaximus parts - and fiddling around with SRB rocket gliders. I hadn't done a thing outside Kerbin orbit in the latest KSP until attempting the Kethane salvage mission. The common thing through all the tests is that unless the ship is properly launched before touching it with Hyperedit, MechJeb can't control it. I'm pointing the finger of probable cause at something changed in KSP .23.5 since HyperEdit hasn't been changed and if HyperEdit isn't used to "launch", MechJeb works. One more thing I can try is launching then cutting throttle while still in atmosphere then using HyperEdit to put the craft in orbit, see if it's something to do with using it from within atmosphere.

I should try a launch that just drops it gently onto the pad, then hyperedit it to orbit and see if it still has problems.

Just did more testing, using old, all stock parts, crafts I put together in .21 If I launch to Kerbin orbit then move the ship with Hyperedit, Maneuver Planner and Rendezvous Autopilot work. If I launch to Kerbin orbit and use Mechjeb to do maneuvers, it works. If I use Mechjeb to fly to the Mun, it still works. If I just pluck a ship off the launchpad to orbit with Hyperedit, they fail to work properly. This go-round I had rendezvous AP doing a plane change that went directly to a full throttle Mun escape, and another where it didn't even begin to do it correctly, just aimed the engine at Mun and burned. I tried several times, reverting to launch or VAB - every time Mechjeb's maneuvering won't work properly with a Hyperedit "launched" craft. The problem only appears to be with ships that have NOT launched. Is there some new thing in .23.5 that gets set when a rocket or plane leaves the pad or runway under its own power? Something that Hyperedit isn't setting when it's used to teleport a craft to an orbit? Whatever is being buggy, it's preventing me from using Hyperedit, which a real damper on testing since the only way I can use Mechjeb is to fly things to places the long way. So I'll fly a ship out to salvage the 32K Kethane from the lander in Mun orbit, which was the original plan to prepare for IR .16, but that still leaves me unable to do Moho lander testing, my next target after going to Eve and back. (Which is going to get a major rework on the transfer ship using Kerbodyne and ThunderMax or ThunderMaximus pieces to reduce parts count to something manageable.)

You don't have to do a plane match, you can do a fine tune closest approach after doing the transfer burn, but the angle you intercept at will be anywhere but equatorial. 1. Match planes 2. Transfer burn 3. Fine tune closest approach (optionally aim for aerobake/capture if destination has atmo) 4. Circularize after passing the intercept marker, too early and it'll try to circularize around the body you are leaving I like to aim the intercept *at* the target rather than *around* it. That way any bits the rocket sheds afterwards are very likely to be self disposing. A fine tune can be done after to miss it.

Eiffel 65's "Blue" but change everything to Green.

Much of good GUI application design is making sure that if the user chooses any font size other than the OS's default (especially larger) the windows don't have text becoming partialy hidden. Buttons, lists, everything should expand to fit while also not being shrinkable too much. I've seen plenty of apps where all the elements were fixed in size so if the font size was made larger the text ran off into nowhere, and the window could be expanded or maximized while the window content stayed all piled up in one corner - and that often combined with no minimum window size so it could be shrunk to a postage stamp. A website gone but mirrored many places (and often added to) was the "iarchitect interface hall of shame", a collection of some of the worst things ever inflicted on users in the name of "productivity" or simply just attempting to look neat. I am not a programmer, but I do have over 30 years experience using and fixing computers and have encountered much of the good and bad and plenty of flat out "WTF is this supposed to do?" in software, and I do try to keep up with at least the basics of the how/why of software design. Software design is related to but very different from software programming. Many of the pioneering programmers in the 70's and 80's were only actively *programming* for a short time then moved to *designing* software. They plotted out what they wanted software to *do* then handed to project over to a programming team to actually write the code to do the task per the designer's plan. Thus beginning in the mid to late 80's, the top people in big software companies were no longer directly involved in the bits and bytes of their own products. If they looked at the source code they might have an overall concept of it but they wouldn't be able to find and fix a bug or add something without going to a lot of time and effort. It's a looooong way from when one person often wrote all or most of a whole operating system (Gary Kildall - CP/M) or a word processor (Rob Barnaby - WordStar prior to 4.0 all by himself, the first version in a few months in 8080 assembly language).

Add the line Debug = True in settings.cfg in the Kethane folder. Then you should get the debug menu in map and tracking station views. If it doesn't display correctly, switch back to space center or VAB or SPH then go back to map or tracking station. If it still doesn't show right, quit and restart KSP. When you get the debug menu, there's a reset button you can click until you get deposits where you want them. There's also a function to show the entire grid. Those work on the body the ship you are flying is orbiting. Very useful when all your Kethane on Laythe or Eve is under the oceans.

It does work better with planes that have thrust going than it does flying a powerless glider. It's somewhat like the earliest autoland systems on airliners. It can get on course and glide path to the runway but it's still up to the pilot to run the throttle and the brakes. I put some jet engines on my Rocko Monster SRB glider so MechJeb will fly it instead of dropping it nozzle first into the ocean. Once it gets it onto the path it's happy with I can pop the jets off and sit back and watch it do a perfect deadstick landing. Something to note, a parachute on the back end does nothing at all to yank a glider out of tail down attitude, even with landing autopilot off it doesn't help much once a glider is going down backwards. I tried that because some real planes have used parachutes as an emergency aid to get them out of flat spins or other situations where there's not enough airflow over the control surfaces to regain control of the aircraft. I'd like to see a glidepath virtual HUD so a plane or glider could be manually flown into the position MechJeb can take over from. Real ALS has systems to guide the pilots to the correct altitude/distance for the computers to be able to take over. Newer automatic flight systems are good enough to run the entire flight from start of takeoff roll to landing and full stop. I wouldn't be surprised if the newest ones can also taxi to and from the runway. Look up on Youtube the first Airbus A380 landing at SFO. There's a cockpit video showing the pilot hardly ever touching the sidestick. Some of the time he's using a keyboard - when it's not folded down under the instrument panel. I wonder if they can fly the plane with WASD?

Doesn't matter, the one ship already has pieces broke off that were attached to the pistons so it's going to get disposed of.

I just did a test of a KSP install with no mods other than the latest MechJeb build, MJ put on the pods with Module Manager and Hyperedit so I don't have to launch and fly test ships all the way. A very simple, newly made craft http://pastebin.com/YSAS0PHd with a new name so there's no profile for it. Popped it to a 20KM Mun orbit then I tried to use Maneuver Planner to change the inclination to 2 degrees. What happened? Exactly the same issue I've been having with my main KSP setup. It warped to the node and started to do the burn correctly but when it got down to 0.3 m/sec left it cut the engine to idle, aimed the exhaust at the Mun then sat there gently wobbling around. Sometimes it doesn't even start the maneuver correctly, it'll just aim the engine at the Mun then do the idle and wobble thing. Output log from that flight. http://pastebin.com/dv70aHnU Edit- I bet it's something hyperedit is or is not doing when it moves a craft. Just hit me that with .23.5 maneuver planner has failed to work correctly with every craft I have moved with hyperedit but has worked with crafts I have launched and used MJ to fly to their destination.

If you're using the MJ pod itself as the control point, and it's not aligned so that when the ship is on the pad the navball is 'straight up' and all blue, the ship won't fly right. You have to set control to a pod or docking port or other part that's aligned with the thrust axis. You only want to set control to a side mounted docking port when you're doing things like docking. Which by the way is NOT the problem I'm having with MechJeb's not working with a Kethane salvage craft that has two 16K tanks but works fine with one that has two 8K tanks.

.15d will do... unkind things... to anything you have out in space with IR parts unless you dig through your persistent file to make some changes. I'm going to wait for .16 which will completely replace the previous version.

Try it when .16 is released. All I ever used it for was to spread out the landing legs on one Mun lander to keep it from tipping over. Didn't have a problem with bending or flopping around.

I have to replace my lander that has several sets of two stacked telescoping pistons with landing legs on the ends. I went to fly it off Mun to prepare for offloading the Kethane in it and *pop*, the pistons shot outward and disjointed, ripping off all but three of the landing legs. When retracted the pieces of the pistons just come into contact instead of telescoping together. Definitely needs disposed of and the pistons removed from the craft in VAB before replacing IR .15d with .16.

Something weird with this craft http://pastebin.com/H2waPH3R All stock parts except the two 16K unit Kethane tanks. If I make it with two 8K tanks there's no problem, but with the 16K ones it fails to correctly complete maneuvers in Mun orbit. Put a craft in a 20K Mun orbit (slightly off equatorial) and this one in a 50K or 58K or 20K orbit then try to do a rendezvous. When it does the plane change it'll start the maneuver and burn but instead of finishing it throttles down to an idle and aims the engine at the Mun then will continue to burn while it wobbles the craft around slightly. Stop it, remove all nodes and try again. It may go directly to Hohmann transfer or intercept and do the same thing with flaking out to idling, pointing the engine down and wobbling around. Replace the 16K Kethane tanks with 8K ones and it'll work properly. I've tried shifting parts around, had more reaction wheels, more and less RCS thrusters, tried the Kethane tanks together with more weight at the ends and also using hyperedit to fill the Kethane tanks to see if more mass would help. Having RCS off and just using torque made no difference. Not one bleeping thing I've changed on the craft has made a difference - except for using the smaller Kethane tanks. Why is MechJeb seemingly giving up on the maneuvers? I need the 32K capacity to offload the Kethane from my 32K mining lander so I can dispose of it then fly out a replacement with landing leg spreading telescoping pistons from the newest Infernal Robotics that will use Tweak Scale instead of having multiple different sized parts. I've also seen it do something similar with rocket gliders where the altitude or distance from the runway or *something* doesn't suit autoland so it just aims the back end down and drops the aircraft instead of flying it. Turn off AL, manually get it into a glide then reengage AL and it wrenches it right back to butt end downwards - but when it's right, autoland can glide the exact same plane right down dead center on the KSC runway in a perfect deadstick landing. (I have gliders built on both long stock SRBs and on the ReStock monster SRB, which surprisingly works the best.) Edit: I see build 257 is released. The above is with 255. I'll try 257. Edit MK2: Same fail with build 257. I've tried shortening the length of the ship by mounting the two Kethane tanks side by side with a ReStock rockomax sized bi-coupler. Same problem. Then I tried more power by swapping the poodle for a skipper. Not a bit of change. Every burn it aims the engine at the Mun, barely cracks the throttle and wobbles around instead of rotating the ship to the proper orientation and burning how it ought. If I use two 8,000 unit Kethane tanks instead of two 16,000 unit ones, without changing any other part on the craft it works correctly. The lander I'm attempting to salvage the cargo from also works correctly with its pair of 16K K-tanks, full or empty.

This will also eliminate the stack of pistons subassembly, right?

Breaking old ships is no problem. I only have one using IR parts. I'll crash it then edit the craft to remove the parts and replace them with the new ones.

That's an amazing speed improvement! Over 104 times faster. (12/0.115) Care to share any insights into what you changed to make such an improvement? "objection function"? Sounds like what a Kerbal does when he doesn't want to be sent on a multi-body flyby mission, optimized or not.

I'm trying to do it in a way that doesn't need any plugins, to go with my ReStock updates.