ShadowZone

Definitely! In general this patch feels like they wanted to get rid of some of the most annoying bugs people have complained about for ages. It really has a "let's make the game as playable as possible before it rides into the sunset" kind of vibe.

Most definitely, but I always used the rocket icons in previous release notes. I guess since the community team (Dakota and Mike) were also part of the layoffs, one of them would have gathered this information and added it to the notes. Without them I could only guess.

Here are the statistics for patch 0.2.2, the smallest update in the history of KSP2 and also the one we had to wait for the longest (133 days since version 0.2.1, almost twice as long as the longest wait up until then, 71 days between 0.1.2 and 0.1.3). Version Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% 0.2.0 156 0 0% 0.2.1 68 14 21% 0.2.2 28 0 0% While many of the fixes and improvements are welcome, it's sad to see that this is the final set of things we are going to see, if this truly is the last patch ever for KSP2. I have to admit, I had hoped for more, especially since it was said that patch 0.2.2 was already signed off on weeks ago.

Nah, all good. I got it now. It was just Steam being funny.

Meanwhile there appears to be an embargo for YouTube creators Big /s of course. This is just Steam being silly.

Seriously, Steam? Now? Edit: now it briefly said "content configuration unavailable". Did somebody jump the gun and they pulled the update?

Yeah, the idea was to just take KSP1, freshen it up, stabilize the code base (no idea how they should have done that if nobody teaches you how it works) and add a bit more content. Think FIFA or Assassin's Creed franchise. The core mechanics remain the same, but some fluff around it changes. Then they got enamored with the "interstellar, colonies and multiplayer" vision but somewhere along the line neither timeline nor budget were increased to accomodate such a re-imagining. So, a bit more detail maybe: When T2 gave them the hard deadline of February 2023, everything was still in the game in some form (colonies, interstellar, multiplayer) to varying degrees of completion. Around May '22 there was the notion "it won't be pretty, but we might be able to ship this". The decision to go EA and rip stuff out again was made around September. They did try to get at least colonies in there, but somebody pulled the plug because the deadline was already close and they wanted some other thing in there (don't know which one). I am wondering about the time it takes them to release colonies as well. Apparently "For Science" took already multiple times longer than was expected. One of the issues I was told existed within Intercept Games was a lack of "okay, that's good enough" (and we'll make it prettier later) attitude. If it gets public, it needs to be as shiny and pretty as possible, was the mindset (at least this was how the story was told to me). In software development you always need to do some kind of tradeoff. Let's take re-entry heating: the mechanics of "part gets hot, part goes boom" with a simple heat gauge or flashing parts or something could have probably been integrated a lot earlier than what we got with "For Science" with all the pretty plasma effects etc. Of course it looks cooler, but with the simple "show me just a gauge of what goes wrong" mechanic you could have tested the math behind it and verify if your assumptions about how which parts will behave under thermal load. The way they did it was that everything had to be "complete" before shipping it. Also kind of misunderstanding what Early Access should be. I don't know who made these calls for re-entry heating. But I believe we could have gotten a stripped down version much sooner, same for science and colonies. Build the mechanics, test them, test them with the public, make them prettier on the go. That's how I would treat an Early Access development title.

Ah, maybe I didn't explain this correctly in the video: The "only hired junior people" part was during the Star Theory days when they still tried to do it cheap and quick (10 million, two years). I don't know what the compensation cap was at that time. The 150k was the maximum compensation for engineers at IG. They had trouble getting senior and lead people for that amount and more trouble keeping them. There was internal pushback against this cap, but corporate finance refused to budge. Again a decision that was made outside of the team directly and adversely affecting it. The 200k/employee is "fully loaded" costs (I hope I'm using the correct term, we call it something else outside the English speaking world), not just salary. So per employee you also need equipment (PC hardware, office chairs, desks etc), rent (office space) and other overhead (HR department, legal etc). While some of the latter was offloaded to PD, there's still a more costs that pour into employing somebody. For instance in my country, an employee that gets 50k a year into their bank account (what actually lands in their pocket) overall costs a company double that amount. The 200k/employee average was used as a rule of thumb number, but it was given to me by LGG as well as my sources independently from each other.

Less than 10 people were working on the second game according to my information.

"You cannot NOT communicate." The long silence was in itself a way to communicate corporate's disdain for our community. The silence also made people more willing to talk to me because they wanted the story to be heard. Had PD/T2 decided to be super open and transparent and honest, we would not be at this point.

I think LGG's stunned face when I told him says it all. Nothing beyond speculation, just as we all do.

You're welcome! If there are any questions I can answer, feel free to ask. I felt this needed to be made public after all the intransparency over the past 5 years.

Not really. I wanted to get last week's video out as quickly as possible after I got wind of the news. This week I chose to publish it to release one week after the WARN notice became public. Kind of a "why are you still silent after one week of this" statement. But I also have a "normal" video scheduled for this Friday, sort of a palate cleanser. And unless there is some major development, I want to return to my usual Friday 13:00 UTC schedule (looking at you, Take-Two earnings call on May 16...)

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 As you can see in the video, I started on the night side of Pol. I placed a maneuver node on the day side and time warped to it. There was some changes in illumination, for instance indirect lighting on the vehicle (light reflecting from Pol towards the "belly" of the ship), but the sun itself was gone. Switching to map view revealed the sun there, but it stayed hidden in flight. Logs, saves etc attached in the .zip file. Included Attachments: ForSci_Bug48.mov ForSci_Bug48__SundisappearsatPol_logs.zip .ipsImage { width: 900px !important; }

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 I encountered this bug at Pol. My vehicle was in clear view of the sun, the panels pointed at it, but the game said "blocked by Pol". This was persisting through multiple attempts to repack and unfold the panels. It only went away when I undocked my lander and then switched back to the original vehicle. Included Attachments: ForSci_Bug47.mov ForSci_Bug47.zip

Amen to that. Fundamentalists of any kind should be treated with caution. To stick with my earlier wording, these people are just selling you a different kind of snake oil I like to say that they're principles, not commandments. Or to quote Jack Sparrow (sorry, Captain Jack Sparrow), "they're more like ... guidelines". The whole idea behind the agile movement (or at least, the value that I personally took from it) is to make things more flexible and to be able to react to a constantly changing situation. If you try to force everyone to follow a rigid set of rules (and remember: rules != principles), then you are not agile, no matter mow many Scrum Alliance certifications you paste onto your LinkedIn page. To me, it boils down to the axiom of "inspect and adapt", which coincidentally is also reflected in principle 12. So yeah, people that try to "make you agile" by prescribing certain processes or try to prevent you from coloring outside the lines are oftentimes making things worse. When in doubt, refer to principle 1: is what you are doing helping you to deliver valuable software to your customer? The trick here is how to measure whether or not you're actually doing that. I don't see the contradiction, because 5 and 6 are aimed at different aspects of a software development organization. Principle 5 is more aimed at upper management and how to treat your employees (especially the "trust them to get the job done" part. Oh boy, did I have heated discussions with managers about that one...). Principle 6 is more aimed toward the day to day operations. But you have to acknowledge the time the manifesto was created in, more than 23 years ago. Kent Beck's "Extreme Programming" was only released two years earlier, bringing the concept of "pair programming" to a wider audience (yeah, it had existed decades earlier, but Beck popuralized it). For me, there's a two key things in principle 6: efficient and effective method of conveying information to a development team within a development team Me as a product owner, I'm responsible for the "to a team" part. In my experience, the most efficient way of explaining a feature, or a problem the customer has, is to sit down with the devs and have a conversation about it. The best outcome is when I get a gazillion questions and we can refine the item there on the spot with everyone walking away with the same understanding of what needs to be done. While principle 6 states "face to face", I have had good results with doing it via Teams/Zoom/etc and collecting everyone's input and thoughts on a digital white board (I'm a "drawer & pacer", I need to scribble on a whiteboard and walk around constantly when I'm thinking. I rarely have my camera on in remote meetings because I'm pacing up and down the office or my living room when I'm talking). Again, the manifesto was written almost a quarter of a century ago. They didn't have our means of communication. E-Mail was laggy, chat was minimalistic (yes, I remember and was part of various IRC servers in the Nineties), phone was cumbersome. I know people who prefer writing meticulous JIRA tickets. I have had colleagues who recorded their "tickets" as a video and upload them as attachments to the relevant JIRA issue. It all boils down to this: "are you practicing an efficient and effective method of conveying information"? But it has to go both ways: just because that product owner likes to record videos does not mean the dev team is able to distill their tasks from it. Is has to work for both sides. The signatories of the manifesto wanted to break the death spiral of "throw a spec over the fence, write dozens of e-mails back and forth until you really find out what needs to be done". To come back to the "inspect and adapt" part: if you and your co-workers are comfortable with the current way you communicate AND it enables you to be effective and efficient, then you do you. As before, the question is: how can you measure whether or not this is the case? A dev team might feel good about themselves, but they can still be inefficient and therefore not delivering valuable software early and continuously (principle 1). I fail to see see how forking a team and code base has anything to do with the principles behind the agile manifesto. There's nothing in there that says "you need to do x" or "you have to use tool set y". You mentioned things that "take a lot of time". If you have features that cannot be done within the confines of a single sprint, you have two options: preferably, put your heads together and try to split the item into more easily digestible chunks that chain together over the course of multiple sprints, or - less preferable - carry an issue over multiple sprints. Over the course of my career, I rarely had the latter situation. Yes, it can happen, but only after you made sure there's no other way. Also, sprint cycles and release cycles do not necessarily have to be aligned. You can have two week sprints but release only every three months. If I ever get into the unfortunate position of being a manager, I would be completely hands off about key development tasks like how to set up your code base or branching strategy or whatever. YOU as developers need to be able to work with the tools available, not me. If you have the plumber come over, do you lord over him and say: "No, don't use the wrench, use the screwdriver, I read that in a book ten years ago."? No, you don't. You trust the specialist that they know that the heck they are doing. Coincidentally what you describe, managers interfering into direct dev work, is in contradiction to principle 5. They don't trust you to get the work done, so they mess with the environment because they (wrongly) believe they know better. Screw those people! Management needs to get out of the way of day to day development (principle 5), the team needs to figure out how to best deliver themselves (follow principle 12 to be able to live up to principle 1). This is why the Scrum Master role is so important. They need to keep overbearing managers in check but also need to make the dev team really inspect how things are going and help them figure out what to adapt to constantly improve (which is in line with the Deming cycle and Kaizen both of which were inspirations for the agile manifesto). From what you write I get the feeling you have a more agile mindset than you give yourself credit, especially the way you recognize that organizations need to be flexible and structure themselves to be able to react to change and offer a good environment for developers. These are some of the most important aspects behind the agile manifesto. But your final paragraph talks about methodology and application. As I said in my previous post, the principles are none of those, but just what they say the are: principles. They should be a guiding light to how you organize your work. Some of them might shine brighter for you than others. All of them need to be interpreted and adapted for your use case. I have heard of companies building ships that have adapted their work to incorporate the principles. One big pitfall is what I repeatedly said about "how can you measure that". This is where most organizations start to flounder, because they often fall back into command & control rythms or try to create a tight noose around everyone with some KPI, OKR and whatever fancy management metric they come up with next. People like safety and large Excel files with a lot of numbers give the illusion of being able to control the chaos when in fact you can't often times. One of my other pet peeves I regularly have heated discussions about with our management staff. Another pitfall is scaling. The manifesto is geared towards a single team working together but nowadays you often have large organizations with multiple teams. Along came LeSS, SAfE, CAS etc to muck things up even further, selling the illusion of a "one size fits all" framework you can put to your company. Snake oil, all of them. History time: I was in a well functioning development organization that managed to implement a custom scaling strategy based on scrum and following the agile principles. It was not perfect, but it worked for us most of the time. Then we got new management and they immediately needed to mess things up by forcing SAfE onto us. We were forced into a box, nobody really liked or understood and the end result was less efficient development, lots of dissatisfaction which led to long time employees leaving but management still selling it as a success because THEIR plan was implemented. Textbook failure of principle 5 and also 12. We didn't inspect and adapt, we followed a fixed plan, to everyone's detriment. In closing, I just want to say I really appreciate this discussion, even if I disagree with you on some counts. This is how we can move the conversation forward how to best organize software development work. Maybe someone from the KSP2 dev team takes note and can pull something out of this for them to improve how they do things

Very hard disagree on this. Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall. I have done long term projects in an agile environment with a team doing Scrum. Notice the difference: the environment (the organization, the system within which you act) IS agile (meaning it and the people within it follow the principles). The team is DOING Scrum. There are a gazillion teams out there doing Scrum but that are not agile. They go through the motions, they work in sprints, but it's all meaningless and in the end these teams end up going over budget, over time and not meeting their goals and everyone is wondering why. So how did we do long term planning ("roadmaps" if you will) with Scrum? It all boils done to setting the correct goals, rigorous prioritization and constant application of the maxim "inspect and adapt". Instead of meticulously defining what the OUTPUT should be, the long term strategy must focus on OUTCOMES. Which is why the role of the Product Owner is so important when you are working within the Scrum framework. This role has to constantly prioritize the backlog according to the desired outcomes. The dev team is responsible to generate the output that iteratively gets the software towards the desired outcome. In the end, the customer does not care about waterfall, scrum, kanban, whatever. They want to be able to reach their business goals and the software you produce needs to enable them to do so. Most customers engage in the fallacy of coming up with specific features and asking developers to implement those instead of saying "I have this problem that I need solved" and the specialists, the software developers, take care of the solution. I mean, nobody goes to the doctor and says "I need you to perform procedure xyz on me". No, you go to the doctor because you have some weird symptoms and want them to go away. The same thing needs to be applied to software development. Detailed upfront specifications are mostly done to reassure everyone that things can be planned in a world that is very unpredictable and ever changing. "No plan survives first contact with the enemy", as the old saying goes. As soon as the customer sees the first draft, they will want to change something. Having an Agile mindset enables your organization to adapt to this type of changes instead of slavishly following a rigid plan. In the end the goal must be to deliver the highest possible value within your software.

Not sure the previous one it was merged with or this one apply. It happens really just right after loading up the game and then loading a save game with a craft that is prone to kill itself. You can see in the video that the game still slowly builds up the vehicle, making the parts appear over the first couple of seconds and then destroying itself. My assumption is that the game is still loading some physics stuff in background and once it is finished, it all applies at once to the vehicle, overloading it. Reloading the save always fixes it. Always. And it never happens afterwards, even with hours spent using that vehicle, hopping from it to others, docking vehicles to it. It only happens right after starting KSP2 and directly opening this save file.

I don't have any hard data to contribute but I can confirm that this has also happened to me.

Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 I already reported a crash when docking something with 2 ports. After restarting the game it worked, but I tried to add another piece and then the crash happened again. So it is reproducible. Please merge with my previous report. Thank you! Just logs this time, no additional video (but it does exist if needed). Included Attachments: ForSci_Bug45-DockingCrash2_logs.zip .ipsImage { width: 900px !important; }

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Load the save game from the bug package right after starting up the game. It will result in disintegration of the vehicle. Load the game again and suddenly everything is fine. See also video. Included Attachments: ForSci_Bug46.mov ForSci_Bug46_logs.zip .ipsImage { width: 900px !important; }

Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 I am building a complex ring station. The final pieces need to dock two ports at the same time. The vehicles glitched into each other, the game claimed there was a successful dock (see "clonk" sound in video), then the game crashed (see log in bugpackage). Included Attachments: ForSci_Bug45.mp4 ForSci_Bug45-DockingCrash_logs.zip

I just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied. Again, please change this. It's fine to show "vessel will run out of fuel" or some other kind of warning, but straight up preventing people from doing something that in fact does not hurt their gameplay is just wrong. I know it was said this is because something with interstellar later down the line, but even then I cannot imagine what this might be.

Unfortunately, no. I have only worked in software projects over the course of my career, no hybrid or hardware. But I was involved in a big project where our team was working agile and the rest pretty much did waterfall. The biggest challenge was syncing up with the other teams that worked differently. But here is where one of the creeds of the agile manifesto help: "people and interactions over processes and tools". We tried to get in touch with the right people and managed to work with them, no matter what framework they were using. It was still challenging, but defining the interfaces between teams and having constant communication helped.

I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback". It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times). Please change this! In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?). This process of picking the body of work for the next sprint and committing to it is called sprint planning. After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints. Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature. At least that's the theory. Most software companies/teams use some variant of this process.