Eric S

Interesting, I just made exactly that craft in a stock 1.0.2 to see how stable it was and couldn't get it to flip. I did a 90 degree pitch maneuver at transsonic speeds after turning off SAS and capsule torque and it still tried to pitch back prograde as soon as I stopped trying to steer. And yes, this was after the top tank had drained, so the center of gravity issue was about as bad as it's gonna get while you're low enough in the atmosphere for it to matter. The only ways I finally managed to get it to flip was by either deliberately mounting the fins too high or just removing them. I think you're going to have to provide more details in order for us to have any chance of reproducing this (us as in forum readers, I'm not any kind of official representative). To be honest, both of those rockets had more control surface area than the rocket you described, considerably more in the case of the V-2/A-4. And yes, in testing, even the V-2/A-4 could tumble out of control.

There were several (8-12) memory leaks fixed between 0.90 and 1.0. Not sure if that was all the memory leaks, but Maxmaps said that it was all memory leaks known at that time. Then another memory leak snuck in in 1.0.1 or 1.0.2. As for other improvements in memory management, the game no longer needs a plugin to use DDS textures and all the stock textures got converted over. Those use about 1/3 the memory of the previous textures. Mods can now use DDS textures as well, meaning that they shouldn't add as much memory. I don't know if squad is turning on read-only for those stock textures it would be appropriate for. Once the memory leak is closed, I think we'll be pretty stable memory-wise, and we should have plenty of room for mods.

This same issue came up with KIDS, the mod that altered the ISP of rocket engines so that FAR didn't become too easy because of its more realistic atmospheric simulation pre 1.0. Your choices were to lower both atmo and vacuum ISP, or to drop atmo ISP to about 80 even for lifting engines. Maxmaps even mentioned this problem a year or so ago when discussing his thoughts on a more realistic aerodynamic simulation for KSP. It's because most of the time spent during ascent is actually high enough that vacuum ISP is at least as relevant to efficiency as atmo ISP is.

To be fair, pre nuFAR never stopped me from launching ridiculous stuff, I just had to understand the forces at work. Haven't tried nuFAR yet.

The problem with the old aerodynamics is that very basic things that could be done to a real rocket or real airplane could make the KSP equivalent craft perform worse rather than better. Let's say, nosecones. Increased the mass and the drag of a craft with no upside other than looking better/right. I would actually go a little farther and say you shouldn't see mach effects if you're having problems with flipping rockets, since being aerodynamically stable at transsonic speeds is even harder than subsonic. I find that a TWR of 1.8 will push a craft transsonic, but one of 1.7 won't, for reasonably aerodynamic craft. Mind you this isn't just the at-launch TWR, so SRBs would have to be throttled well below a starting TWR of 1.7 and liquid fuel engines will usually have to be adjusted in flight. Piloting comes down to two rules. The faster you go, the stronger the aerodynamic forces on the craft get, so if aerodynamics is trying to flip it, going fast is bad. The farther from prograde you aim the craft, the stronger the lateral aerodynamic forces on the craft get, so again, if aerodynamics is trying to flip the craft, steering too far from prograde will flip the craft. Craft design was covered fairly well here.

From what I understand, Unity 5 is better at 64 bit Win than Unity 4 was, the devs of Cities: Skylines switched from U4 to U5 during beta because Win 64 wasn't stable enough to allow for a stable release. Then again, the parts of Unity that C:S and KSP use aren't that much in common. Between improved performance single-theaded, the potential for multi-threaded physics when you've got more than one craft in the physics bubble, and the improved odds of working Win 64, I'm really looking forward to the U5 KSP port. There are other things U5 could bring, but those are the big ones to me, and in order of priority.

Not sure if you're saying that Windows 64 was the point of Unity 5 or if you're saying that Unity 5 has a rock solid Win 64 code base. It's more stable, but no guarantees that everything Squad will need for 64 bit Win KSP will be bug-free. The big Win 64 announcement about Unity 5 by the Unity Devs was that the development stuff was able to run in 64 bit mode on windows. Yes, they worked out more bugs, but I don't know how much effort they put into debugging 64 bit Win code beyond that needed to run the editor.

On the poll, I think the poll needs different answers. There are people that don't like the current aero because it isn't realistic enough. It really is more forgiving than reality. On the simulation-vs-game, I think it needs to be realistic enough that common sense applies, and the old aero was so far off of reality that things that there were things that would make a real rocket or aircraft perform better actually make the corresponding KSP craft worse. If it were subtle effects like ground effects, that would be one thing, but the old aero system didn't even factor the cross area of a part in determining its aerodynamic drag. On the topic of tips to help you get to orbit, I'd suggest starting off reading this forum thread. It's not comprehensive, but it at least touches on the reasons rockets flip during launches. The post mostly goes into rocket design, not the piloting. On the piloting, my suggestions are: 1) If you're having problems with flipping, go slow. If you're seeing mach effects, you're going fast enough to make it harder on yourself. The faster you go, the stronger the aerodynamic forces are, so if they want to flip them, going fast makes it that much harder not to flip. I tune my rockets so that they spend most of the time in the 1.3-1.7 TWR range. No, I'm not saying 1.7 TWR on lift off, because your TWR will go up as you burn off fuel. 2) Always keep your craft aimed within five degrees of your surface prograde marker if you're below 20-25km altitude. The farther off of prograde you point, the stronger the aerodynamic forces are. I've got a few craft where even going that far off of prograde results in a flip. If you've done all this and still can't get to orbit consistently, then I'd recommend posting a screenshot of your craft along with a description of your ascent profile (how fast you're going and how far you're tipping at various altitudes in the 1-20km range).

I think I'm going to disagree with that, though it really depends on your TWR. Most of my designs work fine if I start a gradual turn at 35 m/s velocity, gradual enough that I'm at about 10 degrees off vertical at 3500-4000m and 35 degrees off vertical at 10-12km. If you mean a 20 degree turn all at once, I'll agree, because I never turn more than five degrees off of prograde except for right at launch where I stay vertical and my prograde isn't always vertical until I've built up some speed.

It can actually be done using three satellites in LKO. I usually aim for an altitude of about 600km. They have enough range until they get up to about 800km, and have line of sight with each other down to about 450km or so. 600km puts it near the middle so that satellites drifting doesn't cause a problem too fast.

My approach has already been reflected here. I tend to run single missions until I start going interplanetary, at which point I start stacking them. It's nothing that unusual for my first Duna window to involve six craft leaving Kerbin.

We've seen a review that considers sandbox the meat of the game, a review that considers career the meat of the game, reviews that ignore mods, and a review that considers MechJeb essential. I'd say we're seeing that reviewer opinions differ as much as that of the players, which makes sense. I'll agree that this review wasn't particularly impressive though. As for the delta-v readout, it got delayed because it's part of a bigger thing that wasn't ready in time for 1.0.

Sort of. I'm a programmer, but I've never touched PhysX or Unity aside from reading up on this topic, but here's my general impression. Unity 5 includes an updated version of PhysX that can split physics simulation between multiple threads and therefore CPU cores. However, they're still not splitting a single grouping up between multiple threads, so unless I'm missing something, we'll still see a one-thread-per-craft limit. So no, octo-core CPUs will not be getting a 700% performance increase on a single craft. It should also be noted that PhysX doesn't scale linearly according to the number of CPU cores you throw at it. One of the developers posted some benchmarks showing that three threads were running about twice as fast as a single thread. On the other hand, PhysX 3.3 includes a lot of optimizations over PhysX 2.8.(something). In micro-benchmarks involving the kind of connected rigid body simulation that KSP uses, 3.3 is performing about 50% better than 2.8.x Understand that micro-benchmark scores seldom translate directly to real world improvement, but that indicates that even without threaded physics emulation we might see an improvement, though one capped at 50% and even that is optimistic. From what I understand, assigning separate threads to separate craft should be easy enough that it will probably make it into 1.1. Docking two similar craft together should have performance not too far below having a single one of those craft within the physics window until they actually dock, though docking a simple craft to a complex craft won't show as much of an improvement. So optimal performance improvement will probably occur when you have one craft of similar complexity per CPU core. On the subject of how much work has been done on Unity 5 already, it sounded like they had a test build of KSP running with Unity 5 though with no comments on if everything was working, let alone debugged. Since the PhysX 3.X API is not backwards compatible with the PhysX 2.X API, it could well be that it came up but most physics was broken. As a side note, while the devs of some Unity 5 based games have reported quick and smooth porting over to Unity 5, the dev(s) of Beseige, the closest game to KSP in regards to engine physics usage that has commented on how much work the switch to Unity 5 took that I have seen said that after two weeks they still didn't have anything that they could show to users, and the last update that happened a few weeks after that statement was made didn't list an upgrade to U5 in the release notes. I suspect this is because of the PhysX incompatibility.

Yes, congrats, though in all fairness, it should be pointed out that the previous leader had two SRB stages and was ahead of several all-liquid entries.

They've at least implied that the original intent was to reach the point that we could get clamshell style fairing ejection and that they're not done working on it.

I do think that there need to be some kind of table that says that certain missions need to have a bigger reward than the same mission somewhere else, and not just a generic "missions on/around planet X reward Y times as much as they do around Kerbin." One of the Twitch streamers today got "Mine ore on Eve, deliver the ore to Gilly." Yeah, there are contracts that you need to just say no to, but they should all be at least a little tempting. If it had been "Mine ore on Duna, deliver the ore to Ike" then it would have been so much easier. But an "Explore Eve" contract isn't that much harder than an "Explore Duna" contract, so you can't do it like science where each planet just has a multiplier.

The crash tolerance of the ore containers is 7 m/s, so the speed of the impact can't be ruled out. If the ore containers are the first part to hit, it's almost definitely the problem, in fact. I haven't tried this yet, but I just got a contract to do so, so I'll know more later.

The part does have a higher crash tolerance, though that really doesn't matter if it's being pushed by an LV-N, which is the case for most people that are complaining about the situation. - - - Updated - - - Understand that while I'm a programmer, I've never dealt with Unity 4 or 5, so this is just general impression. Some programs were able to switch over quite easily. KSP will not be one of them (or at least I belive so), because it rather heavily uses the physics simulation functionality in Unity, which is the one major area that is not backwards compatible between U4 and U5. Besiege, which is more KSP-like than most games based on Unity 4, has yet to release a version based on Unity 5, despite at least two weeks of effort, as last I heard. Squad has already mentioned that they have an in-house version of KSP running on Unity 5, though they also mention that there are issues.

Personally, I'm using a lot more SRBs in early career mode than ever before, and more in mid-range career mode. They don't feel overly nerfed to me. I'm using them for things similar to their real life uses. As a primary first (and occasional second) stage for light payload, to help low TWR craft get moving faster off the launch pad, or to get liquid fuel stages up high enough that their efficiency requires. If the craft might be able to use SRBs, I always try and compare prices, and they usually come up cheaper than all-liquid designs for those kinds of uses.

To go into a little more detail: 1) SRBs have a lower ISP than liquid lifter engines. This means that it takes more fuel mass to produce the same amount of thrust. Because of this, SRBs generally should be used as early as possible so that you can get rid of the less effective mass ASAP. In early career mode, I might use SRBs to get a rocket up to a high apoapsis, then circularize using liquid fuel engines. As I transition into having more variety of liquid fuel engines, I tend to use SRBs less often outside of the first stage, and then mostly to get the rocket out of the lower atmosphere so that the liquid engines have a higher ISP. Also, as rockets get heavier, I find SRBs to become less and less useful. 2) it used to be that you wanted to follow terminal velocity for efficiency, but that's not the case so much with the reduced atmospheric drag in 1.0 and later. I still find myself not exceeding terminal velocity below 25-30km altitude, but this is now because of rocket stability. Going transsonic alters the way drag affects the craft, and quite often crafts that are stable below terminal velocity may not be stable above it. 3) First, understand that the atmosphere drops off rapidly, enough so that other factors become more important than aerodynamic drag. The two major factors are gravity losses and steering losses. For gravity losses, you're looking at two factors. First, if you thrust straight up with a 2.0 TWR, 1 G of gravity cuts your acceleration to 1G of thrust upward. If you're at 30 degrees above the horizon, however, your thrust equals 1.0 upward and 1.73 toward the horizon. 1G of gravity negates the upward thrust, but now you're accelerating towards the horizon considerably faster than you were accelerating upward when thrusting straight up. Second, as your horizontal velocity increases, the more your forward momentum cancels out gravity (the phantom centrifugal force) meaning you spend even less of your thrust fighting gravity. For steering losses, if we ignore gravity for a moment, if you burn in one direction for 1000 m/s of acceleration then turn 90 degrees and burn another 1000 m/s of acceleration, you've only given yourself 1414 m/s of acceleration. If you had turned 45 degrees in the same direction then burned for 1414 m/s, you'd have the same velocity, though not necessarily the same position. So basically, a gravity turn is all about balancing all of these. Turn too aggressively, and you're fighting too much aerodynamic drag, don't turn aggressively enough, and your gravity and steering losses increase enough that they increase than the aerodynamic drag decreases. 4) I haven't tried doing spaceplanes in 1.0 or later, but from what I've heard, turbojets aren't as good for spaceplanes as they were previously. Many players have switched over to either strictly using RAPIER engines or a mix of RAPIER and turbojet engines. In either case, in 1.0, spaceplanes are more about reusability than low fuel cost. Prior to 1.0, I had a no-cargo spaceplane that would come so close to orbital velocity that it only took 50-80 m/s of delta-v to circularize. That's not happening anymore. 5) Different experiments respect biomes at different altitudes. The negative gravioli detector, for example, is the only science part that pays attention to biomes at the "high above" altitude range, all other science experiments will get you one shot at a full-value report. Most, if not all, science experiments respect biomes at ground level. EDIT: SRBs SHOULD be used ASAP, not shouldn't.

The only thing I use it for was very short hops to biomes near KSC.

What ascent profile are you trying to do? If it's the old "10km up then pitch 45 degrees" then that's not likely to work. What ascent profile works is really a per-craft thing depending on the aerodynamic efficiency and TWR of the craft. Craft with a higher TWR have to turn more aggressively and also have greater aerodynamic forces applied, so a high TWR craft that isn't aerodynamic is actually rather hard to get into orbit efficiently because the only time you can safely turn more than a few degrees away from prograde is before you pick up too much speed. For most of my craft that keep the TWR between 1.4 and 1.8, I find that tipping one degree when the craft reaches 35 m/s, a second degree at about 65 m/s, and a third at about 85 m/s. past 110m/s, I just follow the prograde marker. If I got the early part right, I tend to hit 10 degrees pitch from vertical at about 3500-4000m altitude, and 35 degrees pitch at about 9500-12000m. This is the ascent profile that tends to work best with my craft that like to flip. If your craft can safely turn farther off of prograde, you can wait longer and pitch over farther, but I still wouldn't expect to be able to pitch over more than 10 degrees off of prograde.

I'm still of that opinion. The KSC facility is built on a large flat area of the ground, except that it's really flat, not flat relative to the center of gravity of Kerbin, so anything far enough from the center winds up having a slight tilt towards the center. The reason I think you don't notice this without fins is because the initial tilt is so slight that it isn't noticeable without being magnified by a gravity turn starting at ground level and largely controller by aerodynamic forces. Without the aerodynamic forces, craft won't follow the prograde but rather maintain the same heading.

1.0.2 needs a few memory leaks fixed and it needs some tweaking so that direct-to-landing interplanetary transfer velocity aerobraking actually needs a heatshield. Those are the major issues to me. Yeah, they could tweak the aero parameters more so that spaceplanes are a bit more useful.

It comes down to that being a poor substitute, for the most part. In particular, if someone accidentally enters the SoI with a periapsis close to the center, rounding errors will tend to slingshot the craft out of the SoI at Kerbin's escape velocity or higher. You can already fake L4/L5 in patched conics, which are the two you can use without station keeping, and the points that need stationkeeping (stable on two axis, unstable on the third) don't behave close enough to a mini-SoI for that to be an approximation. Basically, the people that actually care about Lagrange points as something other than "an easy place to park satellites and space stations" wouldn't find anything short of full N-body physics as close enough to be acceptable. There is someone working on an N-body mod for KSP, though last I saw it was still in early alpha.