bewing

i sympathize, if all you are doing is building spaceplanes. But otherwise, I have to disagree. High crash tolerance is worthless unless you crash your stuff -- which is a silly thing to do. And body lift only has value in atmosphere. I mean, I like building and flying jets, sure, but there is a lot more to the game than that. The way that it stands, then, when you are traveling outer space: MK1 parts are lighter, they cost less, and they have more benefits. So, this is the desired end result of all that R&D? Populating all of space with rockets built from MK1 parts? It's nonsensical.

How do you know that they are pilots? I can't seem to get that info out of my game, until I'm less than 2.3km from their craft.

Yes, that is all quite correct except for one little thing. Mun is tidally locked, and orbiting prograde. Which means it is rotating very slowly retrograde. "East" is determined by the direction of rotation, which means that so is north and south. Which means (as with our Moon and Venus) that Mun's South pole is on top, and the North pole is on the bottom. So you've got your north and south reversed. But yes, the angle of Kerbin is impossible, so the image of Kerbin is being artificially mapped into the shot.

The angle of Kerbin above the horizon limits the location to a very particular (very large) circle (if the location actually exists) -- if you wanted to bother to calculate it out. So it's not like you'd have to search the entire Mun. Edit -- actually, after thinking about it, I'm pretty sure that the viewing angle of Kerbin itself is also a restriction that could be used to narrow the calculation to two very specific possible points on the Mun. (Well, except for the fact that you have to guess the angles within a couple of percent. But still, the two "points" would be fairly small circular search areas.) And you know that the picture is not taken from inside a crater, either -- so that puts another pretty strict limit on it. Heh. I never noticed before, but that's not a still image. Kerbin rotates while you watch. So if it's generated dynamically, then it seems like it must be from a particular camera location? Except for the fact that it's always daytime .... hmmmmm.

This will happen to any craft that has focus, in the stock game. When craft are not in focus, the game forces them to move on a perfect elliptical orbit. When a craft is in focus, unfortunately, the game tries to calculate the orbit from the current velocity vector, with numerical errors. It conserves energy, however. So, as said above, your craft cannot fall out of orbit. But a small amount energy will shift from the periapsis to the apoapsis and back again. If I could modify the program I could fix this -- but if you want it to stop happening to your space station, then you need to shift focus to something else.

I just re-realized something that I've seen many times previously. To anyone with an eye for impact craters, Kerbin has obviously been the target of a recent massive meteor bombardment. Like, "less than a million years" recent. Barely eroded craters everywhere, when you look closely. The badlands are very recent impacts. And the one on the other side of the planet is enormous. Which definitely either implies a war with a spacegoing enemy (who can drop rocks from orbit), or alternately an impossible environment for evolving intelligent life. Option A leaves open the possibility of a Kerbin origin for (possibly space-faring) Kerbals (but you have to factor in an extreme resurfacing of the planet to your theory), but option B definitely rules out Kerbin as the Kerbal home planet. More research is necessary.

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.