Galane

You meant that's not a Ferris Wheel that failed? From this angle the R&D center looks like an amusement park... Ah ha!That's what's needed in the game, an amusement park where all the rides are rocket powered!

You'll still need some struts but not as many and you shouldn't have to use struts just to hold certain engines in place against their sometimes rather violent thrust vectoring forces. KJR makes it much easier to use lots of Mainsails without having them rip your rocket apart. It also makes it much easier to use radially attached fuel tanks. Just stick them on, no struts required! (Most of the time.) The big Kethane drills will just stick on and stay put, can even mount engines to their bottoms and they'll stay put. There's still a bit of an issue with sticking things to the ends of Stretchy Tanks, but Ferram says he's working on it. I like using the Quantum Struts mod. A few well placed ones of those can replace a spiderweb of normal struts. Two things about them, they're super rigid so whatever forms the other sides of the "triangle" between the strut generator and where its other end touches needs to be quite rigid. Too much flex and the quantum struts can jack your rocket apart on the pad. The other thing is to not mount them on nor allow their beams to contact the really tiny mass parts like the Octagonal Cubical Strut. Weird physics happens and the ship will not rotate at all. This can be used in a beneficial way by assigning a strut in such a configuration to an action group. Turn it off before launch then when you want your ship rock steady to be docked to, turn it on. Won't need to use RCS or reaction wheel force to stay still. (I haven't actually used it as a rotation lock for docking, but have tested the effect on a simple test probe in LKO.) The Strut Guns are also highly useful. I mount four on top of landers, around the docking port. It makes the docked crafts a whole lot more stable, especially when docking a third craft to two already docked. They can also be angled for acceleration bracing when you're docking a bunch of things together for an interplanetary trip. Quantum struts can also be used for this task. Just four of those and a clampotron Jr between two orange tanks side by side can withstand the shear forces of a mainsail or a skipper and four LV-T30's - when used with KJR. KJR won't prevent every breakup. I pushed the parts count limit for my PC with my Duna mission. Got quite laggy in a turn and it couldn't keep up with all the calculations. Parts began to slide and.... oops, there goes a whole fifth of the ship flying off, despite the quantum struts that were holding it.

How about a heavy planet landing guidance module that's a bit more aggressive with the throttle and more profligate with the fuel? The way it lands on Eve, ships have to be insanely over-engined to slow down enough from the altitude MechJeb starts the final burn. Any ship that can lift itself even a bit off Eve's surface with full tanks should be able to land safely (even if it doesn't have the fuel capacity to get back to orbit) if it has enough fuel to start its final burn high enough. Even dropping a ship from 50 meters at 0 starting vertical velocity, it has trouble getting down to the surface without damage. I've had a look around the forum and there's some relatively light ships which people have been able to manually land on Eve. I put this ship minus crew into a 100 KM Eve orbit with hyperedit, kicked off the stages and MechJeb didn't start the final burn until just over 1,000 meters. Almost but not quite high enough to avoid disaster. Crew would have survived but not much else. Had lots of fuel left at lithobrake. I wanted to see how high it could ascend when full, then build on it until it could reach orbit - then figure out a way to get such a lander to Eve from Kerbin. My next interplanetary mission is going to involve a one way lander probe to Eve and it'd be nice if MechJeb could land it without having to put a dozen engines on a small probe. Won't matter to me if it burns every drop of fuel, as long as it lands OK. The docking autopilot in build 119 is very nice. Much less jittering about and it also looks like it can coast for a while without lots of RCS firing.

One thing the KSP UI desperately needs is for buttons that toggle the state of things to show on the buttons themselves their state. As it is, no button using the built in KSP theme/style does that. Some change a tiny icon (enabling/disabling a fuel tank), some change text next to the button. Some, such as Control From Here, change *nothing visually*. A toggle button should in some way emulate the style of a real pushbutton that locks in when on and pops out when off. That way all the player has to do is right click a part and at a glance can see the on or off status of all toggle-able functions. In the case of Control From Here it would definitely show which part has control, instead of the current system where it's impossible to know by looking at or reading the popup menu on control pod parts. There's a huge number of ways for a GUI button to show its status, but the least ambiguous way is to alter the look of the button itself. One very common example is in multimedia programs where something directly on the Record button turns red. It's an emulation of the red light on physical equipment that was often mounted in or behind the button. There's a long standing convention in GUI design for functions that have two or more settings or options. Where only one of a group may be active, the selection graphics should be round. They're called "radio buttons" after the station selector buttons on old car and home radios where only one at a time could be pushed in, which would pop out the previously pushed in button. Before GUIs on computers, round circles were used on paper forms where only one in a group should be marked. Radio buttons should show a solid dot when selected. When any number of options in a group may be selected, the selection graphics should be square or square-ish and are called checkboxes after the square boxes on things like paper forms with lists of things where you may check all that apply. Checkboxes should display a checkmark or X or some other mark that doesn't nearly fill the box to avoid any visual confusion with radio buttons. Like toggle function buttons, radio buttons and checkboxes visually display their change of state. Clearly and unambiguously displaying the status of things, and sticking to the radio button and checkbox convention (no mater how creatively designed the graphics are) enables the user/player to *quickly* see how things are. That speed can be vital in KSP when you have only a short time to avoid disaster. I've used and worked on computers for 30+ years. Software that goes by these simple conventions is easy to use. The major point of a GUI is that once you've learned to use one, you can quickly learn any other - as long as it uses similar techniques for how the controls operate. But then the two biggest proponents and implementors of standardized GUI design have often drastically broken their own rules. Yeah, I'm looking at *you* Apple multimedia apps (all of them from Quicktime 4 on) and Microsoft Office! Google User Interface Hall of Shame.

Did this with .21 as a challenge to myself to build an all rocket SSTO capable of reaching a 71KM orbit on MechJeb 1.0.9's default ascent path. Many hours of building and rebuilding and a lot of launches went into this before I got enough fuel on to where it would finish the circularization burn without having to stage off and finish with the lander. The lander design was done first and tested to land on Kerbin. Then I just got the idea to build an SSTO launcher under it. IIRC it's all stock, unless the reaction wheel on top of the lander isn't, that might be a ReStock part. I just tested it in .22 with dev build 118 of MechJeb 2.1. Terminal velocity limit off (it can't hit it anyway), corrective steering on, don't edit the ascent path, go for 71KM orbit. http://pastebin.com/EzkWZks7 Finally! Successful single stage to orbit! Booster core after staging off. It has three OKTO2 with 100 unit batteries so it can be deorbited using the small amount of fuel left. If the large decoupler was swapped for a RockoOKTOClampo and the lander modified to be able to dock to it amongst the upper tanks (perhaps just extending the clampotron up on a girder and adding strut guns or docking struts), this might be usable as a return from somewhere stage, assuming there's a way at somewhere to refuel. Would also have to refuel this beast in Kerbin orbit before taking off to somewhere. The launchers is also easy to reconfigure to asparagus staging by moving and removing some fuel pipes and altering the radial decoupler staging. I did that and IIRC went to Mun with it for my second manned Mun landing to plant the "What? This place again?" flag. If you do something with it, I'd like to see pics here. I should try moving some of the radial decouplers up to the lander stage to see if the booster can be kept all together.

I'm still waiting for an update for any changes in .22 textures.

If you want to read some stories with giant planets, Hal Clement did a few. Most notably the novels "Close to Critical" (1968), "Mission of gravity" (1954) and its sequel "Star Light". (1971) Close to Critical is set on a giant planet with a very deep, very thick atmosphere where the rain comes in boulder sized drops that slowly drift towards the ground, and that's just a small part of the weirdness, including a surface temperature of just over 374C. Mission of Gravity is set on a giant planet that rotates very quickly, so quickly its shape is distorted into a very oblate spheroid. Centrifugal force reduces the apparent gravity at the equator to merely 2.5 G while at the poles it's hundreds of G. The author's calculations when he wrote it estimated the polar G would be around 700, but other people in later years, with computers capable of attempting the complex calculations for such a planet come up with a somewhat lower number. The plot for that book is an experimental probe for studying the high gravity landed at one of the poles, then shortly stopped transmitting. Intelligent natives were discovered and their aid enlisted to recover data from the probe. The natives develop their own plans for the knowledge the humans are sharing to help them on their journey to the pole. Star Light casts some of the same crew of Mesklinites from the previous book. Since they're from a world of high gravity, extreme cold and atmospheric pressure, they're the ideal explorers for the giant planet Dhrawn. It doesn't spin fast so it's a proper round world, but it's covered in ice and has an atmosphere with a lot of ammonia and poisonous oxygen instead of the methane of their home planet. Once again the Mesklinites have plans of their own for Dhrawn. Harry Clement Stubbs was an astronomer and chemist, flew 35 B-24 Liberator combat missions in WW2, taught astronomy and chemistry for many years, and amongst all that wrote hard SciFi, usually involving very out of the norm worlds and odd quirks of chemical reactions on a giant scale. He also tried to start a shared SF universe. With Mission of Gravity he opened Mesklin to other authors to write stories, but AFAIK, nobody did.

The Only Flying Space Car That's Taken Anyone To Another World. (Explained Using the Ten Hundred Words People Use The Most Often.) http://xkcd.com/1133/ "This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today."

The landers I was testing were all stock, originally done in .21 before I had any mods other than MechJeb installed. When dropped from 50 meters (starting at zero velocity) with hyperedit, they can land but the legs sink into the surface. After the few successful times using that to land, I refilled fuel with hyperedit and they could lift off. Wouldn't get too high before running out of fuel of course, but it showed that TWR should be high enough to land without breaking things. If MechJeb would start the final burn high enough to slow to .5 meter/second at touchdown, and if the legs wouldn't sink, it wouldn't take higher power engines and gobs of fuel to land on Eve. Lifting off, well, that's a whole 'nother design problem. I don't have Two-Step lander in a craft file by itself. Will remove it from a ship and post it by itself later. Edit: Eh, whatev on posting the lander on its own. Here's the lander on top of its SSTO launcher. http://pastebin.com/EzkWZks7 Many hours of building and refining and launching went into getting that to where it'd make it to a 71KM orbit without any staging. Just set MJ's ascent guidance to 71KM, terminal velocity limit off, corrective steering on, don't change the ascent path. It'll also work in .21 with MJ 1.0.9 and its default path. That was my goal, build an all rocket SSTO that'd work on MJ's default ascent path. Launcher is easy to remove, pull one of the stack separators off a side tank, then yank off the center one. Reconfiguring this to asparagus staging is a simple job of removing some of the pipes that loop the fuel around, and altering the staging position of radial decouplers. In SSTO form the big central decoupler could be swapped for an ROC so that after staging off the lander (leaving a large core section intact) it could be used for a return from somewhere stage. 'Course it would take a big tanker to refuel this thing before going somewhere.

I tried some landings on Eve yesterday. MechJeb build 118 was full of fail at this task. It saved plenty of fuel, it was so miserly it wouldn't begin the final landing burn until about 2,300 meters. Too late to slow down quite enough to prevent destroying or knocking off parts. If it'd start around 3,000~3,500 I bet could manage to land ships without enough fuel capacity to get back to orbit. But then there's the other issue with Eve. The landings were complicated by the stock heavy landing legs sinking into the surface, causing engines to be destroyed or knocked off. I used hyperedit's ship lander to test designs attempting to compensate for that and discovered something nifty about my Two-Step lander. After dropping it into Eve's ocean, popping it back to 100KM then locating co-ordinates for some land, I tried the ship lander again. I didn't notice one of the three side tanks and its engine had been lost. It managed to touch down upright on just the poodle, two 909's and extreme use of RCS. I gotta try that trick on Kerbin. Alan Aerospace Recycling and Packaging will continue our quest to land on Eve (and hopefully return to orbit) without any of those wimpy non-thrusty things like parachutes, wings and balloons - when we figure out something for landing gear that won't sink into the surface.

I did some Eve lander testing yesterday, attempting to design one cable of landing there without parachutes. Got enough thrust and fuel to *land* but MechJeb won't do the final landing burn quite soon enough and things get a bit broken. So I resorted to hyperedit's ship lander. That brought the landers down safe - until the legs sunk into the surface so far the engines would hit and get destroyed or knocked off (in spite of KJR), and did it again more times despite adding more legs and positioning them lower. The R&D department has plenty of work ahead to come up with an Eve lander design that uses thrust only. No chutes, no wings, no balloons - nothing but thrust.

Here's a lot of photos of assembled and painted old model kits from decades past, from a time when by the far future of 1980 we were supposed to have colonized the solar system! http://www.fantastic-plastic.com/1960s_concept_spacecraft.htm http://www.fantastic-plastic.com/new_page_1.htm

Could probably install KAS then send a supply ship with some sepratrons. Have the guys remount the seps to fire at that girder to destroy it. Be throttled up and ready on the space bar soon as it blows. Of course building a test fixture at KSC to see if sepratron exhaust will destroy one of those girder adapters would be a good idea before spending the time to send some to Duna, only to find out they won't work.

If you plot a course for Jool and end up at Duna... ...You might be a Kerbal!

"This is ground control to Major Jeb. Can you hear me, Major Jeb?" "This is Maj... uh what? Since when are we in the army?" "Hah! I win the bet! Nevermind that, we've uploaded a new patch to the autopilot. Set up the Duna to Ike transfer again and see if it works." "Copy that! Node in T-3, 2, 1... YEEEHAWWWW! We are GO for Ike!" *in Ike orbit* "Y'know, Bill, since we're here, may as well poke a flag into Ike." "I'm all for that! I want some gravity under my feet again." Kethane lander on Ike. All three landers docked. The lag and lack of strut guns on the kethane landers made docking the second one very difficult. Had to shut off SASS on the big ship just before docking to keep kill rot from shaking it all about. Product Testing showed that upper 64 tank and four boosters aren't needed to get back to Kerbin. With the RockoOKTOClampo I could cut that loose then dock the manned lander to the top of the four-pack of 64's. With 124 days to go until the return window, It's cleanup time. Grabbing one of the boosters in elliptical orbit around Kerbin in order to deorbit it. PS. The mission is named DunaRuna 2 because the test design and assembly in Product Testing was DunaRuna and there were some significant changes from test to 'real' mission. The DunaLite heavy kethane scanner satellite and its booster are still in LKO. I know it can get to Duna with plenty of fuel to spare, where else might I send it? It does have two empty clampotron jr ports I could dock some small things to. It predates the ROC so I can't pop the satellite off the nose and dock something else to repurpose the ship. Could send up a robot... (AKA editing the part name in save to swap it out.)

That would work. I hadn't envisioned things like building large constructs of I-beams and girders to knock all off at once. Perhaps amending the rules to the craft must be launchable? Launch to Kerbin orbit *then* use Hyperedit to move it? Is there a list of minimum safe orbit altitudes?

So far I haven't had any phantom launch pad impacts with KJR. I have had one parts monster of a ship come apart during a maneuver under thrust, but that was most likely due to lag and the CPU being unable to keep up with all the position and rotation calculations so it let some parts 'slip' then when it got back around to checking them it saw they were out of position and decided they no longer needed to be attached.

What seems to chew up the CPU time in KSP is it calculates the position and rotation of every part to multiple decimal places, even going into scientific notation. Welding a bunch of parts together drops those calculations down to one set for the welded assembly. Open your quicksave or persistent file in a text editor and you'll see how far out it's running those numbers. The power of your CPUs ability to handle huge numbers of floating point calculations is what determines how many parts the computer can have visible at once before it begins to lag. If there was a way to have the game only calculate to four decimal places on everything, I bet it wouldn't affect accuracy but it should speed things up.

Nope, because you're just removing "excess" parts, not lithobraking or destroying the entire ship. Essentially what Matt Hall did in 2010 in Canada at the Red Bull air races. Won't hurt to try it and see if it's possible.

Build a spacecraft with parts sticking out so they can be clipped off on the tallest points on the airless bodies in the Kerbol system, without crashing the ship. I'd suspect that you wouldn't want to use the Kerbal Joint Reinforcement mod for this. Any mods you want, especially Hyperedit to quickly get the ships to their targets. The setup. Get to a safe orbit altitude. Reduce altitude until you knock off at least one part then climb back to your original altitude. Cannot use hyperedit to set the almost crashing altitude or to climb back to the safe orbit. 5 points for each part knocked off or destroyed on each run. Only one run per airless body goes to the total score. Make as many runs as you need to score. Quicksave shall be your friend here. 100 point bonus for knocking off parts on every airless body, but not using the same ship for all the runs, even if it's the same design. "Gone in 60 Seconds" Bonus Award. 300 points for going to a 70+ KM Kerbin orbit and safely landing the entire remains of your ship after smacking it into every airless body in the system. Named for the original 1974 movie where a single Mustang was used and all the crashes were done with it (including one unplanned accidental crash that knocked down a streetlamp) in the order they appeared in the film, so there'd be no "magic damage" vanishing then re-appearing.If you do it all with one ship, and without using hyperedit, you win the internet. Challenge inspired by a "Dude?! Where's my spaceship?" event where somehow my ship orbiting Ike had dropped below 10,000 meters and was a few minutes away from crashing into a mountain. Plenty of time to save it but KSP would "helpfully" preemptively delete the ship upon loading the save. I hit F9, ship was back, so I launched a lander to rendezvous and halfway through it just stopped. "WTH? Where'd it go?" I reloaded again and switched to the vanishing ship, then noticed the altitude at 9,800-some meters! *engage panic mode* Set SASS to aim the firey end downwards then throttled up until the altitude climbed high enough, then circularized. *whew* Dunno how it got down to that altitude when I'd left it safely in a 15KM orbit the night before.

There's a balance between the size/mass of a ship and the amount of control authority you've built in - reaction wheels and/or RCS. Not enough control capability will make the ship slow to maneuver and will have MechJeb overshooting corrections during ascent, and being late on close together engine burns because it can't turn in time. Being a little short on RCS does seem to make docking go smoother, as long as you start with good alignment then have the target set to kill rotation. My initial Duna mission plan involved sideways docking two stacked 64's, with a Skipper, four FL-T800 and four LV-T30's on the lower one, to a clampotron jr halfway up the upper 64, with only four ReStock 5-way RCS blocks on the upper 64. MechJeb's docking autopilot handled that far off center load perfectly, but slowly. On the other hand, having too much RCS for the mass can make docking very jittery with every correction overshooting the docking axis. If the autopilot is instantly applying counter thrust to every RCS thrust, you've too much RCS. On the subject of force roll, it looks to me as if that function in SASS is now aligning to the current SOI instead of the target. I noticed that when refueling my Duna ship in Ike orbit that SASS would align the landers with the moon's equator, ending up at some odd angle in relation to the ship they were aimed at, but force roll in docking autopilot always aligns to the docking port's orientation. For example, if you don't have a target set, have SASS on OBT and prograde then enable force roll, it'll roll ship to 0 degrees of whatever part is set as control. Type in 90 and it'll roll 90 degrees. Set control to a docking port then set a docking port on another ship as target and SASS doesn't align the roll axis to the targeted port. SASS force roll to target alignment would be a useful option, especially when manually docking a ship with an overabundance of RCS thrust such as the small RTG power pods I added to my Duna ship at the last minute. One more radio button on the SASS window... representing some more code behind the scenes. ;-) Nearly impossible for docking autopilot to manage. I did the second one manually in a few seconds simply by TGT+ on both then thrusting forwards while controlling roll with Q and E. Used only a few units of fuel where DA nearly used the whole 100 by the time it managed to dock the lightweight module.

My last landing on Ike was in a green hex but the drills wouldn't bring up any Kethane, so I had to reload my save and land elsewhere.

Oh good! I have a ship stuck at Duna because the #%@# game insists on only allowing me to target Mun from Duna orbit, and MechJeb can't plot a Duna or Ike to Mun course.

If a cell is tapped out, will it turn to white if a scanner scans it again?

So it'll automatically go to auto from TGT+ when enabling docking autopilot?