StarManta

This is one I'd also love to see discussed! If it's been in development as long as I suspect it has, though, I doubt it - ECS only came out less than a year ago. That said, as long as they're not needing to be concerned with backwards compatibility, it might not be too big a job to change parts of it (e.g. all the ship parts) to use ECS and take advantage of that performance bump. That would be exciting!

No, they're making a clean break. If they supported backwards compatibility they wouldn't be able to do half the new stuff they're planning.

The announcement post mentions a pair of binary planets, so there's SOME level of upgrades from the current system. I'd be surprised if it was true N-body, but I'm not gonna rule out being surprised.

I have a feature to add to this: Undo. If you have dragged it too far in one direction, or dragged it until you realized it was the wrong direction to drag it, you can undo.

I disagree. If this function is available on every part, it doesn't even need a "label and button" like standard actions - it could be just a tiny button with a little eyeball icon in the corner of the context menu. (Since it's a non-destructive action it doesn't need to be labeled - it's safe for users to discover it by trial and error) In fact, I would say that limiting it to certain parts would dramatically reduce clarity, in addition to utility. The probe cores and cockpits already have a lot of options, and another "text and button" option would simply get lost in the list.

The problem is that forces can still translate and feed-back through the docking ports, and that's what prevent them from being on different cores. For example, imagine you have a big space station, and a tiny capsule, connected to the station by a docking port. Now, take another ship, and ram the tiny capsule. The physics engine must not only calculate how hard the capsule pushes back against your ramming ship, it has to calculate how hard the entire station pushes back. The mass of the station, not to mention how it's configured, all factor into the "pushing back" factor - if said docking port is on the end of a flexible 'arm' of the station, it won't push back as hard as if it's in the central area of a solid, rigid station. That "pushing back" calculation is nearly impossible to split into threads, and it has to be calculated a lot, even for non-ramming purposes. That's probably the main reason for not being able to split it into different sections. Some games (I think Space Engineers does this?) get around this sort of thing by having the core of the station be 'static' - it doesn't flex and doesn't move no matter how hard it's pushed. So when the 'pushing back' calculation reaches a static part, it can stop, and doesn't have to care about anything that's connected beyond that part. Thus, each connected part that is physics-simulated counts as its own independent vessel, and can be simulated on a different thread. Possibly, in a future update to the game, the rails physics might be updated to simulate the station core itself and make it static, under certain conditions (e.g. it's not rotating, it has enough solid rigid parts that it wouldn't flex, etc) - but such a system would be prone to its own bugs and problems unless extremely carefully handled, so it might be kind of a long shot.

Maybe you get upgrades to the Tracking Station not by just spending money on them, but by getting X number of GPS satellites in orbit?

I'd like to see the bug report on that one. Expected behavior: house remains intact. Observed behavior: house is on fire. Priority: Medium

Well, it would be if you could see the number without having to keep your mouse over the thing. (This seems to be one of the interface quirks that's getting retooled for 1.1, FWIW) MAYBE if you have an extremely high-ranked Pilot (like 4-5 stars), AND have docked before a certain number of times. But having an auto-docker that newbies can use instead of learning how to dock would remove one of the most satisfying challenges from the game. (Go check out the KSP subreddit sometime, and see how many of the posts are "This isn't much, but I just docked two things and I'm SO PROUD". A widely available autodock would rob people of that sense of accomplishment.) We could certainly use a better UI for docking (more or less what Docking Alignment mod does).

I would probably put up BitTorrent links.

Rockets? I got nothing. But KSP is far more than just rockets: Solar panels. The foil on the LEM. The skin of the Command Module, as posted earlier in the thread. Spacesuit helmets. Windows on every module and capsule.

Right now, KSP is still using the older shaders/materials, and probably will for a while. Unity 5 introduces new Physically Based Rendering materials, which have "shininess" builtin - you could literally write a slider to make a part more matte-finished and less shiny, and vice versa. With reflection probes*, these would properly reflect the world around them, at least in terms of planets and the cosmos. (self-reflection is still a pipe dream for realtime graphics) Even better, even matte-finish parts would benefit - they would reflect Jool's green or Duna's red without the need for a PlanetShine-like workaround, and they would even correctly (and subtly) reflect greenish or blueish as you fly over grassland or ocean on Kerbin. And it does all of that pretty darn efficiently - it's definitely slower than the classical shader model, but overall you probably wouldn't be looking at more than 10-30% more work per frame for the GPU. (And GPU's are almost never the bottleneck for KSP performance anyway.) At worst, I'd expect that your 30fps game would drop to 25fps, but if you have a good video card, you probably wouldn't notice any change in framerate. Every part could be a seamless blend or matte and shiny bits and everything in between. Your solar panels could have shiny blueish glass bits, metallic bits, and matte plastic bits, all rendered in a single material. Same for capsules. Also, Unity's material supports masking out a smaller repeating texture/bump map in specific areas, so you could have e.g. a highly detailed wrinkly aluminum foil look (yes, including the gold tint) integrated seamlessly into the broader texture map. And it would look incredible. There's no two ways about this. It's probably one of the few aesthetic choices that universally looks better, with the only possible exceptions being cartoon-like games. (And even then, a lot of modern cartoony games have realistic aesthetics that would look great with PBR, so "but Kerbals are cartoony" does not qualify as a reason not to use PBR - the Kerbals would look better with PBR, too.) * Reflection probes aren't cheap to render, but on this scale reflections don't change very often - Squad could set reflection probe re-renders to happen at any interval they like, and might even be able to spread the work over several frames. "So flip the switch already, Squad!" I can hear you saying. But, there is a catch. PBR materials use none of the same input textures as the classical shader model. The normal maps are almost the same, but even they would undoubtedly require tweaking. In order to take advantage of PBR, Squad would have to redraw every texture in the game. (Technically they could do it piecewise, but that would look pretty darn awkward to combine the two aesthetics.) This would probably occupy one artist for years, so in order to get this done without crippling other visual tasks, my guess is they'd have to hire more artists just for this (I don't think Squad has multiple texture artists on staff, but I could be wrong). Squad have probably considered all of this, and I'm sure they've made their own decision on whether the improved look would be worth the design time. I can only guess - I suspect it'll be something they do as part of a larger graphics pass on the game as a whole... eventually.

#3 and #4: Wheels have been overhauled for the upcoming 1.1 - wait for that, then revisit. That said, jwbrase is correct, and "broken wheel" can cause some serious trouble if it happens while moving. There's a reason that IRL autonomous rovers on other worlds max out at around 0.1 mph. Exploration in KSP is largely about the challenge of getting there and back, and aside from the little ones, every planet is wildly different on that front.

I am assuming most of the people in this thread have never seen the Delta IV Heavy.

I think a visual marker in the main camera view makes a lot more sense than anything you could possibly put on the navball.