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.

I agree with some but disagree on others. I don't know what your acronym TOOBs stands for. Agree: Wings and stabilizers. Maneuver nodes. Disagree: Move/rotate - KSP would lose some of the charm to reduce the current qualitative VAB design to quantitative number-based design. Neutral: Fairings - doesn't seem necessary and the visual clutter may not be worth the benefit. Maybe if the interface could borrow the same space as the wing/stabilizer and therefore not cause any additional interface clutter.

Made one attempt with this attempted light-weight design. I made use of a "grumble" seat inside a cargo bay. That is Jeb's helmet clipping through the top there: https://steamcommunity.com/profiles/76561198028655071/screenshot/2090288967803297068/ Lessons learned from this failure: (1) Don't forget to balance the center-of-mass and aerodynamics for when fuel tanks are empty...; (2) Green colored things blend into Kerbin terrain coloring. I made it 75% of the way around, through two sunsets and one sunrise, before the unstable weight balanced caused it to spin out of control. On the way it starts off cruising around 4km altitude and 240m/s; but towards the end was cruising at 12km up and 440m/s. Stupidly fuel efficient at the higher altitudes. Its a shame the only way to balance the weight of the engine at the back is probably to add weight at the front. Probably use a real cockpit at the front to match the dry-mass of the wheesey engine at the back. Some shots of Kerbin along the way: https://steamcommunity.com/profiles/76561198028655071/screenshots/

This is the perfect thing for a mod to provide. Why not stock? Because there is a huge benefit for new players to all start from the same place: (1) all guides, tutorials, and let's plays are relevant and relatable for new players starting the game; (2) Developers don't have to re-tune the starting experience for every combination of available start location. I.e. every 'option' added to the game requires QA testing of both with, and without, the option enabled. The developers have better things to do with their time at the moment. After KSP2 is completed, and a full 1.1 release is out. Then developers might want to re-look at things like this and effectively incorporate the most popular mods into the base-game. Similar to how KSP1 added a lot of quality-of-life features into the base game from mods later on in its development.

I agree with most of your analysis with one important addendum about life support in KSP1 and disclaimer about KSP2. For KSP2 we're going to have colonies and the ability to launch vessels from those colonies and orbital construction as a core mechanic of the base game. This is going to fundamentally change the game and, in-my-opinion, define what KSP2 is as a game. I think it is too soon to say how LS can be incorporated until we know more about what colonies will be as a core feature. It may make more sense to have LS buildings as a structured part of the colony buildings and not as parts of any vehicles. Developers mentioned colonies would be constructed in an interaction which somewhat resembles VAB construction - except it is outside and you are placing buildings instead of parts. For KSP1 there was also a fundamental problem with ISRU (and therefore also LS) which mods couldn't solve. This dealt with the way resources were simulated in KSP1. Notably, no resources were gained or lost unless you were flying or within 2.3km or the vehicle. Whenever you switched back to a colony or ship it would attempt to approximate what happened over the interim based off the current rates. However, this causes two related problems: (1) if anything happens very slowly or in very small quantities rounding errors can often result in zero production of the corresponding resource. (2) When loading a vehicle it will attempt to use massive quantities of electricity based on instant generating potential. Accordingly, if your solar panels aren't correctly oriented you may find your entire batteries drained (or occasionally find other resources entirely drained). This is a problem which couldn't be solved in mods because the simulation loop didn't evaluate this. A core re-design in KSP2 was in re-doing how resources are handled to accommodate certain features which are all based off of fixing this fundamental mechanic. Very cool concept art and I concur with your well thought out points above. Just adding my own two cents in addition.

Designed a simple plane and launched it from Kerbin to Laythe. In the latest version 1.4 of KSP2 I didn't encounter any bugs or performance issues. Orbital prediction lines were more accurate than in KSP1. The initial launch to low orbit was a little wobbly right around the decoupler, but turning off SAS it was flyable. When I arrived at Laythe:

Weighing in on the OP with a few considerations: * A huge number of KSP1 mods add resources of various types. Clearly there is a lot of interest to have some aspect of resources in KSP2. * There are more ways to have resources be limiting than just adding a cost to parts, even if you assume infinite resources on Kerbin. For example: (a) Colonies consume resources rather than any individual rocket/vehicle; (b) colonies could have levels of development/size where larger colonies support larger VAB construction. Increasing the size of a colony may require supplying certain quantities or rates of resources. This kind of limitation would correspond to upgrades of the launchpad/VAB/SPH/mission control/tracking station/etc. in KSP1 which imposed weight and part count limits. Devs have mentioned size limits - which might mean the limits they are considering might fall more along the lines of resources limiting a size/part count/weight of vehicles rather than direct costs. * Even with infinite resources, starting from the ground on Kerbin may be more difficult than ISRU from somewhere closer. Both are viable play-styles. Some players may prefer to design enormous rockets from Kerbin while other players may choose to incorporate more ISRU. The ultimate resource for a game is the player's time. For delivery to low-Kerbin orbit it is easiest to just design a rocket, but for anywhere in Jool it may take less time to design smaller vehicles from a Colony than it is to take the time to design something so massive as would be required to start from Kerbin. Some parts might alone might just be too massive to reasonably launch from Kerbin - certain interstellar engines, for example.

I don't know if KSP2 does this, but in KSP1 each part had a vehicle identifier associated with it. It would be nice if by default you could group/filter according to vehicle identifier. This wouldn't allow you to distinguish between "reserve" fuel tanks but either creating manual groupings or just having fewer tanks which have to be individually selected would be useful quality of life improvement. If not in the base game this might be good for a mod to add this some time later.

I agree. Being able to mark an orbit or landing place on the map so other players can see it would be very useful for multiplayer.

The Devs spoke a little bit about this. From what I remember they said: (1) there is no money/funds, but there will be resources including rare resources that can only be found in unique locations. (2) There will be automatic routes where you fly the mission once collecting or delivering something and it repeats. I infer getting to late-game will involve exploring different places to gain access to all the resources and also optimizing designs for more efficient automatic routes. I see a lot of interesting design iteration possibilities with that and it will allow increased reasons to design rovers, boats, and planes for local exploration of a planet/moon. The Devs have said KSP2 will most resemble science-mode because funds will not exist.

I am not sure what you mean by listing these mods. For example, with listing "ISRU" there is some ISRU in the vanilla KSP1, and there are multiple different mods "ISRU Tweaks" and "Less Simple ISRU." I haven't tried either of those mods but I assume they are very different from each other. You need to clarify which gameplay concepts you mean because it isn't clear just by a partial listing of mods. For the general idea that mods - and their respective popularity - are an indicator of gameplay aspects to add to KSP2 eventually, I agree. However, the idea any KSP1 mod could be "copied" and still work in KSP2 simply isn't how programming works. Basic mechanics working in the background are fundamentally different even if they result in similar on-screen elements. Also, usually my experience with KSP1 mods is they are often in need of optimization and generally computationally taxing. This is alright for a mod where a person can choose to not use the mod but the base-game needs a higher level of optimization than found in most mods.