Starman4308

Well, you doomed humanity. No way to make a self-sustaining colony anywhere for decades. In order to survive anywhere but Earth, you need heavy industry, and that means hundreds of thousands of people. No way to get a redirect: you'd need on the order of 10^14 tons of NTR fuel for redirect. You'd basically need millions of Falcon Heavies to redirect by even a few tenths of a meter/second. No way this could ever happen, because it would take something huge to redirect Pallas to an Earth-crossing trajectory, and everything huge is accounted for.

Let me make this clear. With mods, you can do #1 and #3 to a greater or lesser extent. Without mods, you can do a bit of #1, but in a rather tedious fashion. #3 is completely impossible, because in stock, the only source of control is the player. #2 is highly improbable in any scenario: the KSP engine was not in any way, shape, or form, designed to do what you're asking. It's designed for rockets of up to ~500-1000 parts, not a 290,000-part ring around Kerbin.

I'm under the impression that's because stock SAS is rather lacking, and doesn't do well for craft with large amounts of control authority. Be cautious when bumping up gimbal ranges.

1. In stock, the general way to clean up trash would either be with a cup constructed from girders, or the use of a claw. So long as it was picked up below either the debris's crash velocity or the gripper's crash velocity, it should work. Given the ~6 m/s crash tolerance of most parts, this would be much easier if you wrote a ModuleManager config to boost parts' crash tolerances. 2: I suppose maybe if you did some save-game editing to get the parts into orbit. All the parts past physics range (~2.5 km) would go on-rails, and I have no idea if they would remain docked properly. There is also very significant probability of bloating your RAM usage and persistence file to incredible sizes. It would take approximately 290,000 Kerbodyne S3-14400 tanks to circle Kerbin at 80 km. I'm not even sure that would load. My best estimate is 812 MB of just fuel tanks in the save file (assuming ~1400 chars/fuel tank, 2 bytes/character). 3. Not in stock. A mod could do it easy: for example, with MechJeb (so long as everything stayed inside the physics bubble), you could release a missile, switch to it, target your target, go to Smart ASS and point the missile at the target, fire the engine, and then switch back to your other vessel. If you have the scripting chops for it, a kOS script would be a very good option. In general, though, you're going quite far past what KSP was designed to handle. #1 is technically possible, although velocities will be boringly slow without modding. #2, I have no idea how KSP will handle that, because KSP was built around the assumption that you wouldn't have ships so big they extended past the physics bubble. #3 is impossible without mods: you could have a point-and-shoot, but no direction without a mod telling it what to do.

Unlikely, actually. Mods mostly ping on RAM. If he were having RAM issues, he wouldn't be lagging, he'd be crashing. There might be the odd mod which requires a lot of CPU time, but most are fairly minimal. The possible causes of slow KSP are either that his GPU is having trouble rendering stuff (very unlikely with his rig), or that he has a whole bunch of parts. Physics time increase faster than the number of parts, and since Unity physics is single-threaded, that means he can only set one CPU core on it. His CPU is, well, faster than I thought CPUs got without overclocking, but he's still going to run into physics problems when he starts using a lot of parts. At an extremely vague guess, I suspect he could do 500-ish parts without a drop in performance. 1000 parts, and each tick would take significantly more than 2x what it took for 500 parts.

The problem is that Squad can't fix it. It's mostly a problem with Unity, the underlying engine. Squad can't do anything about that short of migrating the engine, which would be an enormous amount of work. I'm under the impression Unity 5 lacks the x64 bugs, but it's not out yet, and Squad is eagerly awaiting that.

#1: It's quite possible to do an interplanetary SSTO, with Laythe being the usual suspect. It may prove necessary to top off the tanks in low Kerbin orbit or in Laythe orbit: I've never tried it before. #2: I have no idea what your problem is, so I'm just going to link you here. #3: Depending on SSTO mass, probably either a mix of turbojets for everything up to ~30km, and a single LV-N for everything past that, or 1-2 Rapiers for light-weight SSTOs. #4: Technically yes, but that's rather unrealistic for many reasons, thus why I'd prefer to use full-up cockpits or capsules. #5: Relatively small wings, loads of intakes. I need to save a link the next time I see guidelines for building SSTOs. The most likely reason you're finding the LV-N insufficient is that you haven't built up enough velocity on turbojets. The typical profile is a dash to 20km altitude, at which point you level off and begin a very slow climb to 30km, gaining as much horizontal velocity as possible, using rate of climb to balance thrust and air intake with drag. Once you're at ~30km and 1500-2000 m/s*, you can switch to LV-N propulsion: you shouldn't need much more velocity from that point. *The crossover point is basically when you can't get any more horizontal velocity because drag equals thrust, and any further ascent would choke off air supply faster than it reduces drag. Your turbojets are likely to be operating at only a fraction of maximum thrust at this point.

If your CPU is tanking, it's probably more number of parts than anything else. FAR does require additional compute time, but not much: again, it's number of parts which kills you*. Engines are more demanding than other parts as well, because they have to scan fuel tanks each tick. I'm not 100% sure how the game engine handles physicsless parts, but I'd assume they still have to have some physics calculations run on them. *I know physics takes more than O(N) time for N parts: I'm not sure if it's O(N*ln(N)) or something else, but the physics time per tick goes up faster than the number of parts.

The basic steps: set up a C# IDE which compiles to the 3.5 .NET framework, and then add two .DLL files from Kerbal Space Program/KSP_Data/Managed: Assembly-Csharp.dll and UnityEngine.dll. Then start plugging away. You'll want to look at the KSP API. TaranisElsu has some demo addons to help you get started, and, in general, you're going to want to spend a lot of time looking at other peoples' code. Just make sure that if you ever copy code, even if it's just a single method, that you obey that person's license. Fortunately, a lot of them are MIT/BSD-style licenses, where all you need to do is attribute the original author and his license. GNU GPL licenses force you to use the GNU GPL license (unless you can get an exception from the author). ARR (All Rights Reserved) means you can't copy any code without the author's permission.

Kerbals and capsules can only carry one of each experiment: you can have EVA reports for three different biomes, but you can't have more than one EVA report for the same biome. Mobile labs can carry infinite everything, so if you're willing to haul along a mobile lab and provisions to get it home, you can truck back a lot of science.

You usually use RP-1/LOX for first stages for several reasons. #1: The primary advantage of LH2 is its spectacular specific impulse of around 450s. This is not very important for first stages: whereas upper stages have to be made as light as possible to reduce mass further down the chain, the first stage can be as heavy as it wants, so long as it gets the same payload to the same place. #2: LH2 tanks are enormous due to LH2's low density. This poses structural/aerodynamic problems. Using RP-1 on the first stage lets you shrink the volume quite a bit. #3: Many LH2/LOX engines are tweaked for upper-stage performance, having high specific impulse, but poor sea-level performance. #4: LH2/LOX is expensive. Probably mostly due to giant fuel tanks, as propellant itself is usually very cheap. You usually use LH2/LOX for upper ascent stages for three reasons #1: That wonderful, wonderful 450s Isp. #2: That wonderful, wonderful 450s Isp. It bore repeating. #3: A lighter upper stage means a lighter lower stage. EDIT: There's also the "long-duration mission" case. Liquid hydrogen and oxygen are both cryogenic propellants, and are subject to boiling off. LH2 boils off so rapidly that it's really not useful past a quick Mun mission without active refrigeration, and RP-1/LOX will probably have issues for anything outside Kerbin's SoI. This is where the storable, often hypergolic propellants like Aerozine50/NTO and MMH/NTO come into play. EDIT #2: To more directly address your specific problem: you're cramming way, way too much into a single stage. Typical first stages are probably going to range from 3-4 km/s of delta-V: the examples you have suffer mightily from diminishing returns. The more frequently you stage, the more frequently you dump off empty fuel tanks and unnecessary engine mass. For ascent, there's also the benefit that your TWR needs go down as you get further through ascent. The primary reason not to stage is that you need mass for staging equipment and your new set of engines: plus, in stock KSP, decouplers are ridiculously expensive.

Not for the forseeable future. Present orbital launch technology is incredibly expensive, and the incentives to go to Mars are just about nil. Unmanned probes can do 90% of the science at a tiny fraction of the cost. Realistically, any manned Mars mission must depend on the development of reliable man-rated systems with much lower to-orbit costs than present launch vehicles. We could​ do it with current technology, with probably 10-20 years of development time, but nobody's going to fork over the money for it.

Well, here's version 0.0.1. Unfortunately, the config file is nonsensical and intended solely for debugging purposes, but in the next week or so, I'll see about preliminary config files for RSS and 6.4x. Please, please put up a post if you think a contract's not getting properly adjusted. There is so much crazy special-case handling for different types of contracts and parameters that I might have slipped in a typo or something. For any contract mod authors who want to make their mod compatible with Renegotiator, the easiest way is to add an rnSit value to your contracts' and parameters' ConfigNodes. This can have the following values, and will easily tell Renegotiator which multiplier to apply. LANDED, LAND_AND_RETURN, OTHER_LANDED, ATMOSPHERE, ATMO_AND_RETURN, OTHER_ATMO, SUBORBIT, ORBIT, ORBIT_AND_RETURN, GEOSYNC, GEOSTAT, MOLNIYA, TUNDRA, FLYBY (note that Flyby is equivalent to being on an escape trajectory). EDIT: That estimate of a week was a blatant lie. It's taking longer than I thought to get the stock dV values, because I'm assuming basic competency: for example, instead of circularizing around Eve and then transferring to Gilly, aerobraking directly to a Gilly-crossing orbit. This involves a scary amount of research into Keplerian orbital mechanics. My easily distracted nature doesn't help.

You added no useful information. It looks like you may have had an overly steep suborbital trajectory based on the high surface velocity at 30km altitude, but I can't be certain. Please describe your trajectory in greater detail than "went up to 100km and back down": that could be a million things, from straight up-and-down to something nearly orbital. I also still​ don't know what's going wrong. Is it heat? Is it excessive G-forces? Is it parachute failure? If I don't know what the problem is, how can I help you fix it?

As far as I can tell, Raptor's configs are designed to be realistic moreso than balanced. If you try to replicate Apollo in RSS with Raptor's configs, your booster will come to just about the same amount of mass as a Saturn V. As such, it's ridiculously overpowered for stock planets: you're probably going to want to either nerf Isp a lot* or install some RSS configuration. *I suspect 0.333 was recommended for people who wanted realistic booster sizes for stock planets. In stock, despite the ludicrously heavy fuel tanks and low TWR engines, you still come off with tiny rockets compared to what real missions would require. The Saturn V had a payload ratio to LEO of about 4%. The Vanguard came close to being the smallest rocket to ever lift payloads to orbit, and the heaviest thing it lifted was a 23 kg satellite, for 10 tonnes of booster.

Thinking about that... it might be good if potential part clipping came up in orange. I've been frequently frustrated by 0.25 refusing to add a symmetrical set of fuel tanks because one of them magically clips into another part. A highlight would let me take a look and see "Is this really clipping, or is KSP just being silly again?".

Realism Overhaul is the most realistic, but Realism Overhaul goes far beyond just giving engine configs to quite radically change gameplay. If you're not looking for the full RO experience, Raptor's stockalike configs work pretty well for most people. I'm not sure if Reaching for the Stars is still being kept up-to-date.

Sounds like a RAM error. 32-bit can't use more than ~3.5 GB of RAM. The Active Texture Management mod can trim down on the size of part textures (which really kill your RAM); otherwise, all you can do is cut down on the number of mods, particularly part packs. One little trick is to delete parts you don't use: the more textures you eliminate, the less RAM you use. More than that, and I suggest making a thread in the modded support forum. I can't help you much more: I use Linux 64-bit. It's a bad situation for everyone: it stems back mostly to the current version of Unity, which has lurking x64 bugs.

RealChute, along with many other mods, is disabled for the Windows 64-bit client. The 64-bit client is notoriously unstable for a lot of people, which led to a lot of bogus bug reports which frustrated modders to no end. StupidChris, along with a lot of other modders, then disabled their mods for 64-bit Windows to save themselves the hassle. Please do not complain about this policy. It has been debated to death and nobody will change his or her mind. You can either use the 32-bit client, install Linux and use its 64-bit client, or remove the check from the source code and recompile at your own risk.

Then make career mode difficult by changing funds/rep/science pressures, instead of just manufacturing artificial difficulty that half the players will solve by just giving themselves enough starting cash to buy the stupid, should-never-have-been-separate upgrades. The launchpad thing is a good example: it forces you to shell out funds if you want big, spectacular missions. Removing SAS is a bad example: it becomes a game of "balance your twitches" instead of trying to focus on your ascent. Same with the orbit lines, maneuver nodes, and patched conics: it's removing basic flight information that literally no astronaut or mission control ever would be without. It makes the game frustrating, instead of making career difficult.

Thanks for the summary! A lot of the changes look to be bad, artificial difficulty though. In a game about orbits, where career mode is the best way to introduce new players, they are deliberately withholding basic orbital information, ability to plan maneuvers, and keep craft steady. It'll make the learning curve even steeper, and will make it far more annoying for experienced players, because they are now lacking basic flight information and flight assistance. It seems strongly like they are trying to shoehorn in their Kerbal experience and upgradeable buildings features, no matter what it does to basic gameplay. I'll keep playing. If the changes go through, I'll just use MechJeb and other mods to compensate. It still doesn't make these ideas good. How I would do it: Keep SAS for all craft. It's just silly otherwise. Limitations on being able to hold different vectors (particularly maneuver nodes) are okay, but otherwise it's just frustrating trying to correct a million little twitches. Keep maneuver nodes, orbital tracks, and patched conics. This is how players can learn what different maneuvers do to your orbits. Not having them is silly. Astronaut complex could be used for training Kerbals in different skills. When a Kerbal gets enough experience, you might train him in holding prograde/retrograde vectors, how to EVA, how to take surface samples, or how to manually deploy solar panels. More advanced astronaut complex means more advanced training allowed. Tracking station might be used to determine how many probe cores you can have going at once, and how far they can get from Kerbin before they shut down.

It really, really, really depends by what you mean on "improve". If you would elaborate on that, it'd probably help come up with ideas. Career-specific mods: Mission Controller Extended Fine Print (which will become stock in 0.90) StageRecovery Science-related SCANsat CactEye (when it finally gets ready for a 0.25 or 0.90 release) Game-altering FAR/NEAR Real Solar System Deadly Reentry TAC Life Support Real Fuels

Please follow these instructions, particularly checking for proper installation and providing logs. Unless you mean "parachutes do not immediately pop out", which I'm pretty sure is intended behavior: if I remember right, the default behavior is to arm chutes when staged (they'll pop open when you reach a preprogrammed altitude or pressure, as set when configuring the parachute). The other possibility I can guess at is that you have Deadly Reentry installed, and your parachutes are burning up the moment they are deployed. In this case the fix is not to deploy parachutes into superheated reentry plasma and wait until you're subsonic (Mach 1 being ~330 m/s, with most people waiting to 200-250 m/s to deploy parachutes).

Follow these instructions to get help: if you've pinned it down to FAR/NEAR, this thread is usually okay. However, it is extremely unlikely that FAR or NEAR is the the root of your problems, on account of FAR/NEAR only changing the aero model.

Can you give us more information about your problem? Could you describe your reentry profile (apoapsis/periapsis before hitting atmosphere), and whether you were burning up or had crew dying from G-forces?