Eric S

It's really hard to say from the point of view of someone that doesn't have access to the code. There are microbenchmarks that show that some of the physics simulation features that KSP uses have been improved by 50% even on a single core, but microbenchmarks seldom accurately predict real world performance. As for multiple threads, it comes down to two factors mostly. The first is how well the code can be run in parallel. I haven't found anything indicating that PhysX can break a single collection of connected parts into multiple threads, and if this is the case, then you won't get any noticeable benefit from multiple cores in the common case of KSP, when a single craft is in the physics bubble. Docking two craft of similar complexity would be one of the cases where KSP should be able to use more cores effectively, and operations in and around bases composed of multiple craft might actually be able to effectively use as many cores as you have craft. Second, multiple threads don't linearly scale the performance in PhysX. Three threads gives about double the performance of a single thread (again, in microbenchmarks). Personally, I think overall I'll see more benefit from the general optimization and increased accuracy of the updated PhysX than I will from the multithreading, but every little bit helps.

Depends on your definition of "much better." As I understand it, Even the latest PhysX can't use more than a single thread for a single craft, which means that a multi-core processor isn't going to help the case of having a single, complex craft. On the other hand, docking two craft of similar complexity should be quite a bit better. Also, the latest PhysX is quite a bit more optimized than the one that Unity 4 uses, with some of the simulation features that KSP uses running up to 50% faster. I don't think we'll see 50% faster overall from a single thread, but anything is good.

Procedural Fairings have a few other advantages that I'm aware of: No size limit (you can have a size limit, I think, but it isn't required) Clamshell-style fairing separation, rather than the confetti separation that stock fairings currently use (hopefully we'll get an option to use clamshell fairing separation in 1.1, and possibly other settings) Rounded fairings as an option as opposed to just pointy fairings

For some definition of many. For every thread like this there are two where the OP listens to advice and manages to overcome their launch issues, and some that do say that they're having as much fun after adapting as they did before. You might want to reread the terms you agreed to when paying for the game. You were promised the version available at the time and future updates with no promises that there would even be future updates. Personally, I find 1.0 (and 1.0.2) to be a major improvement over 0.90, largely because of the new aerodynamics, in fact. This update wasn't perfect, but none ever are. As long as the game continues to get better, I'm happy. When it stops getting better, I'll look at all the hours of enjoyment I've gotten out of the game, and be content with the fact that it was a good run. Given the number of memory leaks that were fixed between 0.90 and 1.0, this is hardly an argument in favor of 0.90, especially because this memory leak can be modded out, unlike the 0.90 memory leaks. Nice way to seize the moral high ground threatening piracy, BTW.

Screenshots would help. What's your velocity within Duna's SoI?

Ah, the AV-R8 winglet, I thought you meant the early tail fins which are much smaller and are still more than enough to keep the rocket stable. The early tail fins, however, weren't in 1.0. As for the rocket you described (now that I correctly understand), it was also unflippable in my testing under 1.0 and 1.0.2, so I still can't reproduce this. I wouldn't go so far as to say "many." Looking through this thread, the majority of pro-1.X aero posts couch the description with "more realistic" or "semi-realistic." Even early on in 1.0 devel, it was obvious that the devs weren't aiming at something even as realistic as pre-nuFAR FAR. It's realistic enough that nosecones help instead of hurt in most cases, tail fins will try to keep the craft prograde when properly placed, orientation of parts matter, and dense things have a faster terminal velocity than less dense items. That's a huge step forward in realism compared to old stock aero. Still, if you really care about realism, you install FAR. I haven't felt the need to do so post 1.0, unlike 0.90 and earlier.

The current system models physics for everything within about 2.25km, and everything on a suborbital trajectory within 22.5km. The thing with pushing that second number farther is that the mods you spoke of sometimes caused problems if you pushed the physics bubble too far due to FP rounding issues. From what I remember, 20-30km was the recommended limit with those mods.

Well, most of it will sound repetitive, but: 1) Keep in mind that we're all here because we're passionate about KSP. In some cases, it may be a love of a specific vision of some future KSP which doesn't align with yours. Their priorities may not be your priorities. 2) Don't attack people. Critique ideas. 3) Keep criticism constructive, and don't try to dictate the precise solution. Not so much here, but in other communities, you'll see people that think that "You need to fire this guy!" is constructive criticism. 4) If you want help with a problem, be as specific as possible. Generic questions get mostly generic answers. For example, at the moment a lot of people are having problems with their rockets during launch. Given that most of the advice on that topic has to do with center of pressure/center of mass/thrust to weight ratio/ascent profile, including a screenshot of the craft and a description of at what point in the launch you're having problems would be helpful. 5) #4 also applies to criticism. I think part of the reason Squad is getting conflicting feedback on aerodynamics is that people aren't being specific enough. At least one forum member is of the opinion that the problem isn't that the air is too thin or too thick, it's that spaceplane parts aren't acting as low-drag as they should be, so rocket people want a thicker atmosphere than spaceplane people. 6) If you're just venting, say so. We've all had times we just needed to vent, and sometimes the venting has come across as an attack on something we're all passionate about.

Not me, usually when someone is looking for help, they say what they're problem is, we ask for screenshots and give generic advice, and they either come back with screenshots or saying that the advice helped, and if they came back with screenshots, we give more specific advice. It's not a debate, the OP isn't trying to convince anyone of anything, and they tend to be more open to what is being said, so it wraps up fairly quickly.

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.