ShadowZone

The switch to Intercept happened in December according to the article. The pandemic was a non factor in the US at that point.

Exactly. I also looked into the three key people I mentioned earlier. Jeremy Ables is now listed as Studio Manager for Intercept Games, but he was with Star Theory for five years, being CEO for more than two. If your CEO who was with the company for half of its lifetime immediately jumps ship when a new offer comes in, something is up.

It's certainly a delicate matter, not being helped by the article using words like "cut throat" etc, mixing reporting with opinion. Let's look at the facts: T2 hires Star Theory to work on KSP2 in 2017. In August 2019, the game is announced. In November 2019, Star Theory gets a 6 month extension of their deadline (according to the article and based on the fact T2 announced the delay in a press release in November). Somewhere around that time, the Star Theory founders try to sell their studio to T2. Ok, let's pause for a second. I was in Seattle and met the developers in September. I also saw bits and pieces of the unfinished game. Until then, the release date was always communicated as "Spring 2020". Nobody of the group that was there actually believed this to be met, especially with how unfinished the game still looked at that point in time. So, here's what's been bothering me: Why would you try to sell your studio to your customer while working on the customer's intellectual property? I usually am more in line with the "big corporate bad" sentiment, but to me it sounds a bit like the Star Theory founders wanted to make a quick buck with a management buyout. We also don't know what the terms they wouldn't accept were. Jumping to conclusions like that unreflected load of drivel of a video somebody posted earlier doesn't help but stir up the pot. Continuing the timeline: At some point in December T2 pulls the plug, cancels the contract with Star Theory. This is where everybody is screaming bloody murder now. What we do not: Was T2 trying to facilitate an amicable transition before contacting the developers directly? Were Star Theory's founders' terms so outlandish that negotiations simply broke down? Or the other way around? Unfortunately the author was not able to talk to the founders, so this remains a mystery. February 2020: the "new studio" video is published and the takeover of the KSP2 devs appears to be complete. What makes me tend to believe this was less scummy than it appears is this: The three top people of KSP2, Nate Simpson, Nate Robinson and Jeremy Ables immediately took T2 up on their offer. Immediately (article quote). I have met Nate Simpson in person and KSP2 is HIS baby, he is living and breathing nothing but love for Kerbal Space Program. So I think he had no choice in the matter if we wanted to keep his sanity. Not sure about the other two, though. We can also infer two things: First, T2 still believes in KSP2. The project was not cancelled, the deadline was even extended further. Second, T2 believed in the work the developers at Star Theory were doing, otherwise they wouldn't have offered all of them (!) contracts within Private Division's "Intercept Games" studio. What makes me nervous: They are looking for a "multiplayer designer" via their jobs website. This could either mean that multiplayer is nowhere near completion yet. Or that they now are actually trying to include microtransactions via some multiplayer angle. We don't know. And we can only speculate until we have more information - which I am trying to get currently. Let's see what the reaction from Private Divison / Intercept Games will be.

I finally was able to show KSP in it's full glory by recreating the KSP2 trailer using just stock parts from KSP1: And I put all those crazy vehicles in here: https://kerbalx.com/hangars/90035

I made a Cybertruck and flew it to Duna on a Starship. If you prefer still pictures, I also put something on Imgur: https://imgur.com/gallery/tjODKOS

I too am very interested in this. I got an entire mission planned where I would revisit the Outer Planets and collect surface science. But of course there's nothing there yet. So I tried to fiddle around the configs myself and created a OPM_rocsdef.cfg file where I tried to invoke the Gilly ridgeline but on Tal. Game didn't crash but I also didn't get any Gilly ridgelines on Tal... hmm... Plot twist: I have no idea how to mod this game

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.

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: