KrazyKrl

Well, the cool thing about n-body, is that not only does it add cool orbital mechanics. But it's more gooder of learning for the people that do play KSP. Sure, at the beginning, people will feel overwhelmed by Lagrange points and orbital weirdness. But then they will learn that ALL bodies exert a force, and you can use gravity assists from them all at the same time. It'll add MUCH more depth to orbital mechanics. And it would enable something like The Interplanetary Transport Network. Sure, it MIGHT be more complex at points, but it's more realistic; and it adds just so much to the game. Right now the orbits are simple ellipses, and planetary transfers are mundane to say the least. I don't see more complexity in a game where you need to worry about the aerodynamic profile, thrust to weight ratio, and total delta-v of your vehicle; just to make your vehicle launch to orbit. Then just have an ellipse when you approach a planet. N-body would only really apply when you are doing interplanetary transfers. So until you get to that point in your space program, the extra complexity is not very apparent.

I see no reason why the gravity calculations couldn't be on a separate, asymmetrically running thread. The fact Squad hasn't done it already, is because the backend for the game isn't even near being finished enough to start rewriting the game systems. The physics thread itself, could do the very very simple force of gravity on the object. By taking distance calculations to all planets, then applying them to the vehicle. Or, even more efficiently, since your vehicle moves at a small fraction of the precession of the system you're in, it could simply read some global variable from the flightpath thread. It would only need the consolidated gravity vector and strength. And it could interpolate any data it needs, due to the relativity of time. The flightpath thread could do all the n-body physics it wants. It could simply do For each timestep in flightpath, calculate vectors for each planet, calculate gravity for distance, and consolidate them. It's essentially how The Universe works anyhow. Doing n-body gravity calculations is EXPONENTIALLY easier than rigid-body physics. Other than the alpha-ness of KSP (and problems with Unity's threading toolchain,) I see no reason why full n-body wouldn't be implemented at a later date. Which is probably why it's in the do-not-suggest thread.

KSP reaction wheels are quite energetic. And they don't have any of the drawbacks of a large spinning wheel of death causing vibration and energy drain on the vehicle. I'm sure that NASA and other space agencies have researched Reaction Wheels, Control Moment Gyroscopes, and RCS. The fact is, if they could find a way to make Reaction Wheels applicable, they would have. RCS is simpler to implement, and is probably MUCH lighter per unit of delta-v. A Control Moment Gyroscopes has AT LEAST 3 moving parts, the wheel itself, the motor, and the gimballing system. It's KSP that is sacrificing realism for gameplay reasons. When you scale down space travel, lots of weird things start happening. Real spacecraft use CMGs anyhow.

I would be very very impressed if the Interplanetary Transport Network was implemented. I could see the stylized depiction of it on the Wikipedia page as an overlay to the map. It would even incorporate Lagrange points. Since the Kerbal system is known, and on rails. The ITN could be extrapolated long beforehand, and implemented into something like a rainbow table or just a compressed array of precomputed vectors. Implementing this would actually be quite easy, you can keep the current SOI system for rough calculations and general orbits. And when you zoom out into a planetary system scale, it overlays the Interplanetary Transport Network, and applies the proper orbital calculations when/if you intersect it. And, the calculations for the look-up table for the Interplanetary Transport Network could even be cloud computed. i.e. each KSP client could take a job for a time-slice of the age of the KSP system, and upload the data it calculates to a server somewhere. And each client could download said data as needed. Of course caching any data it has downloaded, to be reused locally.

I would suggest something like a quickmenu. 1.) Press a keybind like ctrl-F or B (for bookmarks) Of course it would be configurable. 2.) A menu comes up with a 4x2 or 4x3 grid of buttons. (QWER,ASDF; or QWER,ASDF,ZXCV) Configurable of course. 3.) TAPPING the key would PLACE the item. 4.) HOLDING the key would DISPLAY TOOLTIP (like mouseover does.) 5.) DOUBLE TAPPING, or pressing a number key; would PAGE to another. i.e. you could have the main page, then page Q, with an additional 8+ items. 6.) Pressing the open favorites key would close it, or go back one page. 7.) Pressing anything other than the keys expressly used for the menu, would close the menu from any page. To set the items, you could simply shift-hotkey them. i.e. Shift-Q or Shift-doubletap Q (for page Q, Q slot.) The items themselves could have an overlay of letters, displaying if they are Favorited, and where. i.e. A simple "Q-Q" or "Q" would suffice.

It would be hilarious to see this stuff. Some ideas: 1.) "Do Science!" Kerbal puts on a Lab Coat (over his EVA suit, baa ha), and a table with flasks and stuff just appears. The Kerbal shakes his arms and panics for about 30 seconds, then the table and lab coat disappear. 2.) "25 Hour Fitness" Kerbal puts on one of those "muscle t-shirts" (of course, over his EVA suit again), and begins doing push ups/sit ups/jumps and does "pull ups" on nothing. 3.) "Phone Home" Kerbal conjures up an 80s cell phone, mashes the phone with his fist, then sticks it to his helmet. He pounds the phone on the side of his helmet for a few seconds, before giving up and putting the phone away. 4.) "Pale Blue Dot" (Only available when Kerbin is unobstructed) Kerbal pulls a telescope out of nowhere, and stares at Kerbin through it. Has the awestruck face the entire time. 5.) "The Corned Beef" Kerbal produces a sandwich out of his EVA suit, and attempts to eat it. Of course, he can't through his helmet. Then some random chatter comes over the comms, the Kerbal becomes panicked, picks up a chunk of ground, and "hides" the sandwich beneath it. 6.) "One small step" The Kerbal produces a door out of nowhere, and makes a majestic step onto the surface. 7.) "You Blew It Up!" (Only available at an anomaly) Kerbal acts out the classic Planet of the Apes scene, silently. 8.) "AYYYYY" Kerbal produces sunglasses, puts them on, and does a double thumbs up. 9.) Obligatory Robot Dance 10.) "The Exorcist" The Kerbal turns his helmet 180 degrees, and his head follows it. His eyes go wide, then the Kerbal turns the helmet back to the normal orientation like nothing happened. 11.) Obligatory "This goes to 11!" 12.) "Taxes" A desk filled with papers just appears, and the Kerbal suddenly wears reading glasses. Interplanetary paperwork ensues. 13.) "Fine Dining" A table appears out of nowhere, with a 7 course meal prepared. Kerbal is now wearing a monocle and a Tuxedo (both over his EVA suit and helmet, baa ha) Just having some emotes would be amazing. But are wishful thinking at this point in KSP's life. It would be awesome during the polish phase though.

I have a few feature requests for KER. 1.) Since KER knows your current speed, and density of the atmosphere at your altitude. The addition of "equivalent mach number" would be a nice frill to have. And an easy at-a-glance frame-of-reference. 2.) Since KER knows your current velocity, and atmospheric pressure, it would also be trivial to add a "Max Q" (http://en.wikipedia.org/wiki/Max_Q) indicator. It could read ""Max Q" Dynamic Pressure Record / Altitude of Record". It would be useful if your launch vehicle attains the coveted rank of "Disassembled: Autonomous & Unauthorized" (and you wish to rectify that problem.) Max Q is one of the most likely spots in your flight that you would run into engineering problems. Speed of sound at 3.101 kPa of pressure: 346.1 meters/sec. Equivalent mach speed: Mach 3.341

For my fattest launches, I like to put several sepmotors on the tank I'm jettisoning. It keeps the tanks from "pinching" the center main engine, they fly out and away. (30 second MSPaint jobs are worth about 20 words.)

As long as you have all your first stage engines identical, you just need one fuel line per outer tank to drain into the center tank. The outer engines will draw from the outer tanks at the same rate. The inner engine will draw from the inner tank, then the inner tank will draw fuel via the fuel lines from the outer tanks. You do not ususally need more than one "parent to child" relationship in a series of tanks. The fuel lines should always be set up to prioritize what tanks you drain from and jettison first.

It's pretty simple, and already explained well enough. I personally use Kerbal Engineer for a decent readout during launch. It has way too much information to NOT use.

I meant using the target system to make an easy inclination change. Since if you burn at the intersection, all your delta-v goes into changing your inclination; it's efficient, and you don't end up changing your Pe/Ap, unless you want to. Once you get the major delta-v spent on getting the proper inclination, radially burning to the proper orbital intersect is trivial.

An easy stock KSP way of easily changing your inclination would be to set the Mun as your target(0 Inclination). Place a maneuver node at either the ascending node, or descending node. Then burn normal or antinormal as needed.

1.) Already sufficiently answered by the other replies. 2.) You can think of the fuel tanks as "heat sinks" that conduct heat away from a heat source. 2b.) It's probably because they have no current value of something like "thermal dissipation." So what ends up happening, is that a large tank, and a small tank have the same thermal dissipation values. So a large tank has, say, 500 Joules/second of dissipation; but so does EACH small tank. So the thermal cooling rate is double, when it shouldn't be. It is technically a bug, but it's due to the game still being a work in progress.

Judging by the technology in KSP, a better fit would be the space-race era of hardware. It would just fit so much better.

Remember that on the space shuttle the engines are only lit during ascent. The vehicle is not designed for massive inclination shifts or extra-orbital travel. The space shuttle main engine is vectored quite significantly to offset the weight of the main tank. You could have, say, 3 engines though, 2 being ascent engines that are tilted, and a third one in-line with the vehicle itself. But the space shuttle design itself was pretty flawed. It's a cargo hauler design that is very unsafe in practice. NASA is going back to the old, disposable, vertical launch vehicles. And they are going to use the much safer dual launch system with orbital cargo rendezvous. It's easier to abort a launch when you can just decouple a capsule and hit the ejection tower SRBs. Instead of needing to move the shuttle crew on two decks to the hatch so they can bail out.

You can just add some heavy lift engines for stage 1, and fuel line them. Unlaunched fuel is wasted fuel. You can just, say, stick 5 mainsails onto decouplers, and fuel line them. Burn your tank dry, jettison, then you'll be at a pretty decent height. The first 12km is the most difficult anyhow. Fuel adds delta-v Engines add thrust Everything else is extra. But you need the extra stuff to make the craft do anything.

Ouch. Mine, ironically enough, was a successful docking.

I have not used Kerbal Orderly Parts before, but I'm having some trouble. I have not tested the sorting in-game, as problem #3 worries me about possible file corruption. I'm running KSP 0.20 with these mods: KW-Rocketry-v0.2.33 KW-Unofficial-.20-Fix Protractor-v-2.4.1 KSPX 0.2.2 KW rocketry(and fix) is contained in KSP\Parts. Protractor and KSPX is in KSP\GameData\Protractor and KSP\GameData\KSPX, repectivly. Running Windows XP32, I am having a few problems with KOP 1.4. 1) Loading the first time, and immediately after removing sort data, all my parts are there. KW rocketry engines are in the Pods section. Only the KW Ullage Motor is in Propulsion. KW Fairings and Structural are in the Control section. KW stack separators are in the structural section. KW nosecones are in Aero. 2) Tooltips do not work until I close and re-open the sort window. And then click another section's button. Tooltips start working then. 3) Every time I close and re-open the sort window, the complete set of parts gets repeated, collated. I.e.: S.A.S Module Large S.A.S Module Large ASAS Module, Micro ASAS Module, Micro 1 2 3 4 Additionally, only the last of the duplicate entries is able to display a tooltip. I.e. SAS Module, SAS Module, SAS Module, ASAS Module Micro, ASAS Module Micro, ASAS Module Micro. Tooltip Tooltip Removing the mods, of course, solves problem #1. Problem #2 and #3 are persistent even with the stock game without mods.

I think it's the known issue here: http://forum.kerbalspaceprogram.com/showthread.php/30762-Switching-Views-between-vessels-causes-explosion-0-20

My friend used to fall asleep to the "Breezy" theme from Final Fantasy 8. It's very mellow, and very nice.