Murph

Yeah, I'm much the same, but with experience on the stick of a real plane, including aerobatics. The old aero was horrible and I had to actively force myself to fly in an unnatural way. The new aero isn't perfect, but it's a vast improvement and now is at least vaguely matched to my experience of flying real aerobatic craft. Most of the problems I have now are due to my butt and ears not getting any physical inputs, which I've always found makes flying simulators much harder than the real thing. All flight, rockets and planes is much improved and easier for me in 1.0.2, than in pre-1.0. Some changes are needed in approach to design and how you fly them, but it's really not difficult at all to learn the new way, then far better than it ever was before. Let go of the past, embrace the future! Do your best to permanently erase "45 @ 10" from your memory.

I'll give this a conditional "YES". I agree that the behaviour should be fixed where a no-acceleration warp should keep something inside the bay. I agree with some form of auto-strutting for normal docked payloads. An undocked payload, however, should have significant risks during atmospheric flight and acceleration, for disrupting the CoM, or even destroying the cargo bay or sections in front and behind the cargo bay, if it slams into them. Unsecured cargo is typically a catastrophic event in aviation, if it is of any significant size or mass, due to the shifting weight, or damage when it hits something.

I vote NO! on this. Steam achievements are worthless. They would also be meaningless for KSP, since people could just cheat their way to 100% achievements in about 10 minutes flat, and it's absolutely not worth the development time to create a way to have achievements that are uncheatable, when easy ability to cheat is actually a very positive feature for KSP.

Windows: Task Manager OS X: Activity Monitor or top Linux: top, or there's probably also some graphical tool these days They will just let you see the current usage of KSP. From there, it's basic scientific method to determine how much any given KSP setup uses, but varying the parameters and observing the results. Limits are around 3GB on Windows, 4GB on OS X, and effectively unlimited on 64-bit Linux.

I also recommend RCS Build Aid, but I do not consider it important to prevent CoM moving with fuel usage. It doesn't matter if it moves a little, only that you understand how it moves, and that it doesn't leave you with an unstable plane. It is wrong, in my opinion, to artificially restrict your designs by making it a requirement that CoM does not move. Just be aware of the issue and know how the plane will behave, move fuel from aft tanks to forward tanks in orbit, before re-entry.

It's fast (almost mach 1.0), sure, but that's not the real problem. Mach 1 at sea level is just fine under the new aerodynamics, although not really a valid ascent profile if orbit is the intended destination (you don't want to be going for speed until you're above about 7,500–10,000m, possibly even 15,000m, depending on the design).

A single Mk16-XL parachute is pretty much only suitable for the 2.5m pod on its own. If you have anything more than the pod to land, you'll need a number of radial parachutes and/or engine braking as well. In terms of impact, 8m/s is fast. Ideally you should be aiming for 5m/s or less. Visualise a normal modern room, it is probably a little over 2m floor to ceiling. Now think of 4 times that height (8m). Now consider how long a second is. Put all that together, and you can hopefully see that it's a fast and violent impact.

One other thing, more for the ascent, than the descent, is that I'd check for differential thrust (getting more thrust from one side than the other). I'm not yet clear on the details, but I've seen a pair of turbojets do that in 1.0.2, e.g. producing 140kN on one side, 120kN on the other, at the same time, resulting in a constant yaw battle while it's happening. I think it's a bug that is triggered by the order the parts are added, possibly for quite specific cases.

I'm certain you probably can push beyond it a little, but 25km @ 1000–1200m/s, nose 10–15° above horizon, prograde 5–10° above horizon, seems like about the practical limit for the turbo ramjet, and it's going to be near impossible to maintain that. Even achieving roughly those numbers is going to require a fairly specific flight profile, as the power is mostly gone above 20km, it's relying on the power available and speed achieved at 15–20km. Everything above around 20km is pretty much into diminishing returns, where you have to add a fairly huge amount to achieve relatively little. N.B. that there are far more relevant parameters than altitude. I can achieve over 70km with just turbojets, but that won't achieve orbit in a reasonable manner, it's a very vertical ballistic trajectory with engines dead past around 25km. If you're trying to create a space plane that can achieve stable orbit, the speed, nose angle, and prograde vector at around 25km are all critical.

I'd start by adding a tail and rudder, or pair of them. The loss of control in the video looks like it starts with uncontrolled yaw, that's what the tail and rudder control. The video shows more or less expected behaviour for rudderless planes.

You don't, but you can from Minimus to Kerbin, which is what the OP said.

Yes, but you only get offered them after you have visited each SoI. I.e. visit Mun, you can get Mun rescues, same for Minimus, pop out of Kerbin orbit, into solar orbit, and you start getting solar orbit rescues. Each new SoI visited should "unlock" rescues (and other contract types) there (possibly subject to tech tree unlocking and rep as well).

Sure, bringing it back to Kerbin orbit, with scientists working in it the whole time, that's a valid thing. It's landing a lab back on Kerbin that is the mistake. It's much harder than re-entry and safe landing with a pod, more costly, and has no benefit over a pod. Launching a second lab just to return the experiments from Kerbin orbit is definitely the wrong thing to do. It could work, but it's high cost and higher risk than a pod. Personally, I'd just leave it out in Duna orbit with a couple of scientists working there. Bring the processed experiments back in a simple return pod. Less fuel to do that, and there should be more than 500 data from the Duna system, so leaving it out there is necessary to get the same-system processing bonus if you're going to return before everything is able to be processed (but then you'll need a second expedition to return with the experiments processed after the first return trip). Bring the lab back, or don't, just don't land it on Kerbin, and don't use a lab as a KSC->LKO->KSC shuttle for experiment results.

There is *NEVER* a science benefit to landing a lab back on Kerbin. The data in it cannot be recovered, only transmitted. If you try to recover it, it will be completely lost. Experiment results stored in it are separate to that, but you just EVA a Kerbal over to it, take them, and store them in a simple pod to recover back to Kerbin. There's not even a real funds benefit to it, even if you get 100% recovery, as you've lost the launch cost and spent a bunch more on a large number of parachutes. It costs you far less, and is much easier to land the experiment results using a simple pod. So, leave the lab orbiting Duna with a couple of scientists in it, periodically transmitting their results (you do that manually), or bring it back with scientists working in it for the return trip, but do not land it back on Kerbin. It's of far more benefit for you to leave it orbiting somewhere doing more research. Additionally, it is impossible to transfer research data and results between labs. N.B. The new research "data" and results totally separate to the old experiment results. You process old experiments in a lab to generate new data, but that's the only link between them. Old results can and should be recovered (or transmitted with the same transmission cap/penalty as before) after processing in the lab.

Funding is the only and primary reason given by Los Alamos themselves, safety concerns are not cited at all. http://www.lanl.gov/science/NSS/issue1_2011/story4full.shtml NASA evidently do not consider it to be blocked on safety grounds, having briefly revived the concept as Project Prometheus in 2000, which was again cancelled due to budget, and not safety concerns. Yes it is. You have to make a huge assumption to reach the conclusion that nuclear rockets should require a reputation hit, namely that Kerbals have a serious anti-nuclear politic to be concerned about. It's a mistake to add that, it brings real world politics into the game, it's a terrible idea to let the game stray into that territory.

I'd gladly trade this for the current behaviour where they sometimes explode from jumping down about 1m off an aircraft wing, or sometimes even just letting go of a ladder while already level with the ground!

NASA's NERVA was shelved because the funding was cut due to lack of willingness to proceed further with Apollo and beyond (to Mars). The history I've read says that it was a political move, but with financial motivation. It had very little to do with anti-nuclear politics, or nuclear safety concerns, and everything to do with national budgets and willingness to continue investment in space exploration. It's no more of a wild assumption than assuming that the people of Kerbin would have any problems with nuclear propulsion to justify a reputation hit.

Personally, unless fuel is really tight, I wait until the target SoI to pick orbit, making the adjustment immediately after entering the SoI. Tiny burns from a very long way away can be an exercise in frustration, as they require extreme precision in both the burn vector and duration. That said, if you need 0.1 m/s precision on a very small burn, my tip of the day is to temporarily set your thrust limiter to 5% for the burn, effectively giving you 20x the precision and subtlety on your throttle (assuming that 100% thrust is a moderate to high TWR).

It could be a mistake to have any form of pro/anti nuclear politics in the game, so I'm not sure that's really a good idea. For all we know, Kerbals could have a very high tolerance to radiation, so it could be entirely a non-issue for them.

LV-N isn't necessarily before RTG. LV-N is a lower level unlock, but one does not depend on the other. The RTG can be available before the LV-N if you want it first. Yes, this is far from the only issue with the tech tree, the whole thing really needs to be redone to make some sense. Personally though, the RTG is one of the things I don't have an issue with being at the high end of the tree, as it's an advanced technology regardless of the era it comes from in the real world.

You're completely misinterpreting what I wrote. I know that this thread was not suggesting a mod. That has nothing to do with what I wrote, I made no such assumption. My point stands, that in a thread suggesting something for the stock game, it is not off topic to simply draw the OP's attention to an existing mod that is relevant. In discussion of a suggestion for the stock game, it can be useful and relevant to refer to existing mod functionality. And that's the point. I'm frankly quite fed up with people responding negatively to people for providing potentially helpful and relevant information. Informing someone that there's a mod which may be of interest and provide the suggested functionality in the short to medium term can be helpful. It can also be useful for fleshing out the suggestion, such as discussion about what a mod gets right vs. what it gets wrong, in the context of how a stock implementation should be done.

Nope, you're wrong. Threads suggesting mods are off topic in this forum. Someone simply responding to a suggestion by making the OP aware of a mod that may satisfy their need or be of interest to them does not seem at all off topic to me, as it's relevant and helpful. Drawing someone's attention to the mod possibly gives them a solution today, rather than fairly far into the future, or even never in the stock game. There's so many mods out there, it's highly unreasonable to expect everyone to be aware of everything that's available. Posts complaining about just mentioning mods, on the other hand, those truly are off topic!

+625 sounds very much like a bug to me, or you're reading something wrongly, or your game is modded to give huge science numbers, or you've selected a huge science bonus in difficulty options, not sure. I've not seen numbers anywhere near that high from experiments around the Mun, loading them into a lab in low Mun orbit. Whatever the reason, Snark is correct, it's a hard limit of 500, unless you mod the game.

I disagree with 100%. If you can get them to splash down without being destroyed, you currently get a high % recovery for SRBs from a normal KSC eastwards launch. Less than 100% is ok, as you wouldn't be just filling them back up with solid fuel and slapping them on a new rocket. I do agree with adding other runways. Groom Lake would be my first choice, it just seems more fun and highly appropriate when we're dealing with little green men, but would also have a slightly challenging element if topography was similar to the real world, due to surrounding mountains. Vandenberg and Edwards are the other obvious cases, and it might be both interesting and useful to have Vandenberg's alternate launch site as well. Recovery % from these alternate sites would be much higher than landing on a random bit of grass a similar distance from KSC. It does make sense to me that they should be purchasable and upgradeable sites, similar to the KSC facilities upgrades system. In terms of practical implementation, it's probably much easier if they are fixed, pre-determined locations, rather than arbitrary user-chosen locations. I.e. a standard selection of sites that you can choose to purchase, eliminating the problems with trying to dynamically place a runway on any arbitrary bit of terrain.

I've just been setting up to send a probe out for a part testing contract. It's a solar orbit, and the altitude numbers are incredibly frustrating in the way they are presented. It says "Alt: 2725590016m to 2725592064m". Ok, now be honest, how easily can you tell if that's 2.725Mm, between Kerbol and Moho; or is it 27.255Mm, between Duna and Dres? Are you sure about that? Now try the same with "2,725,590,016m" and "27,255,900,016m". This is a "low hanging fruit", quality of life improvement, should be an extremely quick and low risk change, since there's number formatters already widely used elsewhere in the UI. It needs to change in the contract admin UI, and in the universal toolbar's contract quick reference UI. I was busy setting up a series of burns in one direction, trying to see how much "free" dV I could find from slingshots, when I fortunately counted the digits forwards and backwards 5 times, while doing my best to avoid going cross-eyed, then realised that I was going in the wrong direction, fortunately before the first burn.