Lyneira

A crossfade, if technically feasible, would do a lot to soften the sudden movement. In addition, I would suggest mapping the SAS settings upon switch as follows: In the event of switch from surface to orbit, map SAS settings as follows: Up/Down -> hold attitude In the event of switch from orbit to surface: Radial in/out -> hold attitude When flying aircraft in KSP2, I was initially trying to avoid using SAS and use trim only, because they could not be combined in KSP1. In KSP2 though, trim does combine better with SAS. I use it to add a pitch up trim so that SAS can hold the plane's attitude well and the nose doesn't drop down when giving, for example, roll inputs to make turns.

All wing types do generate lift when there is a non-zero angle of attack. The main wing parts with asymmetric airfoils should, in reality, generate lift even at an angle of attack of zero. From memory of my lift/drag tests in the past, I'm fairly certain that's not the case in KSP2. Shame we can no longer open the Aero GUI with F12 to verify.

Been struggling with the very same bugs on those wheels so much with my past rover mission to the other planets and I really hope they pick up on this one soon! Especially when driving on limited EC far from the sun, the constant "wheel sneezing" ends up sapping all your momentum. Also interferes with my plans to make a plane using (some) rover wheels...

I voted "Yes" because I agree the game doesn't need to tell us a flight is a failure. I would however like to keep the flight log information to help me figure out what part broke first. In particular, the flight log should also be accessible with some button before destruction of the last control point. And instead of popping up in front of the explosions on destruction of any part of the craft, perhaps a UI element should light up hinting that the flight log of the finished flight is available. Only when no control points remain. This could also be done when a craft is recovered.

You can't actually float anything with a normal blimp type balloon in a gas giant, because gas giants are pretty much entirely made up of hydrogen and helium, the lightest gases. The only things that could displace the hydrogen and gain static lift are a vacuum or a hot air balloon filled with the gas giant's own atmosphere. Both have problems: Vacuum: An envelope strong enough to resist the pressure and light enough to not undo any potential lift is to my knowledge not possible with any current technology. Hot air: You'll need to constantly use energy to keep the air in the balloon hotter than the air outside. One ideas I've seen for this is a balloon designed to absorb maximum sunlight from above during a gas giant's "day", and any reflected light from the atmosphere below. And of course the balloon has to keep as much of that heat in for as long as possible rather than lose it to the atmosphere. The balloon would rise during the day and sink during the night. Either way, because the air being displaced is mostly hydrogen which is the least dense gas, there is much less lift available per displaced volume than in a nitrogen/oxygen atmoshpere, so the balloon volumes would have to be gargantuan to lift anything substantial.

Efficiency of staging aside, it should be possible to just directly attach fuel tanks to the side of a main tank and have them work. In fact it should result in a more stable connection than using a decoupler in between. If this is not happening right now, it might be a problem with the tuning of the game's part connection physics at higher masses. I don't build big often, but I have noticed spontaneous disassembly like that with one craft where I needed a big launcher.

I would indeed not expect to see this in the first iteration of colonies. And I won't be disappointed if they never get around to it. However, Nate has said that the team wants each planet to bring a unique physics puzzle to solve to conquer it. A floating colony definitely qualifies for this. Consider also that Jool is not the only planet with a thick atmosphere (there's Eve as well) and we know there is at least one more gas giant (the one that the ice moon in the trailer orbits) planned to be added as part of the current roadmap. In general, I see enabling the creation of aerostats, whether normal or colony, as something that will add an entirely new dimension to the game. If the devs don't get around to it themselves, I look forward at least to mods adding it.

It could be a way of harvesting unique gases from a gas giant. Would certainly create challenges attempting to land kerbals and cargo ships on the limited space. As for implementing them: Colony parts are almost certainly going to be treated differently by the game's physics than normal vessels. I would expect them as static objects with no physics done between colony parts. When colonies get large and knowing how much the game already struggles with part counts, there's far too much performance gain here to not do this. Maybe catastrophic collisions would temporarily set them to be treated as dynamic with regular physics while things are falling apart, like we see in the trailer on the ice moon. Surface colonies in particular will remain stuck to the terrain and in one position relative to the planet. A floating colony can be the same, just without being attached to terrain. No rewriting of orbital mechanics needed. If catastrophic collisions happen and some parts of the colony become treated as dynamic: too bad, some parts of your colony will fall into the clouds, never to be seen again. If you break your balloons, your whole colony will fall.

I like the plot idea, but it means the endgame reward for all of your explorations, learning, science and decades or centuries of kerbal interstellar travel is... Somewhat similar analogues to solar system planets, the same planets we've already explored in KSP1. They won't have any new physics or exploration challenges to overcome, compared to what we would have gone through to reach them.

I expect at least a "weird bulbous thing that performs an experiment and I need to build a rocket around it!" And less thermometers we stick on command pods.

Less than a third the height of the real Mount Everest of 8848.86 m. Even the much more modest Alps have many peaks above 4000 m. Although what also plays a role here is the "roundedness" of the terrain that seems to be affecting current mountains. You can easily stand on a peak and barely be able to look out over nearby terrain below you because the peak is actually a giant, slightly rounded, plateau.

There's something to be said for charging full price to the early adopters, among which tend to be those who get the most value out of the game as a sequel to KSP1. It might also act as a deterrent for those who think to grab an EA game for cheap, only to be disappointed by the state at release and never look at the game again. Those who are deterred now might still consider getting the game when it makes headlines again, with hopefully more bugs sorted out and more features on the roadmap released. But this only makes sense if confidence is very high that the product as promised on the roadmap will actually be realized. As users, we have rather little to go on to evaluate this except a gut feeling based on the communications so far. For an early access game, the developer/publisher are required to answer a number of questions on the steam store page, one of which is: The answer is a list of features that the player can do. Notable omission being the game's stability at release (and still currently), something a prospective buyer certainly would have liked to know as it deeply affects all the above. (emphasis mine) As the store page states, feedback on the core fundamental experience is what they're looking for. With only the information above, a prospective buyer has no indication to expect severe performance and stability issues that will hinder them from properly exploring this core fundamental experience and giving feedback on the features mentioned in the previous quote above. Nor does it state anywhere that said performance and stability issues are actually what they need our feedback on to help them resolve. And this ties into the communication pattern that ObsidianAnt has taken issue with in his most recent KSP2 video. (too long; didn't watch): Vagueness and tiptoeing around the elephant in the room, when addressing the game's current issues. All in all, it's understandable to see why people who are critical of the game feel misled.

@AtomicTech The main point he makes in that video is that he takes issue with a pattern in official communications. A vagueness, tiptoeing around "the elephant in the room." That being the game's performance and stability issues at release and those persisting into the current patch. And in his words, he would prefer the "PR and marketspeak being dropped" when addressing them. He also adresses Private Division specifically, rather than just the development team, in his plea for clarity in communications about what's going on. Given how much the state of the game (especially in response to the content of development updates) has been argued about on the forums and on the Discord, some of that had to be prompted by this pattern. I'd prefer a bit more openness on this too.

Colonies are on the roadmap, which will include orbital colonies. We'll have to have some patience for now, but there will be no better place to build a huge interplanetary or interstellar ship than an orbital colony!

Definitely seems like that lately, especially in the threads that are essentially about the "state of the game." Hopefully we'll start seeing more threads about the content of the game rather than the state with the coming patches. For me, it's the same with playing the game. I've explored most of the part catalog, built some planes and rovers, sent a vehicle to most celestial bodies. I'll fire up KSP if I'm inspired with some new idea but otherwise, not much to do but wait for a patch to improve stability to enable longer term savegames, more complex missions and bring some new content to explore.

I've never thought about it like this when comparing KSP2's EA state to the state of other successful EA games that were more polished during their release. If that's accurate (the team has explicitly stated they are in this for the long haul, which is consistent) that's reassuring for the future of the game.

I like this suggestion for the ability to make a flight plan separately from a craft and get information on when launch and transfer windows are. Especially with the possibility of using gravity assists. For scheduled supply runs, it should be noted that KSP2 won't require the player to perform regularly scheduled supply runs, as there will be an automated delivery system you can use after you run it once.

I got inspired when reading about the Dawn Aurora Mk-II, a spaceplane under development by Dawn Aerospace. This rocket plane is designed to fly from a runway multiple times a day. So I made an upscaled recreation! My version takes off from a normal runway and launches into a steep sub-orbital trajectory just above the edge of space. The payload accelerates into orbit on its own while the plane glides back to the kerbal space center. All done in one session without resorting to saving and loading save states! Payload mass: 0.93 t Total mass: 6.02 t Both the ascent and return are easy to fly and don't take long at all. Because of the steep launch trajectory, the plane falls back into the atmosphere close to Kerbal Space Center, cutting down a lot on the length of the glide phase. The payload needed about 2000 dV to complete its orbital insertion, which is quite a lot but it doesn't need to worry about the atmosphere at all. So even if it isn't the most efficient, I quite like this launch profile.

Multiple wing shape segments in one wing part would be great. If that's not feasible, at least having the option to make wing parts snap and match their tip/root size to each other will help ease this a bit. Another suggestion for procwings: A way to resize the wing in 2 dimensions while keeping the same aspect ratio and shape. Right now, when you're happy with a wing shape but you realize that you need more (or less) wing area, you have to do the following steps: increase the wing span Increase root length increase tip length adjust wing angle to approximate what you had Reposition everything that was already attached to the wing It would make plane building so much smoother if this process could be condensed down to just a gizmo or slider to scale the wing. It doesn't need to scale it up in 3 dimensions, just dynamically calculate the existing wing parameters to maintain the same shape. If any one of them would exceed a limit for the wing part, don't let the wing scale up to that size.

Some good points made. I knew from KSP insiders event footage the game was in a very rough state. So yes, I bought it with the hope that the game would be more than it is now and that I wouldn't be comfortable with the money spent if this was all the game would ever be. But KSP is a one-of-a-kind game in the scopes it brings together. The development of a true sequel that does everything the original did and more, was something I didn't want to pass up. So I also bought it with the intent of supporting this one-of-a-kind game's development to help ensure the future of a fully realized KSP2 comes to pass. The only reason I took this approach was because of the special place KSP occupies for me. I would definitely be taking the more cautious approach of wait and see and evaluate its worth as-is with any other EA game. Some EA games have worked out great, but I've also been burned in the past (hello Star Citizen) with promises unrealized. In the end, the EA games that worked out great were the ones I was already happy to play as-is, rather than the ones that I was merely projecting my hopes on. I have gotten some enjoyment out of just designing little missions or recreations, the visuals and the sound design so far. I guess the jury is still out on whether this one will end up in the former or the latter category.

For aircraft fuselages especially, they could be reasonably expected to endure sideways stress on their nodes due to being supported in gravity by landing gear and wings. But even in the case of rocket fuel tanks, the tanks do need to be engineered to withstand all sorts of launch stresses and vibrations too, and plenty of Kerbal spaceplane designs do incorporate, by necessity or by choice, cylindrical tanks in them. So I'd rather not the game give too much special treatment to aircraft fuselage node strength.

I voted "I don't really care" for question 2 but I think the answers are flawed because my actual opinion is a strong "No" to reintroducing an explosion of wing parts. I'm with you on the issues you quoted, but I think these can be solved with UI/UX improvements to the existing procedural wing system. Wing connectors: Use a stabilizer configured to be rectangular, disable the control surface if you don't want one. Wing profile looking like low speed airfoil: For now you'll have to live with tuning the thickness, setting it to minimum will look decent enough for high speed planes and save you some mass. Longer term, extend procwings to allow choosing a few common foil shapes. Include a "cuboid" option for those cases where you just want a big flat panel, like the old Wing connectors. Easily accessible delta wings: Better UI to tune the wing parameters than sliders, allow configuring your favorite wing settings as presets that you can easily load up. Also benefits the Wing Connectors issue above. And a couple suggestions of my own for improvement of procwings: Wing root/tip snapping: When attaching a wing to another wing's wingtip, the child wing root should snap to the exact same location and size as the parent wingtip. Hold alt to disable snapping. Attached parts move with changing wing shape: When changing the shape of a main wing, attached parts and other wings (especially auto snapped wings as the previous suggestion) should move with the new wing shape so you don't end up with stuff attached in illogical places or worse, floating in mid-air.

This is connected to the fact that KSP2 is being engineered to be a multiplayer game, where pausing the game sim at your own convenience is usually impossible. As was pointed out, reducing timewarp with the [< ,] key until time is paused effectively does pause the game for you, but probably not the internal server and time potentially passing for other players in development builds. That said, it'd be good to have at least a configurable pause button that immediately sets your timewarp to paused mode.

I was thinking more of steeper geometry like this that we're currently lacking:

I don't think the volume calculation is very difficult for procedural tanks that are cylinders of the standard diameters, but where you can vary the length. It could be that the game's architecture doesn't currently support parts with dynamically calculated resource capacity. We have procedural wings that can be adjusted in thickness (which affects mass but not lift or drag), but they can't hold fuel, whereas KSP1 had some larger wings that could hold fuel, but KSP1 wings were not procedural. But I'm more inclined to think this is a deliberate choice to stick with predefined tanks and tank sizes that you click together like lego bricks. One perhaps underappreciated benefit for keeping them predefined sizes is that you can size them such that the wet mass comes out to a nice round number like 9 tons instead of 8.836 tons. Since fuel tanks tend to make up most of the weight of a launch vehicle, this makes it easier to do basic head-math (or actual math, if you use a calculator on your desk) and estimations for the amount of thrust you need, as you're building the craft.