bewing

Heh. Well, I'll admit to checking once a day. But if you read the devnotes on the Daily Kerbal, any programmer would have to realize that they are still at least 10 days out.

Landing a jet is a bit tricky. Once it's on the ground, a jet makes a great rover -- especially with a wheesley reverseable engine. I'd forget anything beyond that. Retractable landing gear on the back end is also very nice -- when you are parked you retract the gear and then you can walk off the plane and back on again. Crank the brake torque up good and high on the rear wheels for extra braking stability. Oh, and put the rear landing gear way out on the tips of the wings -- the wider the stance, the more stable it is. You can put another pair of landing gears partway along the fuselage for outriggers. (Actually, I find rovers to be 10 times more difficult to drive over terrain than a jet. Rovers have no traction, and I can and do drive jets up 45 degree slopes.)

It takes some care to make your drills run in the background, unattended. You need to leave them alone for 6 hours at a time and have enough ore storage. You also can't access any other craft within 2.2km of the drill, or the drill will retroactively stop. If you can't live with those restrictions, then you have to sit and watch the drill run -- and the big drills run 5 times faster. Yes, you can timewarp to the limit of your timewarp, but it's still a long time, even with the big drills. All the while your contracts are ticking. Do you really want to wait a Kerbin year to fill one tanker full of fuel? And the whole "running the little drill at night" thing is just one more reason to use the big drill. If you want to play fair on electricity, then the big drill gives you 5x more ore output per hour during the day, so you can just turn it off at night.

In my current game, I rescued 7 engineers in a row, then a pilot. So I had to hire 2 scientists at max price (ouch!). But I like engineers, because I do a lot of ore mining, so I was happy. I specifically research my probe cores very early, because they are on the tree below the accelerometer, and I try to get all my science equipment ASAP. A 0-star pilot is basically worthless compared to a HECS. So my pilots are obsolete almost from the beginning of the game -- they are only good for flying my jets. I never even bother sending them into space. I kinda wish the game would let me know beforehand what profession the rescuee is -- so I could skip the pilots and excess engineers or scientists. But that is naughty of me, I know. It's kinda good that you only find out when you're 2.2Km away from the poor little helpless dying victim.

I agree with Rizzo -- to heck with the runway; I don't care what its basic mechanics are. The only reason to upgrade it is to have bigger planes. The grass allows you to land or take off in any direction you please. A perfectly nice 3 Km runway in every direction. 6 Km if you come in from the right direction(s).

Maybe they could have higher tech versions (deeper down the tech tree) of the science instruments that can withstand higher temps (and higher impacts, and have lower masses, & etc.), but you need to unlock them?

There are already mods that do add clouds, and they already do make you pilot blind through them. So obviously programmers in general are capable of just throwing them in on a whim to see whether it works out or not. Squad may not be that cavalier, but I think a bit of concern is justified.

I am concerned about the concept of clouds in the game. IRL, you have radar to tell you if there is a mountain in the center of that poofy cloud or not. If we have clouds but no radar, we're flying blind -- which is significantly worse than reality.

Heh. Did I mess up my book reference? Oh well, it's been 30 years since I read those silly books.

You might want to read about Ringworld in Larry Niven's "A Mote In God's Eye". And the sequel, where he had to go back and add fusion ramscoops to Ringworld, because the physicists told him the concept was gravitationally unstable.

I switch to sandbox mode. I need to know if my booster stages are going to be sufficient to get me to LKO. I want to know where my apoapsis is going to end up after my launch. Any special tasks to do during launch. I need to know how much fuel the top stage is going to have once it's in orbit. I need to know how much fuel it's going to take to get to an encounter (and how long the burn will last), how much to close the orbit, how much to descend to a low circular orbit. How much will it take to burn to 0 orbital velocity. How much to get any landers to the ground -- all with safety margins. All these things can only be found (approximately) by experiment. So I design the top stage, guess at the boosters. Launch it. Do a quicksave just before I start burning liquid fuel to close my LKO. If it gets to orbit properly, I get as many numbers as I can, do another quicksave, try a transfer orbital burn. Then I go back to the quicksave, turn on the infinite fuel, and do it again. Then I have fuel remaining to do all the testing at the destination, and get those numbers. I also get to see if I forgot anything on any of the ships. Retro thrusters, solar panels, see if the ladders work, or if I can fly around on my RCS jetpacks. Then take the ship's .craft file and move it back to my career mode game, and use it.

Build a multi-use rescue vehicle, with a klaw, a girder, a couple of gigantors, and a decoupler on the nose (along with other stuff it can do after the first mission). Go klaw your lab. Detach the klaw and gigantors. Suddenly the lab has lots more power, forever.

The problem goes like this: (1) Reentry heating (watts per second) = drag * mass * velocity^3 So, issue 1 is that we don't know the drag of an EVA suit. I guess we have to assume the .09375 metric ton mass is correct. (2) Basic elevation of temperature = ( (Eq. 1) * (seconds in atmosphere)) / (thermal mass * specific heat) But the thermal mass is the mass of the suit without the kerbonaut, and we don't know that -- or the specific heat of the suit (but it's probably pretty low). And the number of seconds in atmosphere depends on your exact trajectory. We probably also have to assume that there is not enough time for radiative cooling to make any difference at all. And then we need to know the temperature limit of an EVA suit, and we don't know that either. So, unfortunately, the only way to calculate all these unknowns is to aerobrake 100 kerbonauts in carefully controlled fashion and see which ones don't make it.

How do you poke the wiki staff? There are a bunch of new spam pages.

As said above, adding aerodynamic lift and control surfaces to your RV, and then flying it as it glides down unpowered is what lets you pinpoint your landings. It also eliminates almost all reentry heating problems. But it takes a lot of design work on your RV, and some practice to scrub off approximately the right amounts of speed at the right times. But I have some parts that reenter -- and there is absolutely no way to precalculate where (within 10 km) they will land, because they are designed to be aerodynamically inefficient.They tumble, they porpoise, they glide, they spiral, they spin. So I don't think there is anything that can give you a definitive X on the ground.

I would like to see a toggle in the tweakables of every command module, to set how SAS should handle RCS if RCS is available. In the current version, SAS overuses RCS to a huge extent and causes a lot of problems with docking. So much so that you often need to make sure that one or the other is always off. So I would really prefer to be able to set a tweakable to either completely prevent SAS from using RCS, or to have the SAS system rely much more heavily on gyro stabilizers, even if the RCS system is turned on. PS. Oh, and things like Mk2 fuel tanks should mass slightly less than the equivalent Mk1 tanks. They are supposed to be higher tech, so there should be a benefit (besides a little lift) from using them (and going to all the effort to unlock them) -- you shouldn't be punished for it.

As I said, stage recovery works just fine, within the game's limitations. And my game is perfectly stock. So, "in my book 'stage recovery doesn't work' isn't a reason to change default parachute behavior, it's a reason to update the stage-recovery mod so that the various parts do what they need to do" is a non-operative argument. And this is not just about stage recovery, it is about any passive reentry system -- which I understand you have never bothered to think about. Here is a tutorial on how to do stage recovery: http://wiki.kerbalspaceprogram.com/wiki/Tutorial:_Recovering_Rocket_Stages

I can't believe this. FROM THE PART DESCRIPTION ITSELF: This super heavy booster is designed to be recovered after jettisoning. Once recovered, it is refurbished and refueled for another launch. I am not doing it wrong. I can recover 25% of my launch cost by recovering the boosters. That is not chicken feed. Recovering the boosters works just fine, if you do it the way you have to do it -- and in ver 1.0.5 that means you have to launch them all the way into space. I am sorry that this is one entire aspect of the game that you don't do, but it was designed to work this way. And the drogue chutes are not useful in the game right now because they don't serve the purpose that they were designed for. You say you barely use them, and then claim that they work just great as-is? WTF? And that IS the point of this thread -- making slight mods on stock parts that people don't use because the parts don't fulfill their intended purpose on a cost/performance basis.

OK, it looks like the problem is that you never use your chutes in automatic deployment mode (ie. activate them in space, before reentry, on an unguided piece of debris). You always open yours manually, which you can't do on unguided debris. Let's say you have a bunch of first-stage kickbacks in a cluster that you want to automatically recover. You activate all the chutes in space, then decouple the first stage, and it falls back to Kerbin. The main chutes must therefore partially deploy before they might hit the top of a mountain, so you set their partial deployment pressure to .2 = 8000 meters. You leave their full deployment altitude at 1000 meters above terrain, because that's fine. However, at 8500 meters you know from experiments that the debris will be traveling at 500 m/s. So you need a drogue. So you stick one on, and leave its partial deployment at .02 = 21000 meters. So it opens in partial deployment (which happens to be over the water) and slows you to 310 m/s at 8000 meters altitude, then your mains partially deploy and are immediately destroyed -- because your drogue never fully deployed, because the highest you could set it to was 5000 meters. The moral of this story is that drogues exist to protect your mains. The only reason to have them fully deploy at all is to slow you to a parachute-safe speed before your mains partially deploy -- especially if you are not timing their opening manually. So if you set your mains to automatically partially deploy at 8000m, then you need to know that your drogue will be fully deployed before then -- say at 10000m, absolute. So I am saying that drogue chutes must either fully deploy at absolute altitudes, or allow an altitude above terrain that will always deploy them above 8000 meters.

I find it amusing myself. The T1 SPH has patched holes in it, from little accidents. The flag at the T1 admin building has been abused. It's pleasantly idiosyncratic for each building -- and I'd like more of it. I wouldn't mind if all the T1 and T2 buildings had some silly thing visually wrong with them, to gently encourage you to upgrade them.

The problem you are not considering is that the partial deployment "altitude"/pressure for the main chutes is absolute. Because it's based on pressure, and pressure is absolute. Also, at altitude, you are not descending vertically. So, 95% of the time, when flying over low ground, your mains will deploy before your drogue fully deploys -- which means (if you really needed the drogue at all) that your mains will be destroyed. Alternately, as you say, if you get totally lucky and happen to fly over mountains, then your ground level will suddenly increase and your drogue will deploy first and you will have a safe landing. So drogue chute full deployment needs to basically match main chute partial deployment mechanics, or you will only be able to depend on the partial deployment of drogue chutes for all your landings. And anyway, the fully deployed drogue only slows you to 150 m/s or so, so it's not much of a wait to get from 8km down to the ground. Not like floating down at 5 m/s from 1000m. But the main point is that a drogue that only fully deploys at 5500 meters altitude (or below) 95% of the time is not worth a lot.

There should be a second "high tech" type of airbrakes (ie. deeper down the tech tree), specifically for reentry/aerobraking, that has a thin coating of ablator on the extendable panels and a higher heat resistance.

IRL, drogue chutes are supposed to fully deploy before your main chutes even think about partially deploying. In KSP, you really want your mains to partially deploy around 8000 meters or so, so that you are above the tallest mountains (at a pressure of .2 to .25 or so). So the full deployment altitude of all the drogues should be like 10000 meters. But the absolute max you can set in the tweakables is 5000 meters. So I'd like to see the altitude tweakable of the drogue chutes changed to slide between 5000 to 15000 meters, I think.

Wow, you guys are nuts -- when it takes so much less than that to launch 4 40-ton payloads. Yeah, a Poodle is always much better than a Rhino if you aren't trying to blast a hole through the vacuum. It takes a little longer, but you get there with more fuel in the end.

I find that tail fins are superior to airbrakes in all ways. More heat resistant, they give you aerodynamic control after they fulfill their airbrake uses, and provide just the right amount of drag at the back end to keep your craft oriented properly. Just make an action group that toggles the "deploy" function. ATM, there is a bug in KSP that will always make your RV spin when the fins are deployed, but they slow your craft very very nicely while deployed. At eve aerocapture speeds they probably need the heatshield too -- but if you try them I think you will find they always work better than airbrakes.