Galane

Pre-stacked telescoping pistons? Still haven't managed to get the two smallest sections to stack. A precisely aligned stack of all 9 sections would be ideal to have in subassemblies. Place and tear off however much isn't needed. Like a piston Post-It pad.

It's a limitation of KSP. Only the current ship you're "flying" is fully operational. For close in work like docking you may switch back and forth once they're within 500 meters and the docking will proceed. (With MechJeb doing the docking autopiloting.) AFAIK Kethane doesn't do that even if you have two or more miners down within 500 meters of each other. Same thing with the Kethane scanners. If you want to scan somewhat faster, launch one into a polar orbit, one between polar and 45 degrees and one between 45 degrees and equatorial. Switch to each in turn and crank up the time warp. Using various orbits like that overlaps to help fill in what each one misses and you can do some small plane adjustments to catch more missed spots rather than shifting the plane of a single satellite all over the place. For Minmus I just sent one satellite with one large scanner and a big fuel tank. For Mun I put a pair of small scanners on a mining rover and used it to scan the Mun before choosing a place to land. First thing I did after installing Kethane was launch three scanning satellites over Kerbin. Second thing I did was grump a bit over how only one at a time worked. ;P Once you have the planet or moon mapped, may as well deorbit the satellites, unless you're doing science in career mode or put ISA MapSat on the same bird.

This should be all stock. http://pastebin.com/Yda16emj It's the rover I used to place the beacons. I used hyperedit to put it in Mun orbit, then landed with MechJeb to drop the docking port mounted beacons. The way it's built, would be no problem to stick a rocket underneath to get it places the normal way. With the beacons dropped and less than a half tank of fuel it can do a Mun escape to Kerbin orbit by going straight up. (I was trying to crash it for disposal, didn't expect it to just fly away.) 16,000 unit Kethane mining rover that has trouble hitting targets with MechJeb. http://pastebin.com/5YpBZwGi Mods needed, Kethane, Stretchy Tanks, KSPX (for the reaction wheel on the bottom), this thing and possibly ReStock but maybe not. I've built too many things to keep track of what's in all of them. I could post the 32,000 unit lander but it definitely needs ReStock, adds Infernal Robotics to the list for the landing gear extensions and has the spring strength increased to 10 on the stock landing legs. (I'd also have to yank off its special parallel stack launcher and save it as just the lander if you'd just want to test the lander.)

The trick to a MechJeb landing on Kerbin without parachutes is to ensure the part of the ship you'll be landing has enough fuel to make it down, at least after the initial deorbit burn. So do the deorbit burn and when MJ shuts it down, quickly hit the spacebar to jettison the deorbit stage. If you have enough fuel and a TWR high enough, MJ will safely bring your ship down. Put a little power and a probe core on the deorbit stage and MJ can land it too! IIRC I had it bring the lander down first, then the deorbit stage. It parked it perfectly upright just on the engine gimbal, no RCS, and then it didn't fall over. That's a two stage lander. It has three radially mounted engines and tanks which are used for Mun landing and Mun Liftoff, then they're popped loose for the single engine to take over. This pic is from the final test to ensure it could land on Kerbin, before it went to the Mun. MechJeb's landing accuracy tends to vary between pinpoint precision and missing the target by several kilometers. I dropped a couple of beacons consisting of the thin probe core, a clampotron jr and a PB-NUK on the Mun. (Likely didn't need the RTGs since it's possible to target a powerless but remotely controllable ship.) They're about 3.5 KM apart and I'm lucky if MJ will put a lander within a kilometer of either one. Here's some previous version of MechJeb being a little too precise on hitting its target. Fortunately I was able to drive it off then back the first one out of the way and use RCS to flip the second one upright after it tipped on its side while driving off. If it would hit those beacons like this all the time, that would be very nice.

I installed it, made a little rover and drove around KSP some. Not enough traction. There's room in the cage to fit two seats in tandem. Never used those seats before, how do I get Kerbals in them? The extension parts need some work. The bottom pipes don't visually connect and there should be another one at least 2x the length. Stick that on the front and the short one on the back and the frame would be proportioned like an actual dune buggy. Another finishing touch would be to hollow out the collider mesh on the extensions so it has an open or depressed top so they can be fit over other parts like sticking an engine on the back of the cage then adding the extension.

Looks like Phong shading in the video. Phong smooths the rendering of all edges no matter the angle. It makes everything look like a pillow.

What wheels need in the game, mainly for looks, are left and right versions of wheels that have a unidirectional design. Here's a challenge, do the in KSP.I have noticed there is something hinky with the stock wheels, or perhaps there's gravity/physics weirdness around certain sorts of Mun crater rim terrain. While experimenting with rover designs I try to dispose of failures by jumping them into craters. Problem is much of the time by the time they get near the crater rim they'll heel up on one side then turn sideways and roll, slowing down too much to make a Dukes of Hazzard style jump to their doom. Tried using docking mode and with SAS on. SAS somewhat suppresses the trying to imitate and Joey Chitwood but they'll still twist sideways then roll.

THIS! Just the thing for the Kerran race flying buildings in KerbCraft... ;-)

Hubless wheels! Needs a steerable suspension mount to make them fully usable as wheels but still very cool as they are. Here's another odd wheel concept. http://www.gizmag.com/roadless-adjustable-wheels-all-terrain/29607/

Having some big improvements to the spaceplane and rover sections would be most welcome. As it is now, pretty much all the plane function does is put it onto a heading. It doesn't hold altitude or attitude or do landings, at least not very well. I tried using Ascent Guidance with the stock planes but all that does is flip the plane up on its starboard side then execute a right angle turn. Managed to slam right into the VAB once. Would be nice if the game would at least leave scorch marks. Rover guidance could use a cruise control, operating throttle and brakes to maintain a set speed, even when freewheeling down hills. What I've found is less grabby than the brakes is disabling all or most of the motors at the front and pulsing in reverse to slow down, sort of like old west pioneers dragging a log behind a horse drawn wagon. Such a control would have to have an adjustable brake and throttle pulsing control since those are full on or full off. It'd also need to check whether or not any of the wheels are off the ground and let off the throttle or brake because that's a likely indicator the rover is about to go end over end. There must be some weird physics around crater edges on the Mun. I've tried lots of times to do a Dukes of Hazzard style jump to dispose of rovers but most of the time when I get close to the edge the rovers will tip up on their left wheels, spin sideways and flip over instead of going straight off the edge.

Try it under the ReStock Thundermax tanks. http://forum.kerbalspaceprogram.com/threads/47942-0-21-ReStock-Parts-Pack-%28v08-28%29

Is that kommit's stockalike cubical strut part in the middle?

RCS thrusters in KSP violate Newton's Third Law of Motion. It doesn't matter if their exhaust hits other objects, it causes no push force to be transmitted to what it hits. Exhaust from the other engines does work that way, and if you flame it long enough the object(s) being hit by the exhaust will be destroyed.

There's a Smooth Throttle option which will slow down the rapid throttle changes, but it doesn't help with the instant full throttle at launch. It may help keep rockets together that crumple during staging when MechJeb slams the throttle full open so quickly.

The design thing is with KSP in general. I've used computers for 30 years. There are accepted design elements for how buttons of various types should look and function. For groups of "radio buttons" it's supposed to be that only one at a time in a group may be selected, and that each group should be visibly delineated. When you have a group of options where any or all may be selected, they should be checkboxes. For all the other buttons that are in the KSP game itself - not in any mods - their use is inconsistent in the way they indicate if what they control is enabled or disabled. I do know what I am talking about when it comes to user interface design, especially having dealt with so many that break from long accepted standard design conventions. Usually it's because it "looks cool" or because whomever designed it either hasn't bothered to learn about accepted practice or figures they'll just do it however they like. If you want people to easily grasp the use of your interface, it's important to stick with the visual elements used by most software - no matter how different you make the colors and graphics.

Atlas F missile silo website. http://www.atlasmissilesilo.com/ These missile silos need some blast door art. http://observatory.designobserver.com/entry.html?entry=6697

Have a look at IKFast which is a tool in OpenRAVE.

Inverse kinematics would be awesome. Command a docking port or KAS connector on the end of a jointed arm to go hook up to a matching target and the IK takes care of the joint motions to get it there.

Why? For science. http://www.gizmag.com/uw-penetrator-asteroid-sample/29643/

There's an issue with docking two ships that have IR parts. The control lists merge and the window expands. When the ships are un-docked the control windows don't shrink back to their original sizes. Dock three or more ships with IR parts to a station and it gets to be a big problem. What would be very useful is if the IR windows had a way to minimize them to a small thing, especially in the VAB and SPH. I keep having to move it around so it's out of the way and also be careful to not move it over the vehicle because of it not blocking "click through" and yanking parts off when I'm wanting to move the IR window.

Like self-ambulatory Weighted Companion Cubes, only not so cube shaped.

I've run through a series of all in one Kethane mining rovers, started with a 4,000 unit model that went through some revisions, then a failed 8,000 unit design with two 4,000 unit tanks, followed by a single tank 8,000 unit model and a single tank 16,000 unit rover and finally a 32,000 unit dual tank lander. All of them eventually successful but the 4K and 8K ones don't haul enough Kethane to be worth the trip up from Mun and the 16K and 32K ones suffer from the needs more fuel/add more fuel/needs more fuel to lift the extra fuel loop. As they are, they need to sit and make fuel for a bit to rendezvous with the tankers/refineries in Mun orbit. The first 4,000 unit versions don't have an onboard converter so they can't make fuel and don't carry enough to get back up to orbit after landing. They do work on Minmus, enough fuel to get down, tank up on Kethane then lift and rendezvous then refuel from the refinery. So last night I tried my Kethane drilling rover with two heavy drills and a DROMOMAN+Infernal Robotics docking arm along with a 32K lander with its two heavy drills removed and a couple of side mounted clampotrons added. (The rover turned out to not be able to reach the top mounted port, even after I took out the short girder supporting the port.) Results were disappointing. Aligning the port on the arm and on the lander weren't too difficult. I positioned the camera behind the port and drove back and forth a few times to align sideways then used the arm for fine sideways alignment and to adjust for height and tilt. The problems came from the ports not wanting to lock together. I had to nearly crash the rover into the lander and come close to joint failure on the arm before they'd connect. That ate up quite a bit of time, so did landing over 3KM away from the rover. Not wanting to have MechJeb land ON the rover, when it got to just before the final descent burn I quickly aborted the landing then clicked land somewhere. (Need to develop a low profile, self sustaining, targetable beacon.) Once connected I transferred all remaining rover fuel to the lander and jettisoned the rover's tanks and engines. (With Seperatrons so they'd go high and crash land. I like self-terminating debris.) Tanking up on Kethane proceded same as with the drills on the lander. The last nail in this project's failbox came when the lander hardly used any less fuel getting back up to orbit than it did as an all in one with the two heavy drills. After making delivery and refinement of the 32K units of Kethane I crashed the lander then blew off some time driving the drill rover to destruction. I'm thinking I should bring the whole operation down to a 10KM Mun orbit from its current 15KM orbit. Think that would make much difference in the rovers' and landers' fuel use? How do you go about mining Kethane? Everything on the same vehicle or leave vehicles on the surface to do the drilling and other vehicles to carry it up to orbit or do you refine it on the surface and carry the fuel and other products up to orbit?

That's a common tactic by opponents of various government projects. Force reduction after reduction in the number to be procured, then rant on endlessly about the "cost overruns" and how expensive the thing is per unit. The ultimate goal of that sort is complete cancellation of the project, like they got done with the Comanche helicopter that would have replaced all the various attack helicopters used by the US military with a single type. They nearly got the F-22 Raptor killed off. The numbers that will be built are so small the plane will be next thing to useless should China decide to get militarily uppity - or if aliens with a bad attitude come calling. The F-35 Joint Strike Fighter is actually accomplishing what no previous multi-service aircraft plan has managed to do - have versions for the Air Force, Navy and Marines while maintaining a very high percentage of parts commonality. The Army isn't allowed small, fixed wing aircraft with the ability to blow #@%$ up. Burt Rutan designed the as a CAS aircraft for the Army but they declined to buy it. If it doesn't have a wing that spins or a massive cargo hold, it's not for the Army.Of course there are programs that need to be put down. One older one that suffered from massive feature creep was the Main Battle Tank 70 or MBT-70. Too complex and too expensive, even were it to be bought in large numbers. After its failure the military decided to pare down to essentials and got the M1 Abrams. In later years there was the Crusader Howitzer. Technically it was amazing. It had the capability of firing up to eight shells in series at differing trajectories so that they'd all land on the same target simultaneously. The downside? It was too large to transport on any military cargo plane (not even the C5A Galaxy) and was also too large and heavy to cross most of the bridges in its intended Eastern Europe theater of operations.

Majiir, can you *please* post the fix for that in the first post so perhaps people won't be asking this almost every day? Look for the animation module in the part.cfg for kethane_heavyDrill and change it to this MODULE { name = KethaneDrillAnimator DeployAnimation = idle DrillAnimation = idle0 }

Those options are like check boxes*. If you don't want MechJeb to do anything at all, you have to click all those to clear the dots from the circles. Of course then it's up to you to control the throttle to avoid smashing your ship from too much throttle in the lower 3rd of the atmosphere. *User interface convention fail. Using the common "radio button" circle with dot for check boxes. Check boxes are typically square and indicate to the user that any or all in a group may be selected. Radio buttons are round and indicate to the user that only one in a group may be selected - like the old radios with round station preset selection buttons. Push one and whichever one was previously pushed in pops out. Yup, the people who came up with these grew up with such radios and these two types of selection widgets have become standardized in graphical user interfaces. Mixing up their usage tends to confuse people - especially people who have been using computers for many years. Which brings up an issue about KSP in general. It's filled with toggle buttons that don't indicate their status. They act like a momentary button, they have a clicked state but do not have an *active* state. The buttons all return to their un-clicked state. Some have a *very tiny* icon somewhere else that changes, some like Set As Target change the text on a popup window but others such as Control From Here have no state indication at all. The quickest fix would be to just have all the buttons stay in their clicked graphic state when the user has clicked them to change things from their default state. I'm a big fan of software being as informative as possible via the use of text, but a quickly discernible graphical status indication is also a good thing so the user doesn't *have* to read the text or look for a difference in a tiny icon that's not on the button. Like an old radio selector button, the button itself tells its own status. Better than a black button with black text that lights up black saying "Don't press this button again.".