Wallygator

well, late 2011 iMac here. also Macbook pro 15" 10.10 behaves differently on each. Reliability has been reduced in my opinion. Not just with KSP. Do what you want - just remember to make a full validated backup on Mavericks - otherwise reverting is next to impossible without extra effort.

I suggest, Your decision to upgrade to 10.10 should NOT be driven by improving ksp performance. I upgraded... and as a result my overall system degraded to the point where I cannot run any normal applications let alone ksp. Don't do it. Wait for 10.20.1 or 10.10.2 Check the Internets. It's not good news regarding 10.10.

I think you are on to something here.

All I'm suggesting is the deterministic elements of this type of scenario should be fully within the control of the player.

Agree 100%. (No strange die rolls involved)

So where is the ksp Esa cooperation? Similar to ksp nasa. I think there is/was a major opportunity lost in ksp viral marketing here. Asteroid redirect vs comet landing. Seems all the major game sub components were available for a quick win. Just my opinion...

If the objective of career mode is to guide a player through a pre-determined set of parts and missions then just stick to the tree as it stands (with all the above suggestions considered as tweaks) If however the objective is to create non-deterministic play space (not sandbox) where the player develops a space program with as few boundaries as possible, then the tech tree should be split in many parallel threads (by major part type - ro a star as mentioned ^) and then into branches for for each specific part (for the most part - a few exceptions like ion drives or LNVs coming in a bit later. Allow the PLAYER to choose what parts are desired first. Grant 10 points and no tech available. You want the command pod, then unlock it. You want ot start with probe first then lock that. This would allow a wider range of play experiences while avoiding game "play sequence" mods. I think the current paradigm of the tech tree is too inhibiting.

one further point... As snipped from the reddit... Harvester types: "As for random failure events. This is one idea I'm very much against. It's something we designed out of the game on the very earliest design docs nearly 4 years ago now. The moment you (the player) realize that a failure happened through no fault of your own,..." I would suggest here that Reliability and Risk are two CORE concepts in space systems which if ignored lead to a highly unrealistic perspective of the whole systems view of managing a space program. Reliability should be fully under the control of the player (and any decision to ignore it) If a player does not put enough science and/or testing contracts behind the final unlocking of a part then there should be in increased change of mishap when using that part. A player selects the desired reliability level based on the amount of risk they are willing to take. For example: If you select a low reliability ion engine for a probe to Eeloo and it fails to operate then what is surprising about that? OK, make it part of the difficulty settings - I'm fine with that - "brutally hard mode". So on that specific point, I must respectfully disagree with Harvester. I recommend a requirements change control be initiated.

Concerning the content of the reddit post: The lead in comment regarding the community being split in multiple directions regarding various proposed changes is clearly a symptom of poor expectation management. In the NON KSP world, Business change requires that all stakeholders either fully support the changes or at the very least are not actively campaigning against it. Difficult to fully address with 100k stakeholders (!) however, throwing nearly completed ideas in the forum-space and expecting support is ludicrous (not in the Rap context). If it is the intention and desire of the Dev team to garner and assure higher levels of support for proposed changes then the "Game-feature/change conceptualisation and pre-production lifecycle" should be assessed for opportunities to open up earlier dialogues around significant changes. Lesson learned on the Kerbal experience bit. (I do this kind of this for a living, transforming business processes and managing strategic and tactical change so I have a higher than basic understanding of the complications here) Concerning the "action" of reddit posting (not the content but rather the communication channel)... In the forum navigation bar we see Facebook, Twitter, Tumblr and Youtube. I would have NEVER known about Harv's comments without this thread - How many other social media channels are not linked in the forum nav bar? The UX for KSP is rather ok, but the UX for the KSP community not so much - referencing the above comment, this constitutes a high potential failure point in the "Change communications" process. All that said, in regards to the technical description Harv posted, I tend to agree and support his logic. (Now... watch while we land on this here comet thingy...)

Lookup the "Trajectories" mod. I think it also does exactly this. I agree something like this is quite useful perhaps obtained as a "onboard landing computer" somewhere in the tech progression. EDIT: Sorry typed should have indicated "I looked up..."

Probabilty?

I would propose that part are NOT upgradable, but rather that the "reliability" of parts is increased by research and by testing.

I suppose everyones perspective of "simple" is based on their individual experience.

Triangular Structural Panels please.

Yup. I also suggested this in a separate tread. I support this.

Eliminate the tech "tree". Let career mode players research and purchase individual parts in any order.

I believe it jumps due to a representative move into a Beta stage. Don't worry, we could still see many updates between .90 and 1.0

I tried a side/lateral deployed rover on my apollo-style a few months ago - worked ok most of the time... The rover panel is rotated out for view in the VAB but is flipped up before launch - a radial decoupler lets it pop off the lander, then an inline decoupler fires once the rover is upright.

I'm always hesitant to join a rant but this strikes home. 1) The crashing behaviour is unacceptable. Regardless of the early access concept. Its a delicate balance and the Devs are right now on the knife edge (in my opinion). Major improvement MUST be achieved prior to declaring .90 beta. 2) The game start interface IS substandard. Full Stop. It should be much more elegant and simplified. 3) KSP thrives on a modding environment / ecosystem - This is not to say the Modding ecosystem has been nurtured effectively. I cannot entirely agree with the OP, but I "Feel" that the Devs could provide a more elegant implementation. I suggest Squad/Devs appoint a "modding community coordinator" to take SPECIFIC focus and control of this and assure consistent behaviour of supporting processes and policies. This is not about writing code. Modders should be considered a Critical Success Factor for KSP strategically - and therefor the entire system by which they are engaged should be carefully managed and NOT left to random evolution. ROWSDOWER>>> I expect you and the devs already apply a good portion of your mental bandwidth to this, however, you would probably be well served if you had a minion 100% focused on this.

Thank you for your input. This is no longer a KSP issue in my opinion. I have been systematically attacking this problem in a similar fashion to what you suggest already. Please note that I am not going to update the OP thread of this until I get a stable OS X install. This instability only started following an update from Mavericks to Yosemite. I highly suspect this is not a memory issue. However, I am leaving no stone unturned. There are others out in the internets who are surfing the exact same problem and we are all awaiting some patch from Apple. I am however very happy to hear from other OS X users who are attacking this issue.

Never = launch clamps and or revert.

In general I do not like the idea of a kerbal improving its capability due to flying missions. They should be trained first and then receive any benefits due to the training. A trained kerbal must complete the mission he is trained for. If he dies you loose the training investment and rep. If the kerbal survives the mission then he can be trained for the next one. A kerbal trained for kerbal orbit and docking would not require any additional training if that were the only type of mission he was used for. This would make mission planning much more engaging. Not only would you need to design your vessel, but you would also need to design your training and crew profiles. Just a thought. EDIT: Threw my thoughts into a blog entry http://forum.kerbalspaceprogram.com/entries/1780-Kerbal-Training-Reputation-Records-Reliability-and-Danger%21-One-players-view so to avoid side-tracking or hijacking.

My issue (me being the OP) can today best be summed up as an unreliable OS X Yosemite install. I cannot not point any fingers at KSP untill the OS is stable.

UPDATE: Seems the reinstall of Yosemitie in effect has done nothing. I wake this morning to find the system crashed and restarted (KSP not running at the time) (Waves hand in air and curses Apple...)

Probably both. Either way, I'll keep monitoring it and update this thread as time passes. Thanks Tao for all your Help!