Barrackar

It really depends what you mean by "colonies" content. For example, the automated resource routes would likely be available as soon as you unlock the most basic docking port. Drilling and ISRU resource gathering is probably later. Last, construction and VAB/orbital construction vehicle launch capability is probably last. Each category comes with different parts, requirements, and capabilities. Similarly, the "colonies" update part of the roadmap isn't going to be just one thing. Not long now until the December19th and we see a lot more information about everything else in the tech tree so far.

I like the idea. Certainly more user friendly in that it would be less likely to result in unplanned passengers or unplanned vacancies.

Maybe a small change to the interface where Kerbals who have been assigned to a command module remain in the list of unassigned kerbals - but are greyed out and moved to the bottom of the list. Then you could re-assign them to a different command module without having to find a command module they are currently in.

I don't see any of the supposed issues except the circle thing - because that is how you do circles with pixels. You cannot draw a circle on a screen without some parts of it being wider than other parts. If you remove the parts which you currently see as 2px (i.e. wider) than it will instead look like it has weird gaps at certain angles. The alignment of the icons seem aligned to me. The slanting of the solar panel icon may create an optical illusion, and similarly the circle OP drew on the APP bar may create an optical illusion. To me the icons are aligned and both P's look the same. Overall, I like the new UI as a default layout. It would be improved by allowing customized scaling of UI elements so each person can make some parts bigger/smaller as they see fit but as a default it gets most things right. I.e. the most important things are more prominent than the less important things.

Mods are optional. I am fairly certain many people will be making various flavors of life-support mods. Personally, I want to see how colonies are implemented before considering adding a life-support layer on top. Colonies are just going to effect too much to consider how something else would be added on top.

Silly cliche is false dichotomy. Switching over to watching a video on a different site is disruptive to flow. Why would I want to spend 20 seconds with tab management, loading, ads, etc.? If it isn't important enough for the OP to even put a simple caption/comment/synopsis for it then that often indicates how much thought they put into the idea itself. Instead I could read another two posts. Not everybody will see it that way, but if you want your comment to be read by a wide audience then it is best to present it in a format suitable for a wide audience with different reading/viewing styles.

I would say probably not a bug because I have completed all the tutorial missions. Can you post a screenshot so we have a better idea what is going on?

I think what will really 'save' KSP2 is: "this mode will allow for resource collection and utilization, as well as the establishment of automated resource delivery routes. We want you to be able to continue the campaigns you start in December through all future colony, interstellar, and resource-gathering updates." The entirely redone resource system will, I think, make or break KSP2. The update(s) that resource collection / colonies comes out will be massive. Because it is system rebuilt entirely on the backend there is guaranteed to be bugs - we'll see if the community is patient enough to let the devs fix the eventual bugs or if they flip-out instead. It is going to be tough to implement a resource system which works well with the new colony system, is favorable for the modding community. Excited to see the Science Sr. and everything else this update will bring. I'll need to recreate the mission in my thumbnail to update it to the gorgeous KSP2 heat-effects graphics.

Most situations where science is collected are stable, i.e. in orbit or landed. Forcing a time-warp in those situations doesn't make game-sense. The example you have of barely making it out of the atmosphere could be addressed by making sub-orbital trajectories a different circumstance for purposes of science collection - if you think that it is even an issue in the first place. In KSP1 you wouldn't get 100% of space low science when you just get out of the atmosphere because (1) some experiments don't yield 100% with one collection [goo, material science] and because you haven't unlocked all of the science parts by the time you first get out of the atmosphere. For KSP2 we don't know much about science mode yet because no part of it is out yet. I could see timed experiments having a place for some experiments, but not for other kinds of science experiments. An interesting idea but I think successful implementations of science collection can be done both with and without requiring time delay. For me, RP1 was always too buggy with too many mods combined to make a stable playing experience so I can't say whether I like that version better or not because I never really got to play it in a stable form.

I'm not sure this is true in this case. Sure raw 2D sprite require less than raw 3D mesh, but that isn't what we have. The terrain system in KSP isn't raw 3D mesh, it is the PQS system. I don't know the internal workings of that system so I would hesitate to say a 2D sprite system would necessarily entail fewer resources/performance after accounting for the calculations required to swap them in/out and adjust for things mentioned above like shadows, consistent placement, or other things required to make it look okay. Instead of implementing a new 2D system, why not tweak the view distance level of detail to obfuscate the load distance? Perhaps split assets into different distance load groups so some of them load at different distances so there is no sharp boundary.

"Wobbly rocket"poll results: In a poll recently conducted the vast majority of responses (80+%) said they wanted completely rigid vehicles, but also indicated it should break apart under strain/shear and break apart under aerodynamic pressure. However, the primary roll bending/wobbly of parts has in the game is to visually indicate stress/strain and other forces acting on the parts. If joint physics is entirely removed this would (a) be a major change from KSP1 which was successful and thus represents a major risk; (2) SOMETHING else needs to indicate stress/strain/shear and other forces which could result in the vehicle breaking apart. Missing thus far from the conversation are suggestions for: if not bending , how should forces be visually displayed? Some people including OP have suggested using auditory cues but I think this fails on several levels. (1) Auditory cues could potentially mess-up existing sound design of the game - which most agree the sound design is fantastic. Adding screeching noises or similar could be very annoying. (2) auditory cues alone are too subtle to indicate important information on critical failure modes. Because nobody has suggested any alternative visual indicators for stress/strain/shear/forces on parts, I continue to argue for mitigating the problems associated with "wobbly rockets" rather than going entirely rigid. Here, I suggest a fix for SAS-related "wobbly rockets." Joint Physics: I suggest existing implementation should mostly remain unchanged except tuning default values on certain parts. In particular, stiffness of stack decouplers (inline) should be increased a lot over v1.4 values. Similarly, docking port connections should be less wobbly. No other changes. SAS overcompensation/oscillation: A key source of wobble is oscillations cause by SAS both in KSP1 and KSP2. I propose that if SAS-overcompensation and SAS related oscillation is fixed then the majority of "wobbly rocket" problems go away. That is, with SAS-oscillation fixed then rockets that players agree should not wobble, won't - and those rockets that still wobble most people would agree the wobble is the result of a design flaw (rather than a game bug). SAS-oscillations are commonly the result of final stage command modules being tiny and at the very top while the bulk of the mass is the lower stages. Therefore, while the mass and aerodynamics may be oriented one direction, the command module can be tilted and give an incorrect orientation for rocket control. Any wobble which goes away when SAS is turned off is SAS-related. I suggest compensating the "control from here" part orientation with a mass-weighted average orientation of all parts connected by nodes inline along the control orientation. This excludes radial attachment of all forms. The vehicles overall orientation would be V = (mV +mV +...+mV)/{total mass} for those aligned parts, where V is the orientation vectors [subscripts omitted]. This calculation is only done from a single "control from here" part and should be a very fast calculation. The intended effect is for tilting oscillations to cancel out when averaged because the front of the vehicle is tilted one direction and the rear of the vehicle is tilted the opposite direction. The result is a more consistent vehicle orientation for both pilot and SAS control purposes. Note: To deal with symmetric parts attached "backwards" the orientation of all parts except the "control from here" part should be half-spheres. I.e. no negative z-values, and use reflection for any orientation vector which is in the wrong half-sphere. Pros: Aerodynamically stable rockets will have stable vehicle control while still being responsive to overall vehicle dynamics. SAS would be more reliable. Prevent feedback loops from amplifying into SAS-related "wobbly rockets." Cons: (a) Some additional calculation needed, including a part-tree traversal from the "control from here" part to determine which parts to include in the calculation. (b) some types of SAS over-correction are still possible.

In KSP1 I change the default keyboard controls to remove the secondary SAS buttons {JKLI} and I think {HN}. Thus, I can use the default WASD if I want SAS, and I can use IJKL if I only want to control wheels. I think KSP2 has the same control interface but I would have to load up the game to double check. See discussion here for more information:

Concerns about burn-in on OLEDs is largely a non-issue unless you plan on leaving games running overnight, without turning off the monitor. See https://reviewed.usatoday.com/televisions/features/most-oleds-have-built-measures-prevent-burn That said, control over what monitor applications run on is always good. I'm not sure if this is an OS issue or a KSP issue. This sounds like something that may be difficult for developers to fix without more information about OS configuration/version. It may only affect a subset of OS configurations. OP and others experiencing this issue may want to include their operating system version information so if/when developers read this they can start determining which OS are experiencing this.

As I understand it, floating point rounding is part of the issue, but not the whole picture. So-called Kraken attacks where a craft vibrates and breaks apart has more than one cause. (1) Colliders are certainly involved when loading a vessel and it miscalculates collisions while landed or when adjacent an asteroid or other colidable object. This kind of kraken attack is characterized by occurring at physics loading in KSP1 and visually looks like some part spontaneously exploded. I don't know of any way to avoid these types of kraken attacks except reload a save and try again. (2) There is another kind of kraken attack associated with SAS oscillations. Most often affecting large stations with things docked to it. SAS oscillations occur because torque is applied to reaction wheel parts, but there is a lag time until the orientation of the "control from here" part's orientation is changed. When there is a joint between the "control from here" part and another large mass the inertia of the mass can overcorrect the SAS adjustment causing ever increasing wobbling until something breaks. These types of kraken attacks can be prevented by turning off SAS and using time-warp to freeze everything in place. Notably, these kinds of oscillations can occur without any floating point rounding effects - but a floating point rounding effect could be the tiny push which starts the first oscillation. (3) There are probably other causes of kraken attacks as well.

This is going to reveal how much of a major math nerd I am, but.... Balancing momentum is one of the techniques sometimes used when conducting numerical approximations in N-body simulations. For example, a variable time step is attempted and calculating the momentum of the system is then used as a sort-of checksum to determine whether a time-step of that size introduces significant errors or not. If there is a determined change in momentum for the simulated system above a threshold then the simulation tosses out the results and tries a time-step of half the size. Usually also done in combination with combining objects which are very close together into binary systems which would otherwise require very small time steps to simulate. On that note, N-body simulation and KSP have very different requirements. KSP physics simulation must be guaranteed to be completed within very small periods of time. It cannot at any point pause while the calculations catch-up. N-body simulation is almost the opposite where it is most important to make sure the simulation is accurate within some threshold level of accuracy. Many of the physics calculations done for N-body numerical simulation cannot be used in KSP. So what does all this mean for your suggestion? First, momentum calculations are plausible, but it is never as simple as just saying momentum should be calculated. Second, I'm not sure KSP doesn't already do momentum calculations at some level of approximation. I don't often encounter situations which defy the laws of physics in KSP unless somebody has intentionally set out to break them. Is there some situation you have seen which would behave differently if conservation of momentum were more explicitly enforced? Third, vehicles are not single rigid objects but composed of dozens of parts. Accordingly, calculating momentum is not a single variable but composed of 6 degrees of freedom for every part (and additional calculations for reaction engines). Even if you determine the total momentum is off, figuring out which part is to blame for the error and would need to be dampened would not be easy. Incorrect dampening may itself create abnormal momentum or oscillations.