NathanKell

Most satellites, and *certainly* most early satellites, use spin stabilization. And yes, it works decently in KSP, although max rotation allowed in KSP is far lower than the thousand-RPM stabilization something like that would use. Also, time warp kills rotation unless you have skykooler's Time Warp Rotation fix. Wait. You're talking about during *launch*? Satellites are spin-stabilized in *orbit.* Spin stabilization during launch is for sounding rockets and the like that travel straight up, or in ballistic arcs. Not launch vehicles that actually need to control (and vary) their pitch! Just add some non-moving fins to the bottom of the rocket. Rockets are like planes only moreso: you want the CoM far ahead of the CoL. If you're worried about the CoM changing, make sure the CoL is as close to the bottom of the rocket as possible.

If you're using RSS, you're going to want the latest EVE Overhaul and pingopete's RSS EVE Enhancements (available in the Add on Development forum).

There are in general three types of heat shields: Heat sinks Reflective Ablative Now, most combine those. But still. Heat sinks soak up the heat and then radiate it slowly over time. This was the first type of heat shield used. Reflective just means that it "reflects" away some of the heat; not all the heat of the air impact needs to be soaked or dissipated through ablation. Any heat shield worth its salt will be at least *somewhat* reflective! Ablative shields contain a coating of ablative material that boils away under the impact of the air (heating), thus dissipating heat. Sink-type is hard to model in DRE. The closest would be to give a very high max temperature to the part, and decent reflectivity. The others are, obviously, easier. I've added some notes to the bottom of the readme. Check it out here. https://github.com/NathanKell/DeadlyReentry/blob/master/Readme_DREC.txt#L88

AW YISS! Phil Bono time! What parts are separate parts?

You don't want to remove the one for EVE. That will enable default compression on EVE. Also, out of the box, ATM doesn't support EVE Overhaul correctly. *This* is what you want your BoulderCo.cfg to look like: ACTIVE_TEXTURE_MANAGER_CONFIG { folder = BoulderCo enabled = true OVERRIDES { BoulderCo/Atmosphere/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = false } BoulderCo/CityLights/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = true } } } Change scale as necessary if that's too much texture.

If you're installing RSS, I highly recommend installing the Realism Overhaul suite of mods. KSP's fuel tanks and engines are far, far less efficient than real life ones, and also the sizes of pods and the like are far too small for their mass. This means (a) you will need far more rocket for a given payload, and ( reentries will be much harder than they should be since your ballistic coefficient will be higher. Also, you're definitely going to need Active Texture Management; otherwise KSP might not even load. This is because KSP loads *everything* into memory when it starts up, and will crash if memory usage goes over ~3.4GB (it's a 32bit application).

There's no compiled guide. Basically you just add a shield module, tweak the values to taste, and add AblativeShielding if the shield is more than purely reflective. Check out DeadlyReentry.cfg, which does the module adding, for examples.

Given there is a GameData folder in the archive, you should extract the archive to your KSP installation folder (where there is also a GameData folder), thus creating BoulderCo and ActiveTextureManager folders in ksp/GameData/

First: 3 responses, one helpful, one mildly tired of answering the same question (and yes, as you'll see below, you are asking the same question), and one taking the second to task for not being helpful enough. I'd call that pretty polite and helpful by internet standards. Now, as to the issue. You have volume and density mixed up. Hydrogen taking up more volume (being *less* dense) means *less* fuel will be in each tank. And, I'll point out (as Rayder did) that in your screenshot, you have 20 tons of fuel in neither situation. In the first case, you have only 1.1336t of fuel. In the second, you have 16 tons. Next, let's review the rocket equation. The deltaV provided by a rocket = the natural logarithm of (the wet mass divided by the dry mass) times the exhaust velocity of the engine (= Isp * g0, or Isp * 9.80665m/s^2). Why does this matter? It means that if the chemical engine is light enough, and the nuclear engine is heavy enough, the gain in Isp will be canceled out by the loss in mass ratio. Consider an LV-N that massed 100t. Clearly with only a bit of fuel, it will be beaten by a light chemical engine with 20t of fuel, even if the latter's Isp is much worse. Let's compare your cases. Nuclear: ln(9.235 / 8.1014) * 850 * 9.80665 = 1091.668m/s which jibes with KER. Chemical: ln(19.99 / 3.99) * 390 * 9.80665 = 6163.1m/s which jibes with KER. Try with at least 100t fuel (not craft mass, fuel mass), then compare equivalent mass crafts. You'll see the difference.

shult12: Upload your output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log Slam: The reason (as I think I mention in the file and elsewhere) why those start disabled: because it causes bugs. I'm not surprised it's doing that, although I'm not familiar with why the first bug is occurring (the second, presumably, because the recovery code will only let you recover when the bodyname of the body you're landed on is "Kerbin")

No air-breathing engine in KSP (without AJE) is *ever* going to be realistic, because the thrust won't vary with air density. If you want a realistic scramjet...well, it's classified how it works, so nobody outside the aerospace companies / DoD actually knows. But your best bet for now might be to set crazy-high temperature limits for an AJE ramjet.

That somebody is taniwha, and the converter is available in the Tools and Applications subforum.

Heh. Guilty as charged, I'm me. That sounds awesome! My dream has always been to have to do less work^H^H^H^H have other modders support RO "out of the box"--and the best part is, MM2.1.5 allows you to do just that, shipping configs that only activate when RO is installed. In that case if you want realistic-ish thrust ratios for your engines, it's probably something like 24-12-1 lifter/main/orbital. Never used Unity, so I got nuthin. Sorry!

Because Bop doesn't have a heightmap PQSMod applied, so there's nothing to modify.

You're trying to use mods compiled for .23.5 on .23, it sounds like? You're therefore getting messages from CompatibilityChecker (a code snippet from Majiir that many of us use) saying, quite properly, "hey, you're using the wrong version of KSP"

Or instead of the first part you can use b.GetSurfaceNVector(lat, long, 0) to get the vector. That takes latitude and longitude in the same decimal degrees that KSP reports.

I really like these! Especially since the housing at the top is not larger than the bell. I'll put in my usual plea however: please make the nozzles realistic. In particular, your main/lifter (difference?) engine should have about 16x the thrust of the orbital engine, if they have the same nozzle diameter (going by modern engines). (Well, it varies by the difference in expansion ratio obviously, but 16x is a good estimate.) Also the shape of the nozzles will differ slightly, since in essence the orbital nozzle *is* the lifter nozzle, scaled down, with a large extension placed below it. Also, if you're going to be using the stock color palette, why not go SXT's route and reuse stock textures as much as possible? Then you'll not be taking up extra texture memory, so your pack will be essentially "free."

Kerosene has lower performance (lower Isp *and* is less dense) than the hydrazine derivatives; if you're going for cancer-death-stuff already, you might as well make both your oxidizer and your fuel cancer-death-stuff and get better performance. Hazmat suits and clean rooms are a fixed cost, more or less. Conversely hydrazine-derivatives have better performance than kerosene with LOX; but usually if you're using LOX (dirt cheap, safe) it's worth getting another cheap and safe fuel rather than having slightly higher performance at the cost of, err, cost, and also cancer-death. As a general rule, many oxidizers can be used with many fuels. Each has its own performance level, and the combined performance level basically tracks this. Here is a great reference by the awesome Bob Braeunig: http://www.thespacerace.com/forum/index.php?topic=2583.msg17481#msg17481

Nope. That requires change in KSP's code. Ask Mu to fix it.

Not a bug per se, just a weird consequence of how FAR handles drag. FAR applies drag to "open nodes," i.e. attach nodes with nothing attached, as a way of detecting flat areas. This is why adding nosecones in FAR makes you less draggy; you're closing the open node. This is also why setting node size correctly is incredibly important, as otherwise the drag will be incorrect. However, the key thing about this is that FAR also varies what it applies based on whether the node is "pointing" forwards or backwards, i.e. above or below the part's CoM. If it's forwards, it gets a ton of drag; if backwards, only a bit (and some stability increase). Think about the difference between a rocket with a flat nose and streamlined tail, and a streamlined nose and flat tail. The point here is that when you attach a heatshield by the wrong node, FAR thinks the open node is pointed away from the oncoming air on reentry, and therefore it doesn't add much drag at all.

Time Control does all that and more.

Ohyeahalso: EVE Overhaul disables normal maps in scaled space, so there's no shipping them and loading them into memory; they just take up memory for no purpose right now.

In the archive you released, your city textures are 3000x3000 pixels. Your detailCirrus is 1850x1850. Your detailCumulus is 2500x2500. Your DetailVenus is 1736x1736. duna2 is 1600x1200. Oh, and atmo.png is 50x25. So you'd want to rescale the city textures to 2048x2048, the detailCirrus to 1024x1024, the Cumulus to 2048x2048, the Venus to 1024x1024, duna2 to 2048x1024 (stretching it) unless you wanted to to 1024x512 (in either case stretching it), and atmo to 32x16. Also since only the textures folder from city lights is included, there's no cityLights.cfg... But don't worry! These things happen

Grabbing. Noticed a couple problems right off the bat: there's no CityLights folder; instead, the Textures folder that would normally be under it is in the main BoulderCo folder. Inside that folder, you still have the detaillightOrig and darkOrig files; these, even though you don't use them, *will* be loaded by KSP and will take up memory. Axe them. Also, your textures are non-power-of-2. This means that KSP will scale them up to the next power of 2 anyway; they will look bad, and be slower. So you might as well use 4096x4096 instead of 2500x2500. That said...pretty textures, and I haven't even launched KSP yet!

This is dangerous advice because it's order-depenent: if multiple mods change the same file, or one mod mods another mod, you have to be careful about the order in which you apply them (and be careful about un-applying, too, since some changes may be reverted wrongly).