Starman4308

Well, there's that too, but I figured I'd ignore differences in rocket engine performance to illustrate the point about atmosphere.

It may have to do with one of two things: #1: Different symmetry rules in VAB vs. SPH. #2: How the hell are you successfully using 1400 parts in 32-bit? And what sort of monster processor do you have to keep it from slowing down to a crawl? Additionally, .craft files, and possibly logs would be useful.

If you're using FAR/NEAR: S-turns and air brakes are your friend. Stock aero: I would consider vertical S-turns or loops at lowish altitude. As for myself: after having to restart my 6.4x career for mod issues, I launched Vokshod II into polar orbit, and after a successful 12-hour orbital mission, came down at the poles after a rather awkward reentry.

My strong suggestion is to dual-boot to Linux and keep Windows around: I had success with Ubuntu, which is regarded as easy to install. If you're not familiar with the command line and the concept of a package, Linux will probably drive you up the wall a bit, because seemingly nobody in the open-source community seems to understand the concept of an installer. It's also useful to have Windows around anyways so you can natively launch Windows-only programs, without worrying about whether Wine (Windows Is Not an Emulator*) might have some small bug. *Basically a Windows pseudo-emulator which goes about things in a different way. Standard emulators run slowly: they simulate running Windows, a slow process. Wine goes about it by implementing the Windows API: when a program asks something of Wine, it knows exactly how to go about doing that in Linux. It's open-source, which comes with the standard advantages and disadvantages of open-source software. If you have Windows, might as well keep Windows. That said, once I finished dealing with my graphics card issues (highly specific to my weird GPU setup), I have had no issues with Ubuntu, and I only switch back to Windows when I need to run Office. There are a few annoyances, like difficulty tying into Facebook chat on IM programs, but those are mild issues.

You are misunderstanding what is going on. The delta-V requirement for typical rockets specifies a mass fraction, but not total mass. Taking the Ariane V as a guideline, minus atmosphere, we could launch a 1-gram payload on a 49-gram rocket. The reason no model rocketeers have launched 1-gram payloads to LEO is very much atmosphere. As you scale down, atmosphere becomes an increasingly daunting problem: smaller rockets have a smaller inertia-to-area ratio, and have a harder time punching through atmosphere. As you scale up dimensions, surface area exposed to atmosphere, and thus drag, goes up as the square of dimension, while mass/thrust/inertia all go up as the cube, meaning atmosphere becomes increasingly irrelevant as you go big. In stock KSP, if you had the parts (ignoring differences in TWR, Isp, etc) you actually could get away with your 1-gram payloads, because the terribleness of the stock aero model means there are no advantages to aerodynamic rockets. If you move to FAR/NEAR, you would see limits on micro-rocketry, however, because the smaller your rocket, the more delta-V you have to spend fighting aero drag, until you reached the point at which your rocket could not carry a single gram of payload to LKO. EDIT: The reason you see the average air drag losses there is that rocket engineers know this, and very deliberately choose to design rockets large enough to minimize aero drag. If they spend excessive amounts of delta-V fighting aero drag, their launch costs balloon; it would be more economically efficient just to go big from the start, and carry several payloads per rocket if small stuff needs to get to orbit.

As I see it, it's because TAC Life Support is about resource management, and making sure your Kerbals have enough snacks to survive the crazy missions you send them on, while Deadly Reentry is about punishing you for stupid reentries. They both revolve around the life and death of Kerbals, with different flavors of what they're trying to make you do. Besides, the DRE code is already fairly plugged into KSP physics, while, to my knowledge, TAC Life Support has got no hooks into the physics.

Rule #1 of designing in FAR/NEAR: if it doesn't look like a real-world aircraft or rocket, it probably is not going to fly, at least not at any great speed. For example: your bird is a biplane. No modern cargo aircraft or high-performance aircraft (SR-71, fighter jets, etc) are biplanes. It's gotta go: that second wing isn't going to generate much lift with FAR going, and it will contribute to drag. You should also attempt to make the fuselage much slimmer: it's too boxy to be efficient in FAR. Rule #2 of designing in FAR/NEAR: Unlearn everything you learned, and start back over from small stuff. Trying to go straight to monster cargo SSTOs is not going to work. Rule #3 of designing in FAR/NEAR: If ever confused, look at Wanderfound's designs, or pop him a message. Guy's great with SSTOs. Also: Why did you ever install FAR if you wanted to avoid "KSP becoming a flight sim"? FAR is very deliberately attempting to emulate realistic aerodynamics.

The atmosphere on Mars is barely there: it is ~0.006 atm at surface level. This means that, in theory, you could get into Mars orbit with a rocket approximately the size of a pencil. Disregarding practical issues like fuel flow, you can scale down infinitely and retain the same delta-V, so long as your payload/fuel mass and specific impulse remain the same. The reason we need large rockets on Earth is because the atmosphere is much thicker: going through it is about the same as launching through a 10-meter column of water. Scaling up has huge benefits: a large rocket will have a larger inertia/surface area ratio, and as such, punching through the atmosphere is easier when you have a big rocket. This is why the smallest LEO rocket that I know of was about 6 tonnes. On Mars, however, as mentioned, the atmosphere is much thinner, so you don't have to worry as much about economies of scale: a small rocket will still do it.

My apologies. It does sound like a bug. Given that, though, it would be very helpful to follow these instructions, particularly with regards to getting a log file uploaded he can look at. Deadly Reentry has it. If you set the heating-related variables to be trivial, you can have DRE's G-force implementation without the reentry heating problems.

To put a little perspective on 1000 parts, I do research using molecular biophysics modeling software. It is a similar problem: where KSP models and integrates the forces on many spaceship parts over time, biophysics software models and integrates the forces on many atoms over time. A back-of-the-envelope calculation suggested that 1000 atoms would take about 0.5 seconds* for a single core to evaluate. This is with software which is designed to do physics and nothing but physics all day: no graphics, no checks for whether a user is clicking on a part, no checks for whether fuel is flowing, just straight up physics designed to run on a supercomputer. *A few software packages like GROMACS could do noticeably better, but they are optimized at a very low level using SIMD instructions, which are a pain to program with. I doubt the creators of PhysX ever seriously considered using them in their physics engine, because these calculations are not the bottleneck for most games: KSP is, as mentioned, an outlier.

Scientists have recently discovered that Kerbals in orbit require not only snacks, water, and oxygen, but also electricity to run climate control systems, radios, and other such equipment. This fascinating discovery has led to solutions like "Hm, maybe I should put a solar panel on this thing".

That config file changes the DRE-included heatshields to be much sturdier and capable of surviving RSS-level reentries. You almost certainly need either those heatshields, or tweak your DRE config for much less heat generation. Last time I used it, it seemed to have replaced the heatshield decouplers with a a couple which looked like they were supposed to be size-tweakable, but were not size-tweakable (maybe it assumed TweakScale would be there, which I don't have installed).

A nitpick: in theory, if it was necessary to transfer in a single orbit, the Oberth effect might favor multiple ion engines. Point remains though: for maximum delta-V, the ideal configuration for anything is a single ion engine and enough asparagus to feed China for a year. EDIT: I'll assume 5 minutes to cover the 950 m/s to get to Kerbin escape velocity. That requires 3.167 m/s^2 of acceleration. Ignoring fuel loss, your craft would have to be 39.6% ion engines to achieve this sort of acceleration. In reality, that would go down because acceleration goes up as you lose fuel, but it amply demonstrates that, if you want ion propulsion, you are going to have to live with very, very slow transfers. Consider using 4x physics acceleration. The key binding is 'mod-.'; for Windows, mod- is the alt key, for Linux, right-shift, for Apple, I'm not sure.

...your Munar landing legs fry on the aerobrake home, courtesy of Deadly Reentry.

All I know of is just to try visualizing CoM and CoP (Center of Pressure, AKA Center of Lift) while tilting your rocket in various ways. In the VAB, the airflow is coming from the top (in SPH, from the hangar doors). Keep CoP as far below CoM as possible to retain stability. Be sure you are executing an actual gravity turn instead of what stock leads you to believe is a gravity turn. A real gravity turn is to make a 2-5 degree pitch when you're moving 60-100 m/s (higher TWR means an earlier, sharper turn), and then to ride prograde all the way down until you're in upper atmosphere and can, for yourself, decide what the proper pitch is. If properly constructed*, you can actually turn SAS off and go "Look Ma, no hands!", because aerodynamic stability will keep your rocket dead prograde. Technically speaking, if you ever touch the controls after the initial turn, it isn't a gravity turn, it is a pitch profile, though it should work if you always keep rocket orientation close to prograde. If it deviates too far from prograde, you go from aerodynamic stability to aerodynamic instability, and flip in all sorts of interesting, rocket-ending ways. *Has fins to keep CoP below CoM. I loved this discovery. EDIT: These are for RSS, and you'll have to tweak it for stock (stock planets just feel so dinky once you start playing RSS or 6.4x), but are still helpful: Ferram's guide to making an RSS launch vehicle, and his guide to launch profile.

I've been using 6.4x Kerbin (using the more manual install; just now switched to this*) for a while, and the "rescue Kerbal" missions were always at 600km-ish altitude. Even stock Rescue Kerbal missions have been, in my experience, at 100km, which is a touch outside atmosphere. *Broken mod installation = kaboom, might as well restart with this. The configs for EVE/AVP have been wonderful. In any event, I'm presently playing with Mission Controller Extended (it comes with a hardcoded RSS config), so I'll see how that goes.

A workaround for now is to re-build your craft in such a way as to abuse the fuel flow rules for fun and profit. I don't know of such a mod, unfortunately.

Use FAR and more horizontal hops. FAR's mach effects make for gentler reentries.

There is another way to visualize it I like: "It would take Kerbin surface gravity this long to accelerate something to the same speed as the exhaust gases", which lets you tie it back to the exhaust velocity in the other form of the rocket equation.

Possibly screwed-up staging, though the usual candidate for veering off the runway is misaligned landing gear, or having too much weight on your landing gear, causing them to misalign.

Yes. Higher specific impulse is better. Density is mostly irrelevant, although low-density fuels like liquid hydrogen do take a lot of volume, requiring larger (and heavier) tanks for the same mass of fuel. Disregarding the mass of fuel tanks, and assuming identical specific impulse, X mass of low-density fuel gives you the exact same delta-V as X mass of high-density fuel. The sole difference is that you will use a larger volume of low-density fuel, but the rocket equation doesn't care about volume, it cares about mass. Isp/mass is nonsensical. The only thing that matters is the rocket equation: delta-V = G * Isp * ln(full mass/dry mass)

Similarly, are the xenon tanks enabled? Right-click, and if the marker on the right is a little red crossed-O, it's disabled; if it's a green triangle, it's enabled.

Behold! Just make sure your docking ports line up in the VAB, and use that tool to dock with the correct orientation.

It is more accurate to say Ferram intentionally disabled FAR/NEAR for x64 due to all the "bug reports" which were just more x64 instability. For the benefit of Stikkkychaos: Ferram is hardly the only modder to have done this; the instability of the Windows x64 distribution is common, and there are enough entitled idiots with x64 issues to cause every modder headaches. Senshi has released an x64-enabled version of NEAR. If you download this, do be aware that Ferram will not support you, and Senshi will probably not support you either, because Windows x64 is a buggy piece of crap. The alternatives are to use Active Texture Management to reduce RAM consumption, which should allow you to play 32-bit with a bigger stack of mods, or take the dive and install Linux, whose 64-bit distribution has so far been rock-solid. That, or just not play with so many mods. This issue will be resolved when the Windows x64 release's stability problems are resolved, and modders no longer get stupid bug reports from people who are simply running into x64 issues.

As far as I can tell, there is no requirement for orbits to be outside the atmosphere. An orbit simply describes a curved, repeating path around an object caused by a combination of inertia and gravity. Part of the reason for that is obvious: cutoffs for "what is atmosphere vs. space" are arbitrary. It's not like KSP where atmosphere cuts off at exactly 69,077.553m: atmosphere simply tails off into space. The customary demarcation is the Karman line, the point where a typical aircraft would have to fly at greater than orbital velocity to achieve sufficient aerodynamic lift to fight gravity. That is still a fairly significant amount of atmosphere for orbital vessels. An orbit inside thick atmosphere is bound to decay and stop being an orbit, but it is still an orbit.