ShadowZone

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.

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 I made a mistake during a complex build and pressed "CTRL+Z" to undo what I did. That worked fine but afterwards I was not able to place parts in any symmetry anymore. This only got better after relaunching the game. Included Attachments: ForSci_Bug43.mov ForSci_Bug43-Symmetrygone_logs.zip

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 game, wonder why dV says 0 (instead of over 5000), go into map view to find a completely absurd trajectory that looks like a wreath made out of infinite short lines. Can be remedied by loading other save games or the same multiple times. See video for details, logs attached. Included Attachments: ForSci_Bug44.mov ForSci_Bug44-Superweirdtrajectories_logs.zip

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 Situation: retrograde orbit around Laythe. I want to flip the trajectory, so there is a maneuver plan already set in the attached save game. When performing the burn, the game always refuses to do burn under timewarp in this situation. Being around Jool generally seems to trigger this bug very reliably. Included Attachments: ForSci_Bug42.mov ForSci_Bug42_noBurnUnderTimewarp_logs.zip