Lyneira

Thank you for this great write-up! I'm especially interested in the proposals for presenting part stress information better in the parts catalogue, VAB and through visual and audio cues. Regarding performance, I do wonder how much can really be gained since to calculate stress on each joint, you still need to propagate forces from impacts, wheels, drag and thrust throughout the vessel. I'll also reiterate my desire here for such a system to allow for parts to be connected in loops, allowing rectangles, triangles, toruses etc to be built much more stable (to share stresses over multiple joints) and for true multi-docking port connections between vessels. It might even be a necessity to enable players to build structurally sound vessels when going ambitious.

So much this. I've long been bothered by it but wasn't sure how to explain it, thank you for putting it into words. The white specular glare from the runway and terrain at sunset is what bothers me most about this.

The unit label for surface gravity in the tracking station is wrong. It displays m/s^2 but the numbers are in units of standard gravity (g, 9.8 m/s^2). Once you take that into account the numbers are accurate.

They might not change from the burn directly and higher TWR makes this effect less, but as you execute a long burn in low orbit, prograde does change with respect to the point the maneuver was made. I can't be sure, but I do wonder if this also results in burn inaccuracy the longer a burn takes relative to the current orbit.

Agreed. Trying to get to Gilly's surface from low orbit is even worse, as the orbital speed is far lower than even Minmus. Better off using extra delta-v to boost yourself at the moon, but it should be possible to timewarp through this at higher speeds.

A good point that I've sort of had in the back of my mind as well while making my posts - I like to mention performance and stability as separate issues when I talk about the state of the game. Here's how I personally view these, and my attempt to add a definition for accuracy. Performance - Does the game feel smooth to play? This includes framerate, framerate stuttering, scene load time and UI responsiveness. (I'm looking at you parts manager) Stability - Does the game function over time without failure, in the full range of situations the player can put it in? Lack of stability includes things like VAB construction bugs, flight bugs leading to sudden loss of vehicle through no fault of the player, wheels hitching on flat terrain for no reason, vehicle falling through terrain, improper physics behaviour, save file size explosions etc. Accuracy - Is the game simulation accurate enough with respect to the real world? This includes things like the game's part-based physics system using spring joints (wobbly rockets), part impact resistance, heating, aerodynamics model, wheel function, trajectories and terrain. The current trajectory bug that makes interplanetary transfers difficult is a great example of a lack of accuracy, as well as the orbital decay bug. Accuracy is where we see the effects of the game's foundation most of all. And like you said, I hoped that the foundations underlying accuracy would have been the ones improved in a new game built from the ground up. The most notable improvement here is the ability to use engines under timewarp, but other foundations were not significantly improved on compared to KSP1 such as spring-based joints and drag cubes. For example, the part-based physics system is the foundation of KSP's vehicle behaviour, and is primarily responsible for performance quickly getting worse when building vehicles with higher part count and many flight bugs as well as phantom forces (aka, the kraken) also originate here. There have been calls on the forum to get rid of the wobbliness or at least rein it in, as well as enabling scaling to high part count vehicles. Both of these come down to this foundational system.

I do not agree with this framing, it doesn't make sense to say that clipped parts are penalized by drag cubes. Under drag cubes, clipped parts are not linked to drag because the one has no influence on the other. Rather, it's the whole-vessel approach that you propose that rewards clipped parts, because now part clipping affects drag. And it rewards unduly in the extreme case of clipping fuel tanks and engines, unless another system is created to prevent or discourage this. This will drastically affect the types of builds that players will be encouraged to use in atmosphere, encouraging spam of smaller clipped fuel tanks and engines to get unrealistic drag characteristics while inflating part count to boot. To avoid partclipped ascent vehicles becoming the norm, this means that next to implementing an entirely new whole-vessel (probably voxelization) approach to drag, you must also implement an anti-partclipping system. Even if this combination can be made performant and free of undesired artifacts, which I wouldn't consider a given, the cost of implementing it bug-free is going to be high and impact other engineering work on the game. I do want the advantages that come naturally from such an approach, but it doesn't seem realistic to me given how much more there is to work on.

I'm not happy about the decision to take away what little information we had to aid us in testing and improving our craft for drag and lift without offering something else (ideally, better) in its stead. My reply to Nertea about this very topic: Full text also below: While I agree with this, given all the other things the team has on their plate, it doesn't look like an improved UI for presenting more aerodynamics information in either the VAB or flight is forthcoming any time soon. Players currently have insufficient information about how much drag and lift their planes are creating, and this was made worse by the removal of the F12 Aero gui window in the most recent patch. More than just aiding advanced players, restoring the Aero GUI shortcut and a debug option to show some aerodynamic debug information in the part manager would also enable players to help zero in on aerodynamics issues caused by specific parts, combinations of parts, fairings and cargo bays as well as any overall aerodynamics bugs remaining after the issue you highlighted in your dev diary is fixed.

Like @herbal space program I do also worry that with this sale they're expending the "attention potential" the game has left (being an early access title) too early. A signifnicant portion of new customers this sale brings in will find out soon there's not much to do yet in the game once the novelty of experimenting with sandbox is over and the game's shortcomings and bugs start to outweigh the fun still to be had. The ones that don't refund will put the game down, but only some will return when the game improves later, leaving fewer potential newcomers to spread positive word of mouth when that time finally comes.

I had a mission come back from an interplanetary trajectory from Eve. Before hitting the atmosphere, I ditched the rest of the spacecraft and piloted only a Mk1 "Tin Can" + Mk16 parachute into the atmosphere at a periapsis of 17 km and entering the atmosphere at 3589 m/s. I also experienced an implausibly low amount of drag, meaning I would have flown through the atmosphere at 17km periapsis and still exited above Kerbin escape velocity. It is possible to steer by keeping the pod at an angle to retrograde, but when I try to deflect the trajectory downward I soon lose control and hit the ocean still going over 2300 m/s. The steering results in the trajectory being deflected far more than should be possible.

While I agree with this, given all the other things the team has on their plate, it doesn't look like an improved UI for presenting more aerodynamics information in either the VAB or flight is forthcoming any time soon. Players currently have insufficient information about how much drag and lift their planes are creating, and this was made worse by the removal of the F12 Aero gui window in the most recent patch. More than just aiding advanced players, restoring the Aero GUI shortcut and a debug option to show some aerodynamic debug information in the part manager would also enable players to help zero in on aerodynamics issues caused by specific parts, combinations of parts, fairings and cargo bays as well as any overall aerodynamics bugs remaining after the issue you highlighted in your dev diary is fixed.

I've played a little with FAR in KSP1 and it's quite the interesting rabbit hole to learning more about aerodynamics with it! There are a lot of things simulated by it, like area ruling, that can wildly affect the stability of your plane in ways that are not easy to foresee. In order to make a good plane that flies well, I had to lean heavily on older real world plane designs that were made to be naturally stable without the fly-by-wire assistance that modern planes have now (SAS can only do so much). Or else, I'd be spending hours with the area ruling simulator and drag number tables to try and tweak out strange instability issues for a design that's a little more unconventional. I think that at least these above two traits played into the decision not to go for a FAR-like model: Much harder to understand what adding and changing parts on a plane does to its stability and having to spend hours tweaking a plane to get the drag number tables and the curves in the simulator graphs to a good state. This information would have to be represented in a much better way to make a FAR-like system feasible in core KSP, and tutorials made that can somehow make these concepts accessible to new players. In both KSP1 and KSP2, we have offset and rotation tools that make it trivially easy to clip parts into each other. The "build-a-whole-craft-mesh" approach of FAR means that it is trivially easy to cheat on drag by clipping fuel tanks and other parts into each other, with FAR treating it as an impossibly dense aerodynamic hull. And there would be major incentive to do so, because you could make planes that have very little forward drag for their mass. With drag cubes, there is no advantage to clipping parts into each other and so plane designs don't have much reason to use part clipping other than for aesthetics purposes. (1) Footnote:

Clipping a part does not affect drag. The drag cube system uses only node attachments and the part orientations to decide whether and how much a part occludes another.

Thank you for the update, I look forward to seeing more issues fixed in the coming update and to seeing what you've come up with for Science! Also appreciate seeing the team's view on a successful implementation of part connection physics. I agree with these views, in particular with keeping autostrut out of KSP2. Most of my KSP1 experience was from before the days of autostrut, and even after it was added I didn't particularly like messing with this somewhat hidden setting to magically make connections between parts (root part, or heaviest part in particular) that felt a bit like cheating. I would prefer that stability results from simply using structurally sound parts for the task. However, there is one area I want to touch on and it has to do with the branching, tree-like nature of KSP vessels. It's not possible to truly connect two parts on the end of different branches in a rigid stack-attached way, because loops are not allowed. For example, when attempting to make rings, or rectangles out of fuel tanks or truss sections there will always be a point where the branches of the tree meet, but won't actually connect up properly. You could say, well just strut them together, but struts only really handle forces well in one direction. And as these two parts are physically next to each other, it should be possible to tell the game to connect them together with a proper stack-like connection. Another example is with docking ports, when merging two very large and massive vessels together consisting of multiple rocket stacks and habitation modules. No matter how rigid docking ports are made, it would be silly to expect a single docking port in the central axis to be able to resist the immense bending forces that could be caused by either vessel. The most natural way to deal with these immense forces would be to connect 3 or more docking ports between the two vessels spaced out widely around the central axis to increase the lever arm. But that's not possible, as KSP2 would only truly connect one of the docking ports. Allowing multi-docking port connections between vessels, and to connect together parts on different branches of the vessel tree with proper stack-like connections, will give players important tools to create the stability they need for more ambitious projects without diminishing the challenge and still allowing for some measure of wobble for designs that are not particularly well made. Edit: One more huge benefit to allowing multi-docking port connections is that it allows players to guarantee the angle of the connection and ensure the two vessels line up perfectly for whatever they have in mind next!

I've ran across this issue countless times and always wondered if there was something on the terrain mesh that the wheels got hung up on. I never realized it was every 1000m, and that quicksave/quickload and physics warp resets the distance. From this, I get the distinct impression they're moving the origin of the physics simulation every 1000m and there is a bug in the transformation that causes a rotational impulse on the rover, either directly or through an erroneous collision with the terrain. It brings me back to driving my rover at high speed on Ike's rough terrain, where I spent about as much time flying as driving and didn't see the glitch as often as on Duna, where I spent all my time on the ground. The glitch never happens while the rover is in the air, which suggests it affects wheel parts when in contact with the terrain.

It used to be F12 up until this patch 0.1.2.0 when they seem to have removed the keybind. But I too have been seeing some screenshots recently where people have the Aero gui open and would like to know how. I'm not at my game PC right now so I can't test it; I wonder if it's still F12, but only if the keystroke isn't intercepted by Steam? If so, changing your screenshot keybind in Steam might do the trick.

The gravity displayed for all the bodies is actually shown in units of g (standard gravity), it's just the unit label "m/s" that's wrong.

Fuel tanks could bend and crumple like a crushed soda can... Non-explosive contents (methane in non-oxygen atmospheres counts for this!) could leak or spray out!

Blue is the current conics patch's orbit colour, the next one is an ochre yellow, in both KSP1 and 2. KSP1 goes on to have other colours like red, cyan, etc. I'd like something similar for future patches in KSP2, as well as a dot marker when you hover over a trajectory. The dot marker should match the colour and location of the trajectory that will be affected when you click. This is quite important when you're trying to add a maneuver when two or more conics patches are almost exactly on top of each other. I can't remember now if KSP2 has this or not but I do remember having trouble getting a maneuver node on the right conics patch when two of them overlapped, and being unsure which one I was actually clicking.

Elevators could be useful in colonies to get onto a raised platform or the roof of a building where you have a vehicle parked, either just for kerbals or service vehicles that could do some refueling. Although I expect we will also get the ability to recover a craft and all its components/resources into colony storage and re-deploy it fully fueled (storage capacity and reserves permitting) on a launch platform.

You're right that categories 2 and 3 aren't cleanly separated, I read up on the terms on the Project Rho website to use them as illustration when I hastily wrote that post during a break at work. Indeed, while reading there I got some increasing doubts whether antimatter could ever work out as a fuel for the fabled antimatter engines... To accurately portray interstellar colonization with technologies currently or nearly available to us, KSP2 would have to support ark-sized ships kilometers in size, that can support an entire biosphere slow-boating it to another star over centuries or even millennia.

Appreciate the new update format, keep it up! Glad to hear progress on some bugs is being made, I hope to see more in the future. The blueprint style graphics for the engines are nice, they could go right onto a wiki! The engine stats as shown are on the low-thrust, high-efficiency end of the methalox engine spectrum. It does leave me to wonder if the engines are capable of firing with their nozzles retracted and what the stats are in "short nozzle" mode. Not that there's anything wrong if they can't because there's no worthwhile tradeoff to be made firing them in that mode.

I do think it's important to make distinctions between different technologies that are shown in science fiction stories. Technologies that we could build a physical example of and are possible with currently available materials. They might not have been used (extensively) in the real world because of scale, resources and the will to solve the engineering problems involved. Unobtainium: Technologies we can't build an example of but that the laws of physics say would behave a certain way, if only we had a material with properties that we can't obtain. (yet) There are different kinds, from more grounded in science such as helium-3, metastable metallic hydrogen, antimatter and room-temperature superconductors to completely made-up materials that could, for example, have enough tensile strength to build a ringworld with. Handwavium: Technologies that flat out violate the laws of physics. FTL, Time Travel and reactionless drives would fall under this. So far, I haven't seen anything in KSP2's roadmap that falls into category 3. And of the things teased that would fall in category 2, they're materials on the science grounded side that enable more efficient engines. Unobtainium technologies like antimatter will definitely make Interstellar travel faster, but they're not required to get to another star system, it will just take more time and a larger ship. It's true that colonization and interstellar travel are quite the unsolved problem in the real world and that the challenges of life support, crew comfort for long interstellar journeys and how to bootstrap a colony on a distant world will be glossed over a bit. But I wouldn't put interstellar travel or colonies themselves in category 2 or 3 just because we haven't solved the engineering and societal issues.

If I understand this correctly, the OP has lost/deleted all workspaces for a vessel they were working on. But the vessel still exists in an active flight in their savegame. The question is: How to import an active vessel back into a workspace?

I think fuel scarcity will still make a difference because even if you're determined to use exotic fuel to trivialize travel in the Kerbol system, it will require large scale infrastructure (a colony) to get it conveniently accessible in huge quantities. You will initially need to set up harvesting of exotic fuel and supply routes to bring it to an orbital shipyard in small amounts. Those supply ships will be using your plentiful fuel. As you scale up your resource harvesting, you can start thinking about using exotic fuel for more common applications in the Kerbin system, like replacing your supply ships with larger ones running the exotic fuel themselves. Now you're reliant on the exotic fuel just to keep your supply lines going, which means you need to harvest even more of it. The key point is that it takes time and effort in the form of infrastructure building to get to this point of plentiful exotic fuel, not something you will have available in the early and mid game. The scarcity is the knob you can tweak to tune how early it will be feasible. Similarly, size and materials cost of the engines may not prevent the player from using exotic fuel for trivial applications in the endgame, but if tuned properly it will make more sense to use engines running common fuels for smaller vehicles like launchers and landers. Some possible constraints of exotic fuel engines: Low performance in atmosphere Low thrust to weight ratio So large and massive that it doesn't make sense to build a launcher or lander with them Constructing them on a surface base is not possible due to VAB size limits There's one exotic fuel I remember that might slip through all of these constraints which is metallic hydrogen. I expect this fuel will have a range of engine sizes similar to Methalox engines, but the ISP is going to be close to the SWERV, so their niche isn't actually interstellar but more potent interplanetary vehicles.