Max Que

While the (radioactive) dust settles, what went wrong? The last major release of KSP 1 added features no one was asking for that re-introduced old bugs in basic game mechanics. It took several minor releases to get as playable as the last major version. There are two problems evident here, one is the focus on cosmetic features like rotating docking ports taking priority over basic stability, like orbits. The second problem is the software design was highly sensitive to changes, a lack of stability. The game engine was pushed to do amazing things, and was bouncing off the CPU red-line. Clearly a major upgrade was needed, but the reasons why became lost during KSP 2 development. With KSP 2 the creative design factors led to a terrain compression system that demanded unrealistic hardware specifications, beyond the vast majority of the customers hardware. This is a failure of Verification and Validation, a key process for any development effort. Verification tells you your design meets requirements (like, will run on the customers hardware) while Verification tells you the design works (like KSP 1). In this case the development effort did not meet either case. KSP 2 had significant development time and resources before the EA build came out. The timing of that release was a business decision, not a development mile-stone. The business decision to release the EA build was not the problem. The state of the EA build after that development time and money had been spent is the problem. Far too much of that development time and effort was spent on creative design features at the expense of core stability. If any internal V&V testing detected this prior to EA, it did not change the direction of the development effort. Time spent on things like the impractical terrain system, parts manager, the VAB save mechanics, PAIGE, and so much more burned up development time. Any development time lost to adding the foundations of multi-player was squandered. All the development time was clearly needed on the most fundamental elements of game stability. When the community feedback came in there was (again) no change in the direction of development. We heard about some organizational changes for more efficient development, but once the direction did not change. As for the lack of communications with the community, the old saying "If you don't have anything good to say, don't say anything" seems to apply. So what went wrong? IMO: Misdirected development effort, too many missing / broken game systems for the time & money spent. Failure to V&V in early development, or failure to change development direction if the issues were detected. Failure to change direction after EA feedback came in. Overall the failure to focus on the root causes of the limitations of KSP 1, and why it needed a core upgrade, not a creative re-imagining is the problem These KSP 1 limitations needed to be the benchmark for KSP 2 development and V&V testing through the whole development. Game development demands good creative (artistic) input, but it is a software design effort. It's creative design expressed through software engineering. It need to be organized as an engineering effort, as that is the foundation for the artistic expression. KSP 2 got this backwards.

At what point does a SW project become unsupportable? The last major rev. of KSP 1 added features no one I'm aware of asked for, and broke the game. It took a few minor revisions before I felt it was playable. When new additions cause basic game systems to fail, your project has crossed a line. A fresh start made a lot of sense then, it was pushing the limit. KSP 2 started with a terrain compression system that demanded unreasonable hardware performance. There have been (and still are) basic game systems that simply do now work correctly, or are totally absent. The basic physics of the game are not working, and there is a foundational problem. Landed ships fall through moons, orbit lines disappear and vehicle status changes without apparent reason. Phantom forces cause space stations to roll and rovers to stop and jump. I'm not getting the illusion that my ship (and crew) 'exist' in any persistent way. This prevents the level of immersion I still get from modded KSP 1. The Steam charts tell the story. It's not quite playable, but it is so close. Adding features on top of lingering foundational issues does not result in a supportable product. Maybe having to rework the compression / performance issues took a toll on getting a solid physics base debugged? Sadly, the beauty of KSP 2 have taken a lot of shine off of KSP 1, and reducing my KSP play time. The state of KSP 2 is actually hurting my overall KSP experience. Lets see what the KSP modders can do to fix the mistakes.

I've read a lot from the discord server, by trial and error have written a .patch file that does not upset the log. While the patch 'should' change the capacity, starting charge, and charge rate for the 3.75M RTG, testing shows no effect at all.

I have been unable to find the reference documents, so I'm missing key information: Once I have dumped my text assets and identified a .json file and parameter within that file, how do I format a .patch file to change that parameter? If I want a patch to change the Ec generation rate in "generator_3V_thermoelectric_radioisotope.json", and address the "ResourceSetting" "Rate" value, or change the "UseDecay" parameter to false? If I want a patch to change the ISP range in "engine_3v_hydrogen_swerv.json" to something other than 320 to 1450, how do I address this specific value range? This looks like it should be simple enough. How does the patch file encode the .json file (as seen in the text asset dump) and specific parameter? Without the wiki reference data I'm unsure how to get started.

I have run into issue #26961 in Sandbox mode. The work-around does not actually work.

@RoverDude, it seems that a subtle difference between MKS rover command pods has an effect on KSP bug #26961, where the game throws null reference errors and cannot be saved. If I place a lander on the Mun (conventionally), and then use Hyperedit to drop a Malemute rover near that lander it will trigger issue #26961 before the lander touches the surface while in Career mode, but not while in Sandbox mode. More interesting is that the Akita and Karibou rovers do not appear to trigger this bug in the same way. This bug is not confined to MKS rovers in any way, and was initially observed with the stock MK1-3 command pod. It also happens with the stock MEM lander pod. The first indication of a problem in the log file is: [ERR 23:42:26.330] Input is null for field 'agent' in config node 'CONTRACT' at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at ConfigNode.AddValue (System.String name, System.String value) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Contracts.Contract.Save (ConfigNode node) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Contracts.ContractSystem.OnSave (ConfigNode gameNode) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioModule.Save (ConfigNode node) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ProtoScenarioModule..ctor (ScenarioModule module) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioRunner.UpdateModules () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Game.Updated (GameScenes startSceneOverride) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Game.Updated () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at FlightDriver+<PostInit>d__34.MoveNext () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <5aeafee3fea24f37abd1315553f2cfa6>:0 I asked to have the priority of issue #26961 raised, but the use of mods in my log files was an issue. I was recommended that I test without mods, and to avoid the MK1-3 command pod, and discovered the Sandbox vs. Career mode behavior change. I am now testing in Sandbox mode with mods to verify if this (Sandbox mode) is a viable work-around. I am hoping that the apparent difference in behavior of the MKS rover command pods might help resolve this game-killing bug. What might be different between these rover command pods?

Yes, the log files show null ref errors. I believe I have a work-around for this bug, and I hope this is useful in isolating this bug. There are several ways to trigger this bug, and my testing is still on-going, but it appears that the most reliable methods to trigger this game-killer fail to trigger this bug while in Sandbox mode. I have a KSP.log file of an instance of the bug where the first indication of a problem is: [ERR 23:42:26.330] Input is null for field 'agent' in config node 'CONTRACT' at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at ConfigNode.AddValue (System.String name, System.String value) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Contracts.Contract.Save (ConfigNode node) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Contracts.ContractSystem.OnSave (ConfigNode gameNode) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioModule.Save (ConfigNode node) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ProtoScenarioModule..ctor (ScenarioModule module) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioRunner.UpdateModules () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Game.Updated (GameScenes startSceneOverride) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at Game.Updated () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at FlightDriver+<PostInit>d__34.MoveNext () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <5aeafee3fea24f37abd1315553f2cfa6>:0 In every instance of bug #26961 I have encountered the string "<2afc64dea36946459d4707808bdac511>:0" always appears. The excerpt of the log file shown above was generated without using a MK1-3 pod. The stock MEM pod has exactly the same phantom RCS thruster glitch as has been reported with the MK1-3. Here is a very strange detail: The log file excerpt above was triggered by using the ship lander function in Hyperedit to place a rover onto the Mun within a few hundred meters of an already landed (conventionally landed) lander using the MEM command pod. If I land a rover build on the MKS Malemute rover, I get the results shown above (only if in Career mode, but not in Sandbox mode). If I land a rover based on the Akita or Karibou rovers from the same MKS mod, in Career mode, this does not happen (right away, it may happen later). Why is the (excellent) Malemute rover different? What is common between the MEM and MK1-3 command pods, and what is "<2afc64dea36946459d4707808bdac511>:0"? I have run into this bug with the "<2afc64dea36946459d4707808bdac511>:0" string after re-rendezvous with an orbiting ship, also after driving a rover out of, and back into physics range of a lander, but the simplest (and fastest) method to trigger the bug is landing a MKS Malemute rover within physics range of a lander. Using the stock Apollo style lander you will see the RCS thruster glitch as the Malumute rover is slowly being lowered to the surface. This behavior starts before the rover touches down, and the game cannot be saved. This method of reproducing the bug shows some limits to its behavior such as Career mode vs. Sandbox mode, as well as different behavior under identical conditions based on different rover command pods. Hopefully by establishing some corner-limits we can isolate and kill this Kracken. I will work on testing the Sandbox mode work-around, mainly because there is little worse than completing something cool only to discover you cant save your work.

Same problem here. Any orbiter and lander combination will lock the game if you enter orbit, un-dock and land, then re-dock with your orbiter. An Apollo style mission is not possible with this bug. One detailed bug report describes the problem starting when the un-docking vehicle moves "under acceleration" outside of a specific (physics?) range, and then returning to the orbiting vehicle. I tested this by entering Mun orbit with a lander docked. The lander un-docked and landed, then returned to orbit. At this point saves still work normally. Once I rendezvous with the orbiter and dock the game cannot be saved. Hoping to find a workaround to this game-killer, I ran the test again, but after un-docking I allowed the lander to drift unaccelerated to over 3km from the orbiter before enabling engines and landing. Once again the game cannot be saved after re-rendezvous. There are other ways to generate this bug. Using Hyperedit (is asking for it, but...) and MKS, place a Malemute rover into Kerbin orbit, then into Mun orbit. Use the Hyperedit Ship Lander to drop the rover onto the surface. At this point you cannot save, exactly as described above. What is odd is that the small USI rover does not have this problem. Have not testing with the Karibou yet (what's the point?). I do not see any mention of this being fixed for the 1.11.1 update, but I will test again under 1.11.1 (Windows 64-bit).

I am having several problems with KSP with MECHJEB 2 installed. No other mods are installed, and I'm running under Windows 7 64-bit. Most often the docking autopilot fails to dock. I have tried using the SmartASS docking method, and this also fails in an unusual way. What happens is that I will be closing on the docking port, and as I get very close (<10M?) the ship (station) I am trying to dock to will start to roll away from the approaching ship. When these issues are happening I also notice that my Ap. Pa. orbit markers are not stable. The orbit markers will rapidly jump forwards and backwards along the orbit line. When the game is in this state it becomes very difficult to manually set a maneuver point, and the prograde / retrograde symbols on the navball with also jump around. I am fairly new to the game. Is this a know issue, or am I screwing things up somehow?