rkman

I think the 'heart' is an impact crater/basin: left lobe is the crater, the right lobe is ejecta. (increased saturation and contrast, enlarged)

No longer available for download though Best alternative seems to be one one the probe fuel tanks from Fuel Tanks Plus http://forum.kerbalspaceprogram.com/threads/108238-1-0-4-WIP-Fuel-Tanks-Plus-0-11-2-%282015-07-06%29

Downlink speed ranges from 1000 to 4000 bits per second.

best yet, enlarged by a factor 2

It would be different in that when 'jumping' instead of warping there would be no chance to overshoot. Increasing time warp increases the chance of overshooting, so it would make the problem worse instead of solving it. The calculations are fairly trivial because everything is on rails, so for each body a specific moment in time directly corresponds to a specific point on their orbit, no actual physics simulation needs to be done.

I suspect Squad realizes that would severely restrict the target audience for this game and/or severely dissapoint many customers (who were afer all not warned that this game involves a lot of manual calculation). And just how manual should it be? No spreadsheet? No calculator? And once you do use spreadsheet or calculator, how big a difference is there with having a specialized calculator in the game, other than that being a lot more convenient? Once the game is finished (don't let the "1.0" desigation fool you) we'll see whether or not Squad intents the full KSP experience to involve manual calculations of delta-V and such.

There is a post by HarvesteR on the Unity forum complaining/asking about the stutter. So it seems they are aware of the problem, but they can't really fix it because it is a Unity/Mono thing. Would be nice though if they (specifically the moderators who help in this forum) would acknowledge the fact that the user also can not fix it. At best the user can do a few things that make it a little less bad. (psa: never force ksp to run on only one core, that makes the stutter worse). Hopefully Squad follows this discussion anyway and can benefit from suggestions done by some apparently knowledgable folks: given Mono's shoddy GC, go out of your way not to create garbage (which seems to be in principal feasible with KSP).

(last post on march 10 2015, the problem persists in Unity 4.5) All i know is the stutter does get a lot worse if KSP is forced to run on one cpu core.

Because PhysX' typical use does not involve all particles (parts) constantly colliding with one another. In KSP adjacent parts are constantly colliding/interacting with one another and that makes for a lot more calculations than particles that mostly just fly through the air on their own and only bounce off a wall or floor a few times.

You are mistaken. The debug menu option that enables connecting more than two parts to attach nodes (even though it's called just "part clipping") warns about it being buggy. But the editor gizmos that allow parts to be moved inside one another (aka part clipping) do not.

It is one thing that the game changes over the course of years after when development had just started, and I don't see to many people complaining about it. But that's rather different than the post-1.0 changes that are occurring now, which is what people are currently complaining about. As i've said before: those changes are necessary, but only because the game was not finished when 1.0 was released.

They already have called it feature complete some time back, and the main reason for the updates over the past months is bug- and balance fixes that should have been ironed out before release.

That does not sound like the model that Squad is following: we don't get DLC and a whole lot of new features, we get bug fixes and balance passes of features that were added at the last moment.

"There is an ongoing paradigm shift with software development and distribution these days, and it's fair to say we are caught right in the middle of it. The line between unfinished and finished software is getting increasingly more hazy." - Harvester Might be interesting for the software industry to know that much of their target audience is not down with the direction of that paradigm shift. The fact that developers can easily patch after release is no excuse to publish an unfinished product. And no, "finished" does not mean bug free, but it does mean "does not contain longstanding bugs and does not require major balance overhauls". I'm not even sure there really is paradigm shift, rather than a few big developers getting away with releasing buggy unfinished AA titles. Though it looks like Maxis did not exactly get away with it re Simcity, now apparently having fallen out of favor and surpassed in popularity by Cities: Skylines.

It also why it is good practice to not release software in an unfinished state. It's not like they can undo the premature release so they can't do much different than what they are doing, regardless of paying attention to the criticism: fix the issues in the official release. And what do we think 1.0 is - a designation that implies 'done, minus a few bugs that crept into the final release'? And a developer should be able to redefine that designation without them being criticized for it?

The number of patches in a given amount of time does matter. Four patches in 2 months is quite a lot. Sure, the large number of KSP patches is necessary - because the game still has many issues. It is one thing to fix bugs that are new in the final version, but in KSP many of the issues are long-standing bugs that were not fixed in the final release. Also not many game company release patches that include major features and fixes to those features. Max has actually said after 1.0 that they will now work on properly finishing the game - in other words: Squad agrees that the released version was not finished.

Especially all the bugs.

In addition to reinforcement you can also reduce the cause of the swaying: gimbal and/or reaction wheel force.

Officially yes, practically not. Because there are serious problems with it that need to be fixed.

That is putting the bar rather low though. Imo the fact that games with that many bugs on release can be highend titles is more a critique of the games industry than a compliment to KSP.

I use stockalike, just installed the most recent version. Some engines have a fuel switcher in the part tweak menu, others don't but do have a "show GUI" button. It looked like switching fuels that way works only for some engines but that turned out to be due to mechjeb not showing d-v. Some engines have a "show UI" button which brings up fuel selection for fueltanks... I'm starting to suspect the problem is with Venn's stockrevamp, which i noticed is not yet updated. I think for now it can be concluded the problem is not with RF.

I think Squad is not being schizophrenic, they just gave themselves to little time to balance heating and aero. All versions since 1.0 did have some issue with one and/or the other that needed to be fixed, and fixing it turns out to be difficult. I am going on the assumption that the game will only be truly finished some time after the migration to Unity 5.

I copied my mods to a fresh 1.0.4 install, then installed updated mods including RF (freshly downloaded), but many engine that worked with RF in 1.0.2 don't work in 1.0.4. (no fuel type switcher, and no thrust).

Same here. Between issues still unresolved, new issues introduced, and mod issues, to me 1.0.4 is not better than 1.0.2.