dvrabel

That's fair. Apologies for the accusatory tone. I've edited my post to better reflect the point I was trying to make (i.e., don't exprapolate your personal viewpoints to everyone, even if you see that viewpoint expressed by others -- its still not the whole comminity.).

Please don't misrepresent your viewpoint as representative of the whole community. I liked hearing about the positive morale in the dev team because a) the devs are people and people should be happy; and b) positive morale means better productivity, better decision making, and ultimately a better game at the end of it.

What plan is in place to accomodate players who want to build rockets without stuctural engineering constraints (all the "no wobbly rockets" requests), and those players that enjoy the additional structural/mechanical engineering challenges?

The engineer's report includes the mass of the kerbal piloting the pod (100 kg), which accounts for the difference in wet mass. So the game is correct. The dry mass excludes the 500 kg of methalox in the fuel tank (as expected), but it also excludes the mass of the kerbal (100 kg), the monopropellant in the pod (40 kg), and the 200 kg of abaltor. So I think it's not calculating it in a useful way (kerbals might be useful but you can't use them as propellant!).

Bending stresses are proportional to the length / width ratio. In real life, long, thin rockets would need to be stiffer, and thus (much) heavier. Unity's physics engine, Bullet, and MuJoCo all seem to model rigid body physics in the same way, as far as I can tell from their documentation. Any difference will be related to how the joint constraints and other properties are configured.

I must admit that my structural engineering is seriously rusty (only studied some at university decades ago), but I'm struggling to think of a model for a fully rigid structure that would be computationally less expensive than the current model, yet still calculates stresses throughout the structure. The only technique that I can recall is somewhat similar to the existing model except instead of actual angular or linear displacements to determine forces (via a simple linear spring model) , it uses small/infintesimal displacements and would thus seem to have similar computational complexity. But as I said, I forgotten much of my structural engineering knowledge, so If someone is more knowledgable, some pointers to other models would be greatly appreciated.

I'm not sure the "real rockets don't X." argument really works in the context of KSP since considerable efforts goes into real rocket design to ensure they don't fail, whereas KSP allows you to cobble-together any old parts into something vaguely rocket-like. If you did this in real life, you would make any awful lot of explosions. Lots of KSP rocket designs should fail (this is a key gameplay loop), and thus KSP needs to provide useful, more intuitive feedback to the player about why their rocket failed.

Visibly flexing rockets gives a good visual indicator that the rocket is over-stressed and may be about to fail. Without some sort of indication like this, rockets that spontaneously break apart with no warning will be very frustrating , particularly for less experienced players. I think KSP2 should: 1. Provide a difficultly option for rigid nodes (alongside the existing option for unbreakable nodes, or combined together), for those that want this style of gameplay. 2. Improve the SAS controller in atmospheric flight (it is currently underdamped which makes it more likely to introduce oscillations). 3. Fix bugs where some parts are more flexible than others in the same size class (i.e., the upcoming engine plate fix). 4. Provide parts (e.g., the truss structures) that are stronger (less flexible) but have other trade-offs (such as worse drag or bad thermal performance). 5. Guide players to constructing large, complex craft in orbit (where rockets are not subject to aerodynamic forces). 6. Consider toning down the amount of flex to ease control issues while still providing a visual indication of high stress and impending failure.

Analytical solutions for coupled, multi-body systems do not exist, so it is impossible to "improve the formula's used for calculations and have time passed as a factor". Take a look at "double pendulums" for an illustrative example. The differential equations for such systems need to be solved using numerical methods and thus require small time deltas to get a sufficiently well-behaved approximation of reality.

The names are not obvious feminine or masculine but it does appear that 50% are men and 50% women. With a random selection of 10 kerbals I have 6 women: Gregtop Eleny Geofrie Valentina (naturally) Nedwin Wehrrod And 4 men: Newbus Geofwin Tedbrett Douki It is hard to tell the difference from the small portrait in the kerbal manager.

The move/rotate tool has the same options snap options as KSP1. When in snap mode, click the snap mode button again and you'll get a popp just above the button to switch between local and global snapping. As with KSP1, you can hold shift to snap with smaller increments and disable snap altogether (the magnet button).

Uncontrolled vessel (e.g., one with a command pod but no kerbal pilot) can enter an uncontrollable, continuously accelerating spin if an SAS mode is selected. Steps to reproduce: 1. Create a craft with a empty command pod and an undockable probe core. 2. Get the craft into stable orbit (the bug likely occurs in other situations but the effect is easier to see when in orbit). 3. Decouple the probe core, leaving the main vessel with no control. 4. Note that SAS appears to be enabled but cannot be disabled ("No Vessel Control"). 5. Set the SAS mode to prograde (or any other setting). 6. Observe how the vessel starts to spin at an increasing rate without stopping. Setting another SAS mode (prograde/retrograde/lock) seems to do nothing, and SAS itself cannot recover. Probably unhelpful speculation: I would suspect that setting an SAS mode causes the SAS module to be incorrectly enabled for a single simulation tick and the SAS module starts the reaction wheel to correct the vessel heading. On subsequent ticks the SAS module sees that it should be disabled (no control) and thus never turns off the reaction wheel, leaving the reaction wheel to spin the vessel faster and faster.

The orbit lines look gorgeous. The Stayputnik now has a (weak, hold only) reaction wheel and SAS and so will actually "stay put", making it now a useful part or early comms satellites or similar. It seems you can revert to launch or VAB even if you loaded a save. (Not sure yet which launch it reverts to, whether its related to the most recenlty loaded save or the most recent launch).

You will recall that the joint strength currently scales with part diameter. Joints are modelled as damped springs and thus can be configured to be weak or strong as the game designer likes. Note also that the mass of the connected parts does not affect their strength (but mass would affect the natural frequency of any resulting oscillation). I can see an argument for increasing the strength (or damping, or both) of the current joints, but I would not like to see them be trivially be made fully rigid as I find dealing with the wobble an interesting aspect of the game play. If you're not interested in this aspect, then sure go ahead and turn on that rigid joint difficultly option I proposed.

... and it's not autostrut, nor is it fixing some physics "bug". Wobbly rockets are a deliberate game design decision that higlights a real engineering problem that real rocket engineers have to design for. Nothing in real life is perfectly rigid and engineers need to design rockets to handle flexing and bending during flight. KSP exaggerated the bending to make it an obvious problem to the player -- a wobbly rocket is much more obvious than an seemingly rigid rocket suddenly and unexpectedly cracking in half as internal stresses from bending moments become too great. So, wobbly rockets need in-game, real world solutions. and not a magic autostruct button, so what are they? 1) Struts - Additional cross bracing to stiffen a structure as a real world solution to excessive flex. 2) Truss structures - You will have seen in the parts list a good number of new truss structures. Trusses are lighter and more rigid than tubes (fuel tanks) and should make excellent central "spines" for larger craft. However, trusses are terrible aerodynamically so we've swapped one engineering problem for a different one. How do we solve this one? 3) In orbit construction - Avoid the atmospheric induced forces and drag entirely! This is in the road map for interstellar craft but I think this would work equally well for large intra-kerbol craft. Having said all that, I would also be in favour of a difficulty option that would make all joints perfectly rigid to support the play of those who don't want to tackle this particular problem.