ShadowZone

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.

I did a BFR thing.

I had quite the busy week... launching a rocket from under water, getting a cruiser to Jool and performing a "Jool-5 light" mission, and then ... a small (or rather large) surprise at the end of the mission.

I finally came around trying this unofficial release out. My to scale 2001 space station no longer explodes on vessel load. THANK YOU!

I decided to revisit a classic... the wonderfully weird space shuttle. Then I thought, why not tell everybody how to built it correctly so it stays controllable.

The journey to the Moon would take a few days and on July 20th, 1969, the LEM would safely touch down. I decided to do a Saturn style Eve mission, actually sending a Saturn V Replica to the surface of Eve. I'll try to return the 3 brave Kerbals in it on July 20th. Do any of you do some Apollo 11 anniversary stuff as well? Update July 20th: We now have confirmation that the lunar excursion module has safely touched down in the sea of tranquility. Congratulations to Neil Armstrong and Buzz Aldrin! To celebrate the Moon landing, which occured at this moment 49 years ago, here's the Saturn V from the previous video launching back up from Eve and returning to Kerbin:

After a few weeks break, I did another thing:

It is depending on the mission constraints. If a part of the vehicle may detach and land on the more challenging bodies (Tylo, Laythe, Slate, Eve), then it's totally possible. I am currently doing a "GTO" mission (Grand Tour + Outer Planets Mod). Launched one giant ship into orbit, launched the Eve return vehicle and docked it, started at Eve and went along from there. Of course the entire Eve return vehicle is scrap afterwards, so I'm left with the mothership and the lander designed to tackle the tougher nuts. The new parts also include the entire ISRU/mining stuff, so that helps of course. I already did an OPM tour with one ship + lander, the "Ozymandias" mission, you can watch it here if you so desire.

I decided to launch a Saturn V against its will. Meaning it was on full throttle but it couldn't stop the larger behemoth from pushing it into orbit.

Happy I could contribute to this. Hope you guys enjoy the missions!