ShadowZone

I tested the Launch Escape System for my upcoming "Apollo 50 ... LITERALLY" mission. Just some minor damage. Next iteration works better

I landed a Saturn V. On its side. Sort of.

I did. In general you can find out a lot about KSP from analyzing savegame files and/or config files, especially for newly added parts and features. There is for instance a .cfg file that defines which terrain feature is present on which planet or moon and in which biome. I am pretty sure modders can use the structure of that config to add their own surface features for scanning. I'm really hoping this might one day apply to my favorite mod of all time: OPM. In regards to the save game edit: I put up a screenshot of two saves, one old and one new. The old one has a value of "-1" for the terrain features. The new one sports a random integer at that place. So if you change the "-1" to a random integer, it will enable these terrain features https://imgur.com/a/xC2ak4q !!! HOWEVER !!! I am pretty sure this voids any chance of official support you could get if this does not turn out the way you might like For instance: a cryovolcano could spawn right in the middle of your landed Jool-5 ship and ... Kaboom! So use this information at your own risk. And backup your save file before you try this!

Well... And then there's the undocumented hours in my RO/RSS, OPM and older version installs.

@AFF I totally had the same problem with wheels during my "Purple Pain" Eve exploration series. That planet is just evil. As to the thread: I did a Blue Moon lander replica, flew it on a New Glenn replica and tried to land the booster on a ship. Things didn't completely turn out as I planned...

I paid 18 USD to see "Avengers: Endgame". I enjoyed myself for 3 hours. I have more than 4200 hours clocked in at KSP - and that's just my Steam install, my other variants (RO, OPM, ... ) not counting. I paid about 30 USD back then for KSP and 15 for Making History and I will gladly shell out 15 for Breaking Ground. All in all a total of 60 USD for a game that already gave me thousands of hours of fun. Triple A titles ask for the same amount of money for a hammy single player campaign and a derivative multiplayer part I am not interested in. Add to that, KSP taught me a lot about orbital mechanics and space travel and opened my horizon in all things space. That's invaluable. And of course it's a monetization strategy. The base game does not have the same pull it did years (!) ago. The company behind this wants to survive, maybe hire another dev or two. I can live with that.

Oh that will definitely go up on my channel.

UUUUUUH YEAH! The things I will be able to do with this. 500 ton Kerbal BattleMech incoming!

I failed miserably trying to get an Orion/ESM/ICPS thing into an orbit around the moon in Realism Overhaul. Any variant or mod part I test, the ICPS inevitably runs out of fuel way too early. I mean it would be a lot more bearable if my RO install would start in less than 8 minutes...

which is ... ? I really like the new look of the small engines.

Just wanted to post a finding from my experiments: After freshly loading MM 3.1.2 via CKAN into my KSP 1.6.0 install, this happened. Neither KER nor the game itself picked up any dV readings and the nuke appeared to fire in the SPH. Solution similar to the issues described above: Close the game Verify install files via Steam (found 2 files that couldn't validate) delete PartsDatabase.cfg Start game --> same error Close game Start game --> error is gone I hope this helps anyone who encounters similar phenomena.

Just had a few days with the beta, but so far 1.6 feels like a really solid update. Well done!

You're right, I only have a vague understanding of "game development". I was too busy delivering working enterprise software for the past years to look into that. One dev in my team was once developing games for a small publisher, though. He says it was hell. How about we skip the ad hominem and get to the facts: A bug breaking something that has already worked in a previously released build should not happen. No matter if it's a game or any other software. But it happens every time with a new KSP version. It has become custom to wait for the first hotfix after a release until you can actually play. This should not be necessary. There are multiple ways to mitigate the risk of introducing new bugs or breaking existing features. Even more to prevent them from being released. Some are organizational, some are technological. Automated testing, pair programming, mob programming, pair review, regression testing, exploratory testing are just a few of them. What works best? The Agile tenet holds true here: Inspect and adapt. Find out what fits for your circumstances and implement it. But: the inspecting has to begin at some point. 538 issues in KSP's bugtracker have not even been looked at. Ever. Maybe half of them aren't even bugs or are outdated. Who knows? Well, nobody, because nobody seems to take the time to analyse them. For me this is an indication that not enough resources are spent on quality. I am not even talking about code quality, I am talking about taking the reported income and acting on it. Yes, I build gigantic vehicles in KSP, it's kinda my thing. But I was able to build 1600 part battlecruisers in KSP 1.0.x without ever experiencing the amount of memory grab KSP performs nowadays. The problem lies with fairings and the new structural panels. As soon as a decent amount of them are in play, the game goes into nightmare mode. Especially if you work with subassemblies and delete and load parts of your vehicle. One quick fix could be to disable the fairing preview animation or the many attachment nodes on the new panels with the press of a button. To re-iterate, this type of problem was not present in previous versions, even with significantly more mods. I know of other KSP players and YouTube creators that stick to version 1.3.1 due to this and many other issues. And as I mentioned in the video, bugs are only part of the issue. The problem with technical debt is that over time a development team starts to work itself into a corner if they do not get rid of it. You chose one library over the other because it's faster to implement but you know that the other one would have been better in the long run. You hack your code and leave //TODO comments that will never be looked at again. You hardcode stuff instead of doing it the right way. All of these things enable you to get your product out on an arbitrarily set release date. But it's like taking up a loan with high interest rates. In the long run it will cost you more. And if you don't pay it off, the debt will pile up. Usually it's mismanagement - not believing developers when they say they need more time to get rid of tech debt - that leads to the mentioned flatline in my video. Don't just take my word for it, maybe the father of the Wiki, Ward Cunningham, might convince you: https://youtu.be/pqeJFYwnkjE I would very much like to know how KSP development is organized nowadays. Are the team or teams colocated? How is testing set up? Is testing (and in what form) part of the definition of done (if such a thing exists)? How is the release validated before shipping? How is bug reporting handled? Is this also the job of the developers (it shouldn't be) or are there dedicated support/quality engineers looking tat the new income and analyzing it? There are so many ways software development can be improved. But as mentioned above: somebody has to start the inspecting before the adapting can begin.

I finally came around to release a video about the biggest spaceship I ever built, measuring 108 x 70 x 32 meters and having a wet mass of 4528 t ... it's also 1658 parts, so using it is a hell of an ordeal.