StarManta

Not likely; it's a fundamental part of both the data structure of the craft and the UI. Consider this: you click on a part in the middle of your ship. If there's no 'root part', how does the game know whether you want to grab everything above or everything below that part? The only real way around that would be to take only that part, and that seems like a logical nightmare, not to mention very user-unfriendly. Frankly, I'm impressed that they managed to implement the re-centering of the root part. That's not an easy algorithm.

I built a large first stage booster using several of the "Twin Boar" LF boosters, as they were the most powerful engine available to me. I discovered that, when fuel crossfeeding was being used, these engines could run long enough to heat up to the point of explosion; before my last one could use up all its fuel and/or get the payload to orbital speed, it would go boom. But I think, I have all these radiator parts! I only needed to buy another 15-20 seconds, so I slap a couple of the small radiators on that last engine - even a little bit of heat reduction would probably be enough since it'd be running from the moment the engines light up. I launch, and the little radiators almost instantly turn red, which I take as a good sign - they must be removing heat. ....except that when I get to the final stage, the last engine explodes again, with almost exactly the same amount of fuel left in the stage as before. Alright, they're just not big enough. That's fair, it's a big boost and a little radiator. So I unlock the Large size radiator, and I cover that last booster with the things - I think about 20 large radiators overall, covering every exposed surface. Launch again... and again the thing explodes with no apparent change. I eventually decided to use the slightly less powerful Mainsail for that last stage, which had no such overheating problem, and I got the payload into orbit. But now I'm thoroughly confused about the radiators. What do they do? What are they for? It would appear they do nothing at all.

How arcadey it feels would depend entirely on what sound effects are used. Obviously the less important things should have more subtle sounds, but a simple, distinct blip or whoosh or tone would make all the difference.

Wouldn't really work for an ascent stage...

Part of the problem is sound immersiveness, and more impressive engine sounds and sonic booms would help. My main issue, though, is that so many things have no sounds at all. Transmitting science is silent. Electricity running low/out is silent. Drilling for ore is silent, as is converting it. Depleting a fuel tank (e.g. time to drop those radial tanks!) is silent, except for the (often imperceptible) change in the engine sounds. Passing into the zone where you're supposed to perform a temperature scan is silent. Landing is silent unless you land hard enough to explode, and there really ought to be a sound when I lightly bonk against a ship instead of docking with it. Docking, too, is silent. Rover wheels are silent. Cargo bays opening and fairings deploying are silent. Fuel pumping between tanks is silent. Accomplishing mission objective and achievements is silent. Parts approaching critical temperature is silent, and when they fail, is just a generic explosion. Completing a maneuver node (such that it switches from the X to the green checkmark) is silent. Kerbal EVA pack jets and Monoprop thrusters are silent. SOI changes are silent. Running into a solar panel and destroying it is silent. I could go on. I probably will come back and edit this again with more examples. This isn't just aesthetics or even immersion, although they would help that immensely - the audio queues could and should be functional. The sound in the game should let you know that's it's time to take action. Every single thing listed in the above paragraph should have a unique sound effect associated with it. And then there's the bugs. For example: the audio bug when you're throttled up and in map view - anytime you drag the view around, sound stops. Any Unity developer (even most amateur ones) should be able to instantly tell that the problem is that the camera used in Map View has an AudioListener on it, when it has no business having that - the AudioListener should be kept on the camera that renders the real-world scene when you come out of map view, or if not that, put onto a different GameObject that follows that position. No exaggeration or grandstanding here: if I had access to the project file for maybe ten minutes, this bug would be fixed. Yet somehow it has persisted for as long as I've been playing (0.17). The only conclusion I can draw is that the devs play the game on mute, and have been since very early betas. Which is understandable, and would be fine, if they had a dedicated sound engineer as a part of the team. They don't. They badly need one.

Will be tough to give a good answer without a screenshot demonstrating the problem.

I want a companion app that's not standalone, but rather is directly linked to computer KSP. Example: I want to make it possible to show the orbital view on my iPad and all my ship's resources on my iPhone.

The deployment device... thing was a set of 3 things with 4 connectors each. I'm guessing it would've been more trouble to design the third thing with 3 balanced connectors. Personally, I'm kind of surprised they didn't include 1 more satellite just for redundancy, but presumably they ran some numbers somewhere and decided it wasn't worth the cost. Or maybe they'd originally planned for 12, and didn't have time to finish building all 12 when the launch date was coming up. Honestly, you'd have to ask ORBCOMM whether that was part of the plan or not.

The recent ORBCOMM launch by SpaceX had 11 satellites and 1 mass simulator (e.g. ballast) because they had to have a balanced load. This may not be quite so unusual.

Definitely floating point. Literally everything KSP spends any appreciable amount of time on is float-based. Physics, rails physics, graphics, trajectories.... oh yeah and physics again for good measure. Hell, even the UI uses floats (because it's built on the same position data structures as the rest of the game engine). The big question you should ask in CPU benchmarks for KSP, though, is single-core performance. If you have an 8-core processor, 7 of those cores are going to be idle most of the time. The physics is all single-threaded, and nothing else in the game comes close to the amount of CPU that physics uses. (This is likely to be somewhat improved in 1.1 since the upgrade to Unity 5 brings with it an upgrade to PhysX 3, which supports multiple cores - but my understanding is that any single craft will probably still need to be on the same thread, and so a single thread of physics is likely to continue to be the main performance bottleneck.) My advice is probably to get the dual (or more) core chip with the best single-core benchmark you can find.

....You still said it...

My (pretty confident) guess is that we're going to see no visual changes (besides UI) in 1.1, if ever. I say this for two reasons. One, if they were changing anything visually, we'd see pretty pictures in the devnotes, because pretty pictures make attractive devnotes. Two, making all those new texture maps is a LOT of work - I've used PBR before, or should I say attempted to use, and it is not natural for someone who's been working with classic 3D rendering previously. There's no straightforward texture conversion - you have to remake every texture, from scratch. (Wild ballpark estimate, all the textures in KSP, it's probably a man-year or more worth of work.) Converting to PBR would be an enormous investment of labor, and I can easily see Squad looking at the numbers and deciding it's just not worth it.

What you can do is take advantage of Z/X and toggle 3-way symmetry. 1) with 2-way sym, place your first part 2) Turn on 3-way sym, line up your second part. You can line up one of your 3-way copies to be pixel-perfectly aligned with one of your original parts. 3) Use Z/X to change back to 2-way sym, and click to place the part. I use this all the time for asparagus staging.

Wow, I never realized it was that bad. I need to rethink my landers....

Maybe the rule isn't necessarily "they have to connect on the same frame" exactly, but there's no way that's true, either. Docking ports bend and flex all over the place. That why this is an issue at all.

I think the main problem is that this would result in many reviews saying "It's called Kerbal SPACE Program, and they have me tooling around the base and selling fuel?" New players would lose interest before ever setting foot on a rocket, which is where KSP gets fun. This is one area in which KSP is not hurting. Universally, reviews of KSP praise its ability to make every step of the way feel like an accomplishment. As a mod, this is fine, but this would be terrible for the core game.

(Also a Unity dev) At one point I solved this by using a Hinge Joint instead of a Fixed Joint and just setting its properties so that it doesn't actually hinge at all. Hinge Joints are just plain better.... This was many moons ago, I can't say whether that's still the case.

This would be a shockingly easy problem to fix. Right now when you hold F9, it says "Hold F9 to load the last quicksave". All you need to do is change that text to "Hold F9 to load the quicksave from X weeks/hours/days ago" - and if that time is more than an hour or two, it blinks yellow/red.

Say you build two vessels that have a triple-docking port in identical configuration, with the intent to connect all three and create a much more stable connection. Currently, when you dock with a vessel, the first docking port connects, and then the other two "shut down" - you still have just one connection, and then multiple unconnected docking ports. (It's possible to connect with multiple ports, but only if all three connect on exactly the same game frame.) I believe the suggestion is to allow all the docking ports to connect.

Just want to add that the "School Bus" name for this mission is absolutely perfect...

That inclination change is overly pessimistic, IMO. It doesn't account for, for example, the possibility of a gravity assist, or starting the maneuver from a polar orbit. Starting from the right orbit could easily shave off 2 km/s from that. This would at least give you a comfortable margin. It's still a difficult mission, don't get me wrong on that. I would say to build a huge many-staged launcher for a tiny satellite and go for it, but the requirement to have a materials bay makes it that much harder, so maybe not.

I don't see anything in that quote that would imply that they used asparagus staging the way we think of it today - which is to say, a bunch of rockets clumped tightly that drop off two at a time. It sounds like they're just describing a crossfed stage, and "wrap-around" probably doesn't mean to describe asparagus staging. While we're at it, no one has yet successfully built an orbital launcher that used crossfeeding and lateral staging (though, admittedly, I've never looked into whether non-spacecraft like missiles have used it.) The rotational force from fuel churning around in a circle as it does with asparagus staging would destabilize any craft in the real world.

It'll be tough to tell you what's going wrong without pictures of your launcher.

Of these, this is the only valid point - patched conics works now, and changes might break it. That's fair. You keep harping on additional CPU strain, but if you think about it that clearly won't be an issue - in fact, performance would be better. We're only talking about the one active ship being handled this way (the conditions suggested in the thread all prevent switching away from the craft during thrusting for a number of reasons). Thrusting while in this pseudo-rails mode would clearly be lower in CPU than thrusting with all the craft's physics turned on, which is currently our only option. This improves performance during certain situations, and has zero impact on the rest of situations.

It sure does, I've lost several probe craft because of it