Wallygator

But since Kerbin is a fraction of the size of Earth, then should the dimensions of the KSP rockets be upscaled to show parity against the IRL vehicles? Just a thought, not a requirement.

However, at the end of the day if there is nothing to be done in space or on a surface other than the dismal activities currently allowed, then KSP will gently die a slow death - unless the devs decide to release it as total open source for open ended community based support and expansion. I don't think that will happen. So if not, then they MUST (at some point) advance (and communicate to the market) plans to improve content, development capability, and release reliability. This may already be part of their strategy - or maybe not. Let the market decide Squads' fate (and KSP's) in the absence of an understandable plan and adjunct communications.

My expectation is that new "content" (not to be confused with any revised [U]mechanics[/U] currently planned) will not be announced as part of any delivery cycle until 2nd Qtr 2016 or beyond - just a prediction based only on tarot cards... EDIT: And for my record "New parts" do not count as "new content", sorry.

That was nice. Well documented, but not too much fru fru unnecessary stuff. Nice to see a well reported "vintage" mission report in these current times!

I'm waiting for a mod that creates population centres all around kerbin, and crushes a players rep when debris drops from the sky nearby them... that would be a very interesting game mechanic. Still, but more on topic - the factors that sculpted the apollo mission profiles were far more than just fuel usage. Ranger and Surveyor missions could execute a direct ascent, but a manned mission required quite a few more safeguards.

Everything is cheating. Unless you actually build a real rocket and actually send it into actual space, actually.

Bug fixes, yes. Memory management improvements, no. This coming from an OSX user.

Stay on two legs. Then optimize for one.

Nice RP. Huge ship for Minmus - but I assume you will reveal all later. Well done on the reporting! Looking forward to seeing what you have in store.

Since Tylo has no atmosphere chutes will not work as intended. You must first install them in a reverse configuration.

Commendations on this. I would also suggest there are likely additional multiple related dimensions that contribute to engine assessments such as Thrust, ISP, cost, weight - all these factors likely need to be considered in kind and not to the exclusion of each other. My opinion is that unless we (which only includes me as a consumer) start using the calculus, a proper solution shall not arise. Sadly, I forgot how to do it about 30 years ago - hence my consumer role. ;-) Till then, I shall remain stock. Rep on its way.

Collecting and having stats available is straightforward, yes. I cannot disagree with you. But code alone will not deliver a viable service capability. You are also quite perceptive, I do not have decades of experience creating or managing digital game support systems - rather decades of experience creating and managing a wide variety of business systems and adjunct support processes including codified elements. Perhaps my fundamental mistake is assuming there are common principles. I apologise if this is an incorrect assumption. That said, I do not in anyway discount anyone's experience on this particulate subject. To terminate my contribution to this thread in a constructive manner --> I believe everything you said sounds great. I await the moment where i'm convinced that THIS particular game and THIS particular dev team can do it. Perhaps someone could volunteer time make this all happen seeing as it is so straight forward. That would be a really good (actually great ) outcome. In good conscience, I would even purchase another game license to support the effort, knowing that such an effort was underway. Over and out.

OK, I'm not going to attempt to educate the "masses" and please don't take this as personal since I have no idea of any forum member's (or your) level of experience pertaining to this particular topic. I (perhaps wrongly) assume that folks contributing to this thread have a reasonable level of experience addressing core elements of IT and service support. (Disclamer completed) Regardless of any preferred method of "Reporting errors": I STILL FEEL UNCONVINCED that our beloved (and in my opinion still over stretched) dev team has the capacity, insight, strategy or process in place to effectively and efficiently comprehend and address this potential plethora of automated crash reports that will overwhelm them following implementation of such capability. "Liberation" assumes that the appropriate processes, governance and prioritisation capabilities are in place and validated well ahead of the "tsunami of crash reports" that will ultimately ensue. And, If folks (you the reader) don't comprehend the necessary elements of human intervention that automated crash reporting implies, then I kindly suggest the community should start code-ifing it all now. Let me know how you get on. I genuinely encourage anyyone who dreams of automated crash reporting (that confers comprehension of deep problem management and mitigation) to wake up and join the present day IT profession. TL;DR: This is not simple. NOTE: Apologies to Squad if the above is already incorporated into their master plan.

Your are correct, Sir! I doff my hat to you!

If properly implemented, the user is allowed to opt out. But, I still agree.

If a tree falls and there is no one around, does it make a noise? I like the idea, but have no idea of knowing if the dev team is geared up to handle the volumes. The process and organisation required support automated crash reporting is likely not in place and there are also probably no plans or strategy defined at the moment to implement any of it. I wait in hope...

Sounds cool. I would suggest launching some refueling depots to be pre-dropped in the sea at preselected points in the journey - then you just have to sail toward them. Just a thought. Looking forward to following this one!

One way to maybe end these types of discussions whenever any new engine is released, is to rejig engines entirely so that players select bells, chambers, pumps capacities, gimbal ranges, other enginey stuff etc. and then configure their own. Slow heavy pumps at lower end of tech, small efficient ones later on... Static bells lower in tech, procedural bell shapes later on. etc, etc. etc. might need some general smartness and creative thinking on the required modelling, scaling, cost balancing by feature, etc. Whatever... I'm sure someone somewhere has already suggested this. Wait - then we would argue about bell shapes! Argh! ;-) On topic - I like the vector, Victor - don't touch it.

Uhhh... Thanks for that. Not sure I would have known it even existed. Seriously. Thanks.

I am going to be "reel" disappointed if there are no fish in the water. Other than that it sounds ok. EDIT: I guess this makes landing on water moons a bit easier now...

I will build a rocket, and send it into space. (not actually, just virtually) Maybe conduct a lemming mission to Duna

It is not "obvious". "Lots" requires hard data to confirm. "Like" is a matter of perspective. Regardless... you are entitled to your personal viewpoint. My view is they should release without the hype. Let the release itself generate the hype if it deserves it.

the 1.0.5 update is a good idea. Running a bunch of "introduction videos" in advance of the release is a waste of effort. Especially, since the dev notes already toughed on the majority of features. Dugh! If there is still experimental and bug testing going on, then why pre-release? I think Squad is stuck in a a "pre 1.0 release process paradigm" and they need to get out of that. More frequent and smaller content releases (even surprises without announcements) punctuated with well planned and tested engine evolution releases is the way to go.

Yes, too many related threads trolling on the same subject. 1.0.5 is a good strategy - separating content development from core engine work - keeping work streams focused on specific deliverables is always a good thing.

I have too many saves running concurrently across two computers and get frustrated with managing ship constructions between them all.