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.

I agree- as it is now, there's no gameply motivation to ever build a rover. Maybe it could be implemented with using terrain scatter as items you need to collect. Just like how the Mars rovers drove up to several rocks, we could be credited with doing the same. There a rover becomes a real gameplay incentive- sure you could walk all around the area, but if the devs increase the scatter juuussssssst enough, it will be a pain for the player to collect all samples by foot in a single mission- leading to a real incentive to having rovers.

I guess it would depend on exactly what's going on inside the engine to make the heat- Remember that ISP is basically a function of engine exhaust velocity. Sure heated particles would vibrate faster, but they're vibrating in all three dimensions while being expelled at 7856 m/s (ISP 800 * 9.82). Not sure that an engine running any hotter could influence how fast the chemical/nuclear/magical reaction expels particles. What it could influence however, would be the amount of fuel undergoing reaction, and therefore the mass flow rate- basically changing the TWR with how "hot" the engine is running.

Not to mention, landing to find and collect specific *things* (resources, science objectives, anomolies, Macguffin, etc) gives rovers a use beyond just a gameplay choice. As you look at it now, rovers contribute nothing to the stock career game, and give no extra science beyond what you'll collect. If you have to land on a planet and find that your *thing* is 2 km away, well then- now I bet you'll wish you designed that nice rover!

It's not too bad once you learn what parts both float and have high crash tolerances. Also, you really have to bleed off almost all speed before touching down. On your landings, get as low as possible, cut the engines, and hold the nose up just enough to stay at like 3 meters altitude as long as possible while bleeding off velocity. I can't remember, but I think I had to get this baby down below 30 m/s or so to land safely. At that point, the nose-up attitude would pose more of a danger of knocking off my rear engine. Same goes for takeoff, you have to get up quickly while watching your angle of attack- again this means you need a lot of horizontal space. Gun the engines, and keep holding back on the stick to get the nose just above the surface so you both get the structurally weaker parts away from the water sooner and get airborne before your velocity gets too high. You really have to go slow while in contact with the water or any craft will break. For an example, here's a low part count, stock seaplane I made. Note the I beam, structural plates, and landing gear assembly. This allows it to both land on the runway and to float.

Yes, the bracket keys switch between craft, even on a MacBook Pro (I use one too). Try right clicking (or with track pad on MacBook, two-finger click) on the node itself. You should see the option to decouple. If that fails, try the other side of the node (ofen only one docking port gives me the option to decouple). It will also only work if you are "flying" the rover and not the Kerbal on EVA, so make sure you have the right vessel selected. If that gives you trouble, go to the tracking station and select your rover/lander from there to be absolutely sure. Where you may be doomed though, is if you are out of electricity. Check your resources- if you don't have any juice left, it may not let you decouple. Also, if there's something structural blocking the rover from detaching, it may be permanently attached.

I'll add that MechJeb can still assist you with the calculations- use the current spacecraft mass readout to get the starting mass for the equations. Be careful with using the fuel readout to get your "empty mass" The tricky part is for interplanetary probes and ships you need to calculate the mass of only the fuel you want to burn en route. Simplest math is a "big orange tank" carries 32 tons of fuel. So, if you only plan on burning one BOT, your "empty mass" is your total vehicle mass minus 32. For this purpose, only subtract the fuel you plan to burn on the interplanetary flight- any fuel in landers, tugs, etc. needs to be included as spacecraft weight, because in this case it's actually payload, not something you plan on burning to get to your destination. Repeat the above if you have multiple stages, though for large docked ships, it's likely you'll already know the delta V of your subcomponents. Like me, after docking, I want to make sure the mothership has the delta V to get where it needs to go, and then not worry about the smaller parts. So, that's why the above tip only focuses on the interplanetary portion of your mission. Note that engine ISP is not additive. For example, if you use one LV-N, your ISP is 800. If you use 8 of them like I do, your ISP is still 800. The number of engines only changes your thrust to weight ratio, not your ISP. It gets more complicated though if you use multiple engine types. Just put this in any calculator, or even better, an excel spreadsheet: (9.82 * [engine ISP]) * ln ([total mass from MechJeb] / [mass minus mass of fuel you want to burn])

I agree with all of the above, an see your point on the levels of brightness. I wonder if it could be implemented as a "sliding scale" based on the camera orientation. Such an implementation would also allow for the stars to be washed out when staring at the sun, but come into view as you turn away. As it is, you can't see Jool against the background stars when in space heading for it, where it should probably be one of the brightest objects relative to the background stars.

Right, that's the meaning of "grand tour" I was going for- as used in the real-life Voyager probes where they called it a "grand tour of the outer solar system." I recognize it's come to mean something different in the KSP lexicon, where it does imply a landing on each and every body. My goal is a cheap probe to blast off and get readings in space "high above" multiple planets and to simulate a photo run like Voyager did, using minimal fuel or course changes to accomplish. In this case it's a personal challenge of orbital dynamics rather than a challenge of designing landers and recovery for each body. Thanks for the tips with the website, I'll have to tinker around quite a bit, and I'll be sure to post something if I can find a once-in-a-lifetime launch window like they did for Voyager.

First off, I am aware of the Interactive illustrated interplanetary guide and calculator for KSP and the Launch Window Planner. Both are awesome tools and I use them heavily. What I am looking for is to see if anyone knows of the next logical step in these... basically how can I find a launch window planner for a multi-planet probe? Failing that, is there a good equation to use to get the optimal day of the transfer and flight time? For example, it could be applied in a Duna/Jool/Eloo probe thusly (simplified here, though I'm sure you'd need a little fudge room for non-optimal transfers): (planets abbreviated by first letter) This is a grand tour launch date IF KD burn date + KD flight time = DJ burn date AND DJ burn date + DJ flight time = JE burn date Such a launch window would greatly save on DV requirements, as you wouldn't need to circularize at the planets en route, and just use gravity assistance and correction maneuvers to go on to the next one.

I’d like to be able to see the planets from farther away. I’ll admit- I have a little ritual every time I approach a planet or moon for the first time. I find its location in the map view, and as I approach the SOI, I switch to IVA and try to spot it. There’s something fascinating about watching it come into view for the first time, I have no idea why. However, they seem to be harder to see than they should be. As it is now, the planets don’t really have much of a realistic apparent magnitude other than the rendering distance. Think of how bright Venus is from Earth, owing to its dense atmosphere. Eve and Jool should be readily visible from the skies of Kerbin as bright slightly off-white dots. Even bodies with high albedo like Minmus should appear brighter than they currently are from some distance. Heck, look at the moon tonight, and compare its brightness to Mun from Kerbin. Something as minty-green and bright as Minmus is should be more visible from Kerbin than just a flickering pixel. I’m not asking to increase the draw distance across the solar system or anything, but a bright spot in the sky (replaced by the 3D model at a reasonable distance) would be an interesting addition to add a little realism. Similar to how the map view planet circles disappear when you zoom in, the artificial brightening of the celestial body can fade as you close in.