Murph

I've tried it on an old Core 2 Extreme 2.8GHz with ATI Radeon HD 2600 Pro 256MB, and don't get obvious lag from the fairings fading and moving around. They are quite snappy and responsive to the mouse, and the editor is lag free. I suspect you may have some other issue, such as graphics settings too high for your system, or a bad GPU driver, or something about what you are doing. KSP is quite playable on that old system, if I choose appropriate and reasonable graphics settings, giving 50 FPS and green time dilation for simple scenes (e.g. single medium complexity craft in active flight, but many flights on rails). Some more detail on your system, your mods, and just what sort of craft you're editing is in order, I think, if you want to be taken seriously. Do you have problems with graphics options turned down, no mods installed, editing a small to medium sized craft, with a small payload fairing? If not, which of those factors has to change, and by how much, before you experience problems?

Bigger isn't necessarily more immune to flipping. If it is very tall, with the CoM significantly below the middle, you have a big lever for the force acting above CoM. Bigger also has more surface area for the air to react against. Some bigger rockets will be more stable, some less stable. More mass does mean more stability, due to inertia, but bigger size means more force from the air. If the mass:force ratio rises, it is more stable; if it drops, it's less stable. As for the original "why are my rockets flipping?". About 90% chance that it's a mixture of wrong speed for the altitude, or nose too far from prograde (even if prograde is no longer a direction you would like to go…). It could also be lack of control authority (torque wheels, fins, control surfaces, and vectored thrust), or a horrible amount of drag on the upper end.

I can confirm that fairings do work very well to keep heat off the payload. I've just done a launch of a tiny-size probe on a small size launcher which got a bit too fast and horizontal too soon, to the point where the fairing popped up an overheat bar that filled past 50% by orbit, and the fairing itself started glowing red (the object itself, not the hover temperature gauge). On arriving in orbit, I turned on the temp overlay, and the fairing and lower stage were bright yellow. On jettisoning the fairing, the probe inside it was deep red (the coldest visual from that overlay), only the decoupler attached to the fairing base, and the probe's engine had started to get hot (via conduction), and they were colder than the lower stage, fairing base, and fairing. Conduction was getting the heat in, but very slowly, despite the shell glowing red without any debug overlays enabled. Fairing was char grilled and extra crispy, lower stage was toasty but not well done as it was partially shielded by the fairing (it was slightly wider diameter, to accommodate radial parts on the probe). Payload was fairly cool other than decoupler and engine. I don't have exact speeds to offer, but probably 2000m/s-ish @ 30,000m on Kerbin ascent which was mostly horizontal from about 20,000m, so a long sustained period of heating. I strongly suspect that the fairing and other bits would probably melt if you tried 3000m/s deep into a thick atmosphere. They are not a substitute for a proper ablative heat shield if you're going to go for a crazy ultra-fast aerobraking entry, but they will give a lot of protection to more vulnerable components inside them. They work very well, pretty much as they should work, but they have their limits.

Unity wheels have 2 static friction curves, one for forwards & backwards, the other for sideways. The curves themselves have very little parameterisation, basically only max friction before slip, then the reduced friction after slip. Torque from power or braking is applied to the forwards/backwards model, any non-aligned velocity component is applied to the sideways model combined with any sideways component of gravity (e.g. going across a slope). So yeah, there's a static max friction value, torque gets delivered up to that point (translated into linear force), and it slips beyond that.

Unity wheels don't support this, at least for Unity 4.x (not sure about Unity 5, although I have seen developers complaining about wheels again in 5.x, so quite probably the same again). They explicitly ignore PhysX material types, using a different friction simulation to everything else in Unity / PhysX. That means that any variation in friction has to be completely new functionality created and maintained by the developer. It is not a quick or simple fix, as you have to create completely new ultra-fast, highly complex code which runs every physics frame (many times per second), to evaluate the current required behaviour due to surface type, relative slope, dynamic loading, etc. Not worth the development resource to implement it, and maintain new complex physics code from now to the end of time, since this is not Kerbal Driving Program, GTA Kerbin, or GTA Mun. The wheels we have, using the Unity supplied, maintained, and optimised wheel physics are not brilliant, but more than adequate for KSP. Real world wheels are simple to the layman (but have their own real world complexity in demanding applications). Simulated virtual wheels are incredibly complex and difficult to get right, and much more so if you are trying to simulate them in something other than the most mundane and simple circumstances.

The pod memorial doesn't appear until the VAB is fully upgraded. The wiki's biome list lists all of the special sub-biomes at KSC. I've confirmed that they are all present in 1.0.2, but the per-structure sub-biomes are not all there until the related building is fully upgraded. Your science rover needs to be touching the structure for the per-structure sub-biomes (drive gently into it, keep driving forward to keep it touching, click brake on, then collect results).

Technically, the decoupler doesn't create the shroud, it's created by the engine itself. Stack anything directly below an engine, attached node to node, and the shroud appears. While it would be nice to have something like this, I think the answer is likely to be that it's too complex to reliably figure out what should happen. The situation right now is at least 100% predictable and reliable â€â€.you'll always get a shroud which matches the size of the engine. I know there are other cases where it might not be so simple, but in the OP's example the solution is just to use a Poodle, not a LV-T30, for roughly the same thrust and the correct size for the stack.

Yeah, I'm inclined to agree and say that Squad made a mistake having action groups as part of the facilities upgrade system. It just doesn't make sense to me. I think they should just stick to part count and size, or find something else that makes sense to only be available at level 3. Remove action groups from the upgrades system, change the part count for level 2 to something much lower than 255 parts. 255 is effectively unlimited for normal career mode craft, at least in the "get your space program started" phase  I'm easily completing all of my local (Kerbin, Mun, and Minimus) contracts on around 50 parts or less.

NASA's plans for the NERVA included tugs to take things from LEO to higher orbits. So, it's not so bizarre for them to be used over shorter range.

Yeah, that's the special case to be avoided, unless the bounty is HUGE. In every other case, no big deal, as long as you do check the orbits before launching. It does beg the question of how the hell they got into a retro-orbit around the sun in the first place?!? Just how many boosters did Jeb sell them? Indeed, with the new hiring cost, I've been taking every rescue contract offered, as they are not only lucrative at the time, but save a significant amount later by avoiding the hiring cost. Right now, I might earn 100k from a rescue mission, but the net benefit is over 500k, and growing larger as your operation expands. Once I've got about 7 new recruits rescued, I send them on a group tour of Mun and Minimus, to skill them up.

I'm not against having them shown in the tracking centre before you accept the contract. They absolutely should be shown there. Having said that, I don't see any problem in the scenario you describe, at least on normal difficulty. Rescuing someone from Mun orbit costs me about 25–30k, using the small pod on a 1.25m launcher with a probe core to get it out there. The taxi contracts pay at least 100–150k from the Mun, if memory serves (I've not had one for a while). Seems just fine to me, doesn't require doubling up to make it viable or worthwhile. It's one of the more profitable contracts either singly or doubly. You can also try to add on a science survey contract or something, for yet more profit from single launch cost. I normally don't wait to double up with other contracts for Mun and Minimus, but will double up when the opportunity is at hand. Or, take some extra fuel and you can still do both in one trip, even with a 180° inclination difference between the orbits. After picking the first up, raise Ap to something suitably high (but still inside Mun's SoI). Change orbit at Ap for fairly low cost. I.e. what you describe is no big deal in the first place. N.B. You can also accept the contract, look at the orbit, then cancel it without the failure penalty (you just have to repay the advance).

I don't remember it ever behaving any differently, all the way back to the very introduction of science in 0.22 or 0.23, whenever it was. My memory says that it always transmitted and removed 100% of the experiments stored on the craft, even those with 0 transmission value. Admittedly, I rarely used it after discovering that behaviour in the earliest days of science, so it's possible that it did something different at some point between 0.23 and 1.0. It does need to change, and we actually need some serious polishing of the stored science UI. With the new lab mechanic, I've ended up with 50+ experiments stored in a lab, and it's an extremely tedious click-fest to wade through them. It's also extremely difficult to actually see what you have stored, as it is an exercise in remembering stuff as you tediously click through a stream of highly similar screens. We need a much better UI with a scrollable list of stored experiments, and the ability to transfer subsets of them to docked pods, and the like. The improved UI for craft-stored science could then be triggered by "Transmit Data" on antennas, and should include a "Transmit All" button on that UI which behaves as the antenna does now, but also buttons to transmit only things with transmission value, or individual experiments. Another bug that I've recently discovered, but I think may have been around for a good while, is that data is lost if you run low on power during transmission. It claims that it's sending the remainder as power becomes available, but it seems that most or all data is lost after the first point where it stops due to no battery power.

Yeah, that's all pretty much hitting the nail right on the head. I've not yet used the LV-N enough in 1.0 to be certain about the thermal issues, but it seems like there's enough concern that Squad should be looking at that part of it. The real life Los Alamos / NASA NERVA, which appears to be what the LV-N is attempting to emulate, had thermal management as a major feature and top priority. If anything, I'd say that Los Alamos probably ranked thermal management higher than providing efficient propulsion. So, yeah, it does seem a bit nuts if it has major overheating issues in normal use. I agree that they are intended to pretty much be either 100% or 0% output, not throttled, but I'm not sure that throttling should cause a huge problem, since the control of the nuclear reaction can be relatively finely controlled by the position of the moderators and control rods/dampers  the control mechanisms for the reactor are not a 100 or 0 only thing. I'll admit that I don't know how NASA's real NERVA would have behaved throttled. Fuel tanks, yeah, some additional choices of LF-only would not do any harm, but we absolutely can throw together some perfectly reasonable LF-only storage for LV-N tugs right now. It's on the opposite end of the spectrum from "ZOMG, it's broken, Squad sucks!", which is how some people seem to prefer to paint it. Is it perfect? No. Is it reasonable (with possible exception of thermal issues)? Probably. Is there scope for improvement? Yes. Is it useable today? Yes, with care and creativity, and letting go of "what used to work". Is it useful today? Yeah, I believe so. Should Squad be thinking carefully about the tuning for next release? Absolutely, yes.

I'm not convinced there would actually be much shock felt in the capsule. The circumstances we're talking about are so vastly beyond the strength and heat capacity of the parachute material, that I believe it would almost instantly shred or vaporise, before it could transmit much shock load. I'm speaking from some experience here, having shredded very large sails made from parachute material, they just go instantly when you exceed max load (but you do get recoil shock in that situation, as it was typically under sustained max load before it shredded). Subject normal modern parachute cloth to extreme heat, and it will just vaporise rapidly. The only way I see the capsule experiencing shock is if it was under significant load for some time before being destroyed.

It has 2 seats, where the small one only has one. That's important if you want to level up your crew. If you're doing Rockomax (2.5m) missions, it's both aesthetically correct, structurally correct (stronger attachment nodes, I believe), and quite possibly aerodynamically superior under the new system. The weight is no big deal for Mun and Minimus landings with a 16 tank and a Poodle, and certainly no big deal on top of a full 2.5m launch stack. If you're doing 2.5m stuff, why wouldn't you use it? I certainly wouldn't dream of using the small one in any circumstances other than very early missions (before 2.5m stuff is properly unlocked in the tech tree), or very long range solo missions. There's also basic maths. It's not twice the size, it's 4 times the size. Area = Àr2. If anything, either it's not heavy enough, or the small can is too heavy, based on its size and structural capacity. If crash tolerance is an issue, either your design or piloting skills are lacking. Crash tolerance should be irrelevant for it, due to the tanks, engine, and landing gear below it.

I'll be extremely blunt. To the OP, you're completely wrong, you're not giving 1.0 a fair chance, you're refusing to adapt to necessary change. LV-909s were never meant to be a space plane engine, they are a low profile, low gravity lander engine. It's entirely possible to build reasonable space planes using the turbojets and some other rocket engine, you are in no way forced to use the RAPIER. The bad silly stuff with turbojets has mostly gone, such as the absurd air hogging, insane speeds and altitudes, etc; but it has been replaced with HUGE power in a realistic sweet spot for a turbo-ramjet hybrid (SR-71 territory). The flight technique to get a space plane to orbit has changed radically, with the vastly improved atmospheric physics, you just need to learn how to deal with the much better model. LV-Ns were a bad thing about old KSP, as they gave too big an advantage over just about everything else. Balance was very much needed there, and now there's actually some skill needed to create good, efficient interplanetary ships. The LV-N is still very much useable, you just need to learn how and when to use it, and when not to use it. As has already been pointed out, if you don't like a particular aspect of the current game balance, go right ahead and change it. It's all there for you to setup exactly how you'd prefer it to be for maximum enjoyment, either in the debug menus, or the various .cfg files. It's really very easy to change just about any aspect of the balance to personal taste. Honestly though, KSP 1.0 is every bit as much fun as old KSP, you just need to let go of most of the "how to do x,y,z" stuff from pre-1.0, and do things the new way. Once you've learned how to work with the new behaviour, it's a much better game overall than it ever was pre-1.0. Squad have done their bit in filling in the gaps, balancing, producing a great 1.0 release, now you have to do your bit and re-learn stuff that absolutely had to change. There is no way that KSP could have been released with the old horrible, broken aerodynamics, for example. It was obvious that things had to be balanced from rough and ready alpha, to full release. Is the balance perfect? No, it's not, there's still scope across the entire game to better tune the balance, put the polish on bits that didn't quite get enough polish for 1.0, etc. Overall, however, the balance and polish isn't all that bad, it's in the general area of reasonable for most stuff, but some things are better than others. I fully expect the existing 1.0 feature set to be pushed close to perfect by 1.1 and 1.2, we just need to give them a little time to get it done. As it stands, 1.0 is a vastly higher quality product than some big name AAA studios put out under flagship brands and vast budgets. Some big names have put out basically unplayable 1.0 releases in recent memory, taking 6–12 months after release to sort out serious problems, and even then not actually fully delivering; other notable names have slapped a 1.0 sticker on it, fired the dev team, and walked away to leave customers with an overpriced, broken, incomplete game. KSP is ranked in the top 10 of all games on Steam sorted by customer reviews (not the world's best metric, I admit, but still a fantastic achievement for a small developer on their first big games project), and it deserves to be up there.

I very strongly disagree with that. I do not believe that it is necessary or useful to add tweakable ablator to command pods. Most pods don't even visually have a heat shield anyway, it's only the simple starter pod that has the visual shape. The current heat shields do the job just fine. I see absolutely no advantage to having an integrated shield on the starter pod, when you can just add a normal shield below it when required. Additionally, separate shields almost certainly make it much easier to deal with the physics of the heating in the simulation code. As for the shape, it's fine as-is, I see no need to change it. It even makes sense for using it without an additional ablative heat shield, if that's Squad's intended behaviour for slower re-entry. In theory, two of the features of the rounded shape are that it's aerodynamically stable, and can actually be used to fine-tune the trajectory, if memory serves (if KSP's aero sim ever reaches the point where that would matter). There's a very interesting Apollo-era video out there, a NASA official production (I think), which is roughly "how pods work", if you want to know how you can actually "fly" a pod rather than just passively wait for it to submit to gravity.

No, it should not be longer. What's needed is a second part in the same style, but suitable for mounting on a wing attached to the middle of a mark 1 tank. I.e. existing small gear for mounting to the bottom of the body, longer variant for mounting to wings, and the combination of the 2 used together resulting in a plane that is horizontal.

The fee prevents people just signing up with throw away email accounts, and similar. Apple can, and do, revoke keys used maliciously or in violation of their developer agreements, with the OS regularly downloading the current revoked keys list. They can also block individual apps, rather than an entire developer, for cases where there's something which is problematic but not malicious. There has been signed malware in the past, I believe, and not just on Apple's platforms. It's not a high security system, but raises the bar quite significantly and adds risk of being traced by authorities for malicious acts. Using a 3rd party key would be a quite silly thing for any legitimate developer, as your apps could get blacklisted due to improper behaviour by someone else. The annual fee also gets you access to closed betas (and various other closed downloads), and the ability to publish via their App Store.

Absolutely, this should be a short term priority to get sorted out. It should be fairly easy to do, and is low cost. Here's where to sign up: https://developer.apple.com/devcenter/mac/index.action It's also the first step towards being able to sell the game via the Mac App Store, which should be a positive thing as well.

The current medium and large gear is fine, for wing mounted main gear. It gives the necessary height to avoid tail strikes, particularly for classic delta wing designs which require pulling up fairly hard on takeoff with the wheels set a fair distance behind CoM. What's needed is shorter matching versions of both, so that you can have wing mounted main/rear gear, and body mounted nose gear while still keeping the plane more or less level. For completeness, there should probably also be a tall version of the older small gear.

Flying better isn't only about maximum range. Your test is invalid due to staying vertical, and focussing only on the maximum altitude. A valid test must include a realistic ascent profile, and consider whether it improves aerodynamic stability and control. I.e. does it improve flight characteristics, helping to avoid loss of control, on a realistic profile? A valid test should also keep to appropriate speeds on the way up, i.e. no prolonged balls of fire due to excessive TWR, no mach 3+ at low altitude. If you want to conduct a more meaningful test, I suggest using MechJeb to get a repeatable "hands off" realistic ascent profile (assuming that MJ ascent guidance is working for 1.x now, I've yet to try it as I have chosen to do the first bit of career hand flying). You'd still need to do some separate hand flying, and subjective evaluation, to decide whether it helps for control and stability. N.B. I'm not saying that the nose cone is ok, only that your test is not ok.

No, the license does not permit that. You'll need to wait for the original author, or get permission first, otherwise it's a breach of copyright to distribute it. The most you can do within the law, is to distribute a separate Module Manager patch, without any of the original content, to fix any issues.

It's still suitable for its role, you just have to change your expectations and approach to it. You just need to use the mark 1, 2, or 3 LF-only tanks for it. Or, just use mods. Frankly, I find it baffling that people say things effectively equivalent to "I know there's a simple and easy solution for what I want, by installing a low risk mod, but I refuse to do that!" Parts mods are all very low risk, if they are just parts, without any new features. There's a large LF-only mark 3 tank, something like 5000 units or so, if memory serves, which is right up there with the Jumbo-64 2.5m tank. The LV-N was changed to LF-only, because *that's how NERVA engines work*. It was a bug that it used LF+O, the bug was fixed. Your suggestion is not well founded, and I actively oppose it. Squad, please do not change the LV-N back.

I said earlier in the thread that I thought the fairings were "perfectly reasonable" (but not perfect). At the time, I'd only been using them for small payloads, and couldn't really see a problem with them, based on using them in practice rather than the absolute numbers. Based on more recent posts, I now accept that they may well be too heavy, particularly when scaling up, and that Squad should take a serious look at the weight. Even with that, I don't think they are "useless", they do seem to basically work ok, just probably need some tuning. Overall, I don't really care if they perfectly emulate the weight of real world examples, only that they are reasonably balanced for normal use cases.