UH60guy

I'm getting this with and without using MechJeb. MechJeb and Alarm Clock are my only mods. I plan a maneuver with advanced planetary transfer, and the node shows up as usual. Plot looks good and leads to an intercept. Whether I have MechJeb do the "execute maneuver node" or I do it myself with just SAS heading hold, I get about three quarters through my burn when several things happen instantly and simultaneously. First, the targeted planet is un-targeted. Next, the maneuver node pops instantly to a new heading several degrees away. Third, the delta V required jumps up to a few thousand m/s to some seemingly random number (maybe the original dV?). Obviously if SAS-follow-node or MechJeb is on, I'm thrown way off course as they follow the new node to nowhere fast. If I free hand it and just hold the original heading, I have to guess my way to engine cutoff, as I'm now no longer pointing towards a node and my dV countdown is inaccurate. This only happens during interplanetary transfers- in system works fine. It happens on every ship, not just one in particular. Any ideas why a new maneuver node is created mid maneuver? If needed I can upload a video- it's a large file and I'd rather see if this description suffices first. Thanks!

Mulbin, what are you using to create your decal labels? I really like your attention to detail on the label and bracket of the SAS RCS R/W grouping. Looks very professional.

Who cares if they're functional, I want MOAR SWITCHES! Looking at the Apollo CM schematics, there are 16 switches to operate the RCS system. There's an interesting way to try to fly. Here's a (very!!!) rough draft of how I plan to lay things out functionally. It's based on the Apollo CM layout for the most part- staging, abort, fuel indicators, VHF comms, docking controls and a few other things are in the same general area. Of course there is plenty of artistic license, and thoughts of where I'd like to make sticky decals for gauges. Everything color coded is tied to a KSP control group somehow, and the white switches/pictures are intended to be functionless switches to feel more like a real spaceship control panel. I've decided to expand the radar grouping to include the map, switch spacecraft, EVA/IVA and camera views since they seem to be what I use primarily when docking. Plus, "camera" and "target sel" sound more radar-y if I label the switches as such. I'm trying to hide the pure simulation buttons the best I can with similar names to real functions- though there's still a grouping of buttons for time incr/decr, pause, and possibly quick save/load that I haven't figured out how to disguise yet. I counted the planned button uses, and as long as I use joysticks, that gives me 30 functions. That's perfect, since the circuit board I wanted to use can interpret up to 31 button presses and translate to USB joystick output. I'll hide a powered USB hub inside the panel, which should have input from the circuit board plus the attitude/translation/throttle joysticks and have a single output to the computer. At least that's the plan... I think the next step will be buying a few switches and getting the exact measurements. That way I can start putting together a CAD drawing of the panel and really get the size and exact layout locked down.

One thing that I'm going to try to use, to make it easier as a first-timer, are preprogrammed circuit boards designed for flight simulator. My hope is to use spring-loaded switches that look like actual toggles, but function as a single key press, tied to these pre-made circuit boards that are purpose built to give keyboard/joystick outputs. As long as I keep the joysticks on a separate wiring thingy, there won't need to be any programming or need to lean Arduino stuff on this particular build.

Well, I'm going for something similar to what Mulbin is working on here, but without the awesome dials he is making and with more switches and more angled like a flight/cockpit panel. I doubt I'll get anywhere near as awesome results as he is getting, but hey I have to post something to keep myself accountable as I try.

OK, first planning attempt. I'm grouping all the controls, plus common action group functions as normal controls, in attempt to figure out the critical parts of the panel. So far, I've come up with the following groupings: Attitude Joystick SAS [*]Propulsion Throttle dial Throttle Chop Stage Toggle Engines (action group 1 and 2 as my personal default use) Placeholder/decal for fuel gauges [*]Abort- single button with dial dictating function Off Return to Launch Site / Launch Escape System (abort button) Trans-Oceanic Abort (action group 6) Abort to Orbit (action group 7) Return to Orbit (action group 8) [*]Power Panel on/off Panel lights? Spacecraft lights Solar Panel Extend/Retract (action group 5) Placeholder/decal for battery gauge [*]Space Operations RCS On/Off RCS joystick Fairing Jettison / Payload Deploy (action group 4) Docking port activate (dummy switch) and undock (action group 3) Placeholder/decal for radar data (target distance and relative velocity) Placeholder/decal for RCS fuel gauge [*]Landing Parachutes (action group 0) Landing Gear Brakes Ladder extend/retract (action group 9) Placeholder/decal for radar altimeter, maybe vert/horiz velocity, and time to impact [*]Simulation Trackball or mouse Time incr/decr Map Pause Camera and EVA/IVA controls Switch vehicle I'm making some sketches, with the general concept of the attitude joystick and trackball on the right. RCS and propulsion/throttle will be on the left. That seems to make the best use of how and when I use two hands (launch is attitude/throttle, docking is attitude/translation). That leaves a good portion of the center for either notional navball and orbital parameter gauges or some of the misc groupings.

Well, I've never built anything like this before but I bet it will be fun to try. So, in the effort to hold myself accountable, I'm posting my intent here. Now, I don't move into my new house for three more weeks, so that means while I can't start to build yet, I can get some serious planning done first. My intent is something that looks/functions like a combination of the Apollo Command Module and Lunar Module, minus the gauges. If this initial project works out, I'll make a mark II with the gauges integrated into the panel, but for my first build ever, gauges are a bridge too far. Here is my inspiration: Here are high-res links to the NASA site with Apollo Command Module and Lunar Module control panels. Of particular note of what will influence my build: Two joysticks (like LM cockpit) for attitude and translation Guarded switches (like CM) Switches grouped by function (like both) Switches to control the panel itself hidden amongst the others (maybe a fuel cell control or something as a disguised panel on/off switch) Some extra functionless switches for cool-factor or action group use (VHF radio, radar, and an Apollo 12 memorial "SCE to Aux" switch) Action group switches will not be numbered buttons, I will hide them as I commonly use them for things like engine on/off, extra abort modes, parachutes, undocking, etc. Maybe some decals of gauges for appearance, since functional ones won't be in this build attempt. I will sneak in a space shuttle style abort button. It will be a rotary button to select abort mode such as Safe, Return to Launch Site, Trans-Oceanic, Abort to Orbit, and a space lander specific Return to Orbit option. Now this is a long term project with no guarantee of success, but time to give it a shot!

My stations are usually the start of the debris field- I've destroyed three stations now by forgetting to disable engines and trying to take screenshots. On the Mac, F1 requires pressing Fn-F1 , and Fn is juuuuuust below Shift which engages the engines.When various docked engines facing various directions all fire up.... kaboom.

I would love to be able to put a "this end up" and arrow on a rocket. While we're talking decals, tweakable paint colors would be fun too! (could be implemented as large wrap-around decals)

Some terrain mapping stuff would be a good addition if cloud cover ever gets implemented. Imagine if all you could see at Eve was the cloud tops on the map view. Even from a ship in orbit, you still have no idea where it will land (splash?) unless you had the right instruments along for the ride. It would certainly bring a little more life into the necessity of probes, which many argue are too weak in the science system- with probes, you're more likely to risk a blind landing. That could open up some new planning tools on the map window. Similar to how the Kethane mod toggles the scan view, maybe the planets could appear as fuzzy atmospheres on the map, and the player could toggle through science instrument/telescope views to plan their landing, and if necessary, "see" through the clouds.

Oh, much of this could be done with regular staging, but timers would eliminate the frantic spacebar mashing I'm prone to do during aborts. For example, my standard abort setup is a tower that fires sepratrons and pulls the capsule free of the main stack. This gets it away from the explosion in a jiffy. However, usually my parachutes are high on the staging list, and I don't like to waste an action group on them. So, for low altitude aborts, I have to resort to spacebar mashing and hoping that I can get through like 5 or 6 blank stages (as the rocket's exploded and separated) after the capsule separates just to get the parachutes. I'm normally very safe and never launch without an abort system. My only fatality was from a near-pad abort, where the capsule escaped properly, but I couldn't mash space fast enough to deploy parachutes. A timer could have been set up to deploy after the sepratrons cut out. Adding a timer would have saved lives! Lives, I tell you! There's Kerbal blood on my hands! Has my space program learned nothing?

Here's my take on it. Note, I don't know anything about FAR, but I've studied aerodynamic engineering and I hear FAR is a decent model. Your plane looks wider than (or just about as wide as) it is long. That's a big no-no in supersonics. That's why it's trying to align with the flowstream along its long axis (the wings). If your brain can handle it (it's tough) google the Whitcomb Area Rule. Boiled down, it says in essence the ideal shape for a supersonic body is a long cylinder thingy with pointy ends on each side. Now, that's a model of the cross sectional area of the plane. So, to keep the cross sectional area constant across the body where the wings stick out, real world supersonic aircraft have Coke bottle shapes (the fuselage gets a smaller cross section to make up for the cross section of the wings). Bottom line, go for long and skinny, not short and wide. Also, any excessive control inputs you make at those speeds won't help much! You don't have a lot of maneuverability in KSP until you get subsonic. Edit: it could also be incompatibility between FAR and other mods you are using. Again, I haven't used FAR or your cockpit, so who knows. Edit again: Now that I think about it the Area Rule is about low supersonics, you are in the hypersonic range there. I never got to that point in my studies, so this is talking out of my lower extremeties, but I'd agree that you may have too many control surfaces. Any small deflection is going to have big implications. And, depending if FAR treats them differently from the wings, think of it as a large "something" about the same size as your wings which the model is treating in a different manner.

Then again, just because we can't see a reason *yet* doesn't mean new gameplay couldn't emerge from wild and crazy ideas people come up with. Yes, automatic delays would be friggin awesome for emergency aborts when things happen very quickly. But there could be uses for other parts too- off the top of my head, delayed landing gear extension could be used from a probe mothership dropping a few lander/rovers. One button to stage, and staggered delays kick the parachutes in enough to gain some separation, while an additional tweakable delay on the landing gear lowers the landing gear of the smaller ships from their in-flight stowed configuration. Delayed engine ignition following a staging event could be really cool for things like an X-1 / X-15 / SpaceShipOne style mission, where a mothership drops the main rocket, it falls for just enough time to get separation, and then the engines kick in. I love the idea of optional time delays on parts.

I make em strictly utilitarian- science module, a few seats in a hitchhiker, and a LOT of fuel. They look like those jacks toys or an asterisk, or the above poster's picture. I don't have a picture of my own handy- but the "core" is a node with conical adapters and clampotron seniors in each of the 6 directions just like the above one. From that central core, one direction has a science module, hitchhiker, and cupola tower. The other five directions have large orange tanks with large RCS tanks. Each orange tank has medium size clampotrons on the sides so smaller ships can dock, as well as large docking ports on the outward end of the fuel tanks for the bigger ships. Basically, my goal is to get a refuel star/asterisk/jack in orbit around each planet to serve as refuel stations for return trips. I launch at least one orange tank to planets during each launch window. After I've gotten stations established at Moho, Eve, and Duna, I came to realize the only one I never used was the one at Kerbin. It's just simpler and fewer steps to launch a refuel shipment from Kerbin direct to my ships rather than deal with supplying a refuel station.

Oh, don't get me wrong, I love my rovers- I just mean that there's no career incentive for them. As in they don't enable us to get much extra science, except where a few biomes come close together. Even then, the size of the biomes means you're likely only to cross the border into maybe one more (like how you drove from shore to water for example, or flats to slopes on Minmus), again making the rover not that helpful. Usually people seem to make the point to point hopping lander to collect multiple biomes oweing to the distances involved. I agree rovers are great for bases- but again, without long-term science or "contracts" implemented yet, there's no actual incentive for bases or space stations either, other than for our own amusement. Giving something like a scattering of "things" to collect within a radius of say 1 or 2 km in order to return science, and within a single biome, would give that gameplay incentive (not just a "for fun" incentive) to make them useful.