Lyneira

You can make things more interesting for yourself now by exploring the limits of what you can build when trying to stay low-tech and low-mass. Both of these constraints, applied to a degree that suits your tastes, will challenge your skill at craft building and translate over well whenever the future resource system adds actual constraints. You also have KSP1 to give yourself some context for what parts are generally cheaper and lower tech, for example solid rocket boosters stand out as a pretty cheap way to add some extra power and delta-v to your launch stages.

I agree with that actually, to me it looks a bit like a question trying to bait some kind of admission.

The surface gravity of Kerbin is the same as Earth's, so it seems to me like geological processes would be capable of forming mountains just as tall in absolute height. Maybe someone who knows a bit more about (exo)geology could chip in with some examples? Approaching it from another angle: Kerbin's atmosphere height, being as tall as it is, is clearly aimed at being analogous to earth's atmosphere height. The KSC buildings are also similarly large in scale. From this I gather that the terrain and atmosphere are intended to be similar to Earth's in scale from a ground point of view. Which would suggest mountains with a similar height range.

Did a quick flight to the north pole and while I found huge swathes of mountains, a few with snowy peaks, I was comfortably flying above them at around 1800 m altitude. The cloud layer seems to start at around this height too.

Mountain ridges look great from high altitude and space, but I missed seeing some tall peaks and cliffs and valleys to fly through when I was just flying a plane near some mountains. I hope they'll get raised up again. And add some snow-topped peaks to them where appropriate, pretty please?

Hello Games during its radio silence were busy collecting all of the issues and expectations people had, and worked in silence until their first patches started rolling out and slowly, bit by bit, improved stability and delivered on the missing features. Opinions eventually turned around on the game, based entirely on delivering results. My impression is that KSP2 has a different kind of fanbase, with a larger fraction of people who are familiar with game design and development that can share useful insights. That would be a missed opportunity if they went radio silent.

To give additional context, the question and the (transcribed) answer: Is the team at IG/PD happy with the current state of the game? (Sunny54Games, Discord I was only digging for the question initially to answer Aziz but now that I read the transcribed answer back it does read as a thought spared for the road still to go, regarding features and performance/stability. So I'm happy with that.

I think it's fair to spare a thought for it when the question being answered is: Is the team at IG/PD happy with the current state of the game? (Sunny54Games, Discord) Edit: As I later found out re-reading the answer, she did spare a thought, so I'm happy with that.

Those patch notes, while the fixes were much appreciated, were not part of the AMA session, and do not change the fact there are many bugs remaining. To emphasize, I said "What would have helped with that perception [...] remind people in the same answer." That defuses what could seem like cognitive dissonance on the team's part for a player who's preoccupied with being unable do the things they want in the game because of the bugs that are still there.

I was listening in to the AMA when that particular mention of being proud was made. And I can't deny I had similar thoughts to @Scarecrow71 at that moment, where it seemed as if the game didn't still have its multitude of outstanding issues. It's very understandable to have thoughts like that when as a player, your reality of the game right now is far from what's needed to fully enjoy it as the game we hope it will be at the end of the roadmap. Feature wise, we don't have the same context of what's to come that the team is working in. Add on top of that fears in some of the community that the publisher might pull the plug on the game. However, like @The Aziz says, it's important for team morale and motivation to celebrate successes, even small ones. They've come far to create KSP2 as it is, and laid groundwork for what it will be. And I can agree that's something to be proud of. What would have helped with that perception in the first paragraph is to remind people in the same answer that they're committed to continuing to improve on stability and performance.

It might be caused by this bug?

I guess that goes to show how little I've played KSP1 in its later years! I don't recall this functionality existing from the times I played. You just had to divide the burn time by 2 and start when "Node in ..." got to that number...

My initial explanation was a bit poor and I've tried to edit it to make it a little clearer that I don't mean a return to "instant impulse" maneuver planning. Instead, the suggestion is for the game to base the maneuver direction on where you placed the maneuver on the orbit and, if desired, set the start point at half the burn time (or whatever time you want, really) before the maneuver's location. Then simulate the trajectory the same way it currently does. Effectively a convenience tool to make it easier to plan the most efficient burn possible.

I've encountered situations like that myself where the burn was just a bit long relative to the orbital period. I think this can still work fine with non-instantaneous maneuver plans we have now, it just needs way to set the maneuver marker to be the burn's halfway point. But the red trajectory and the burn start time dynamically extend a little before the node as you increase the maneuver. This way you can avoid burning radial quite so much and wasting Oberth effect. When doing an ejection or Hohmann transfer to/from circular orbit, you can manually do it now by moving the maneuver backwards a bit and adding a bit of radial component to adjust the Pe to where you want the middle of the maneuver to be. It's quite a bit of move, adjust maneuver and repeat though.

Since Patch 2, I've been working on an interplanetary rover mission to see how well I could deliver a rover to other planets and drive around on them. Ran into many bugs over the course of it, so to deal with that I've had to make many saves. I put it away for a while, but today I figured that with so many bugs encountered, these saves might be a goldmine for bug reports that are hard to get to with 100% reproducability in situations that the team might not see often. 4 different bugs reported! Bonus pics: Anomaly at the south pole of Dres. Drive in at your own risk...

At the Dres south pole anomaly, when exiting the rover seat in the picture below, the kerbal is put 11 km away from the rover, underground. To replicate: Download this save file bundle, unpack in your save directory and load it in KSP2. Have Jeb go on EVA. Note that Jeb appears underground, 11 km away from the rover. Bonus: Reload and drive the rover into the anomaly and try to get to the center. Use the reaction wheel to roll the rover around over the terrain when getting stuck. During certain terrain collisions near the center's whacky terrain, the game will start hitching and freezing up. Press action group 1 to toggle the reaction wheel to assist with turning and maintaining control. Status is indicated by the green LED strip on the back. Accelerating is best done with the reaction wheel off. Workaround: Don't exit the rover seat. KSP Version: 0.1.2.0.22258 Operating System and version: Windows 10 CPU and GPU: Ryzen 7 3700X, GeForce RTX 2080 Super Mods: none.

When driving the rover in the below picture away from the lander, after reaching just over 2.5 km distance from the lander (sometimes closer), the lander is lost in one of two ways: The lander marker can be seen falling through the surface of the planet. Returning to the site of the lander shows that it really is gone. One time, this happened not immediately after exceeding 2.5 km but when returning to the lander within 1 km or so. The lander marker disappears completely. This happened 7/7 times that I tested it with the example save and the reproduction instructions. The problem is not unique to Dres, I've also experienced this on Ike and Vall. To replicate: Download this save file bundle, unpack in your save directory and load it in KSP2. Press B to unlock the parking brakes Drive away from the lander heading roughly 270. Press action group 1 to toggle the reaction wheel to assist with turning and maintaining control. Status is indicated by the green LED strip on the back. Accelerating is best done with the reaction wheel off. The lander marker should disappear or start falling through the surface when reaching around 2.6 km. Workaround: Stay within 2 km of the lander. KSP Version: 0.1.2.0.22258 Operating System and version: Windows 10 CPU and GPU: Ryzen 7 3700X, GeForce RTX 2080 Super Mods: none.

When attempting to descend the Lander + Rover in this picture to Dres, the craft experiences violent forces when coming out of timewarp below a certain altitude. Often this will rip the craft apart or at higher altitudes, destroy a few parts on the rover, or give the lander a huge kick, messing up its trajectory. The example save file is for Dres, but this problem is by no means limited to Dres. I've experienced it on Ike and Vall as well. Before and after: To replicate: Download this save file bundle, unpack in your save directory and load it in KSP2. Timewarp to the maneuver plan and execute it to set the lander on a suborbital trajectory. (Due to the large normal component in the maneuver, SAS must remain in "hold attitude" mode and not "maneuver" mode, otherwise the maneuver will be way off. Final impact location doesn't really matter, as long as it's suborbital.) Timewarp at maximum allowed speed until sea level altitude is below 10 000 m. Return to 1x speed. The lander's engine pods are ripped off. Workaround: Guess what altitude is still safe to come out of timewarp, then wait out the descent without timewarping. KSP Version: 0.1.2.0.22258 Operating System and version: Windows 10 CPU and GPU: Ryzen 7 3700X, GeForce RTX 2080 Super Mods: none.

When attempting to merge a rover with a lander in the VAB and hovering the rover near the lander's docking port, the rover flicks rapidly between different possible attachment options. It is then very likely for the part orientations on the rover to get jumbled up like this: To replicate: Download this craft file bundle and unpack in your save's Workspaces directory. Load workspace "Rover Lander" Merge "Mini Rover 0.1" with the Rover Lander, review the shape. Note that the rover is now the main assembly and the workspace title "Rover Lander" has been overwritten with the merged workspace's title. (shouldn't the lander remain the main vessel when merging? And keep its original workspace name?) Make the lander the main vessel again. Grab the rover by the central battery and move it around the bottom of the lander a bit. Note how the rover flicks rapidly between different possible attachment options, which would make it difficult to attach the two docking ports together. Rover parts should become noticably jumbled as in above screenshot very quickly. Workaround: Cover every undesired attachment node with a nosecone. This might be a tad impractical. KSP Version: 0.1.2.0.22258 Operating System and version (Windows 10, Windows 11): Windows 10 CPU and GPU: Ryzen 7 3700X, GeForce RTX 2080 Super Mods: none.

I'm OK with the design of the maneuver planner UI overall, getting used to the 1A and 1B target markers wasn't much of a problem. It helps that, like Ap and Pe, you can now pin these 1A and 1B markers, and it immediately makes it clear what they mean in the pin description with "vessel @ intersect" and "target @ intersect". The maneuver node widget does need work to make dragging on the handles or the node itself a bit more predictable, the handles sometimes disappear at certain camera angles. We need a way to move the node an orbit (or multiple) forward and a way to precisely nudge the location of the node without dragging. And while I can't point at any concrete examples right now, I have the feeling there are often click priority issues with the map view in general. Sometimes I would like to be able to focus on a target world to fine tune an encounter, but to get a good view of the encounter trajectory, I have to look away from where the maneuver node actually is, forcing me into a view angle that is a poor compromise between maneuver node and encounter visibility.

The latest I've seen mentioned from the Community Managers is that they're still highly prioritizing bugfixing for stability and performance. No hints of any kind for when new content might drop. So far, the dates for patches we got have been announced less than a week ahead of time. Personally, I'm not holding my breath for the next milestone (Science) when just trying to do any sort of complex space mission, without the constraints that acquiring and returning science adds to the mix, still runs into so many bugs, frustrating at best, mission ending at worst.

Good work on finding this out! No doubt optimizations for this are planned for the future, as this will be essential to run a larger multiplayer savegame with multiple craft from multiple players in flight. I could see this being a case of deferring premature optimization until they have their internal multiplayer prototype working better. Once that's the case, there should still be lots of room to improve on this.

@GotmachineThanks for demystifying some things about what KSP2 is, and is not, under the hood. Some of the things I remember being most frustrating, time consuming and momentum-killing in my KSP1 days were the problems caused by switching or loading vessels, like spontaneous disintegrations resulting from physics startups when reloading a vessel you left safely landed or in a stable orbit, or when coming out of timewarp. And I'm noticing similar things happening now in KSP2. I was really hoping for KSP 2 to fundamentally improve on the glitches and instabilities resulting from its physics system. Can you say anything about what it would take to improve on this, is it even possible to fully solve? (To, in their own words "slay the kraken")

I've been doing a lot of rover durability design testing lately, there are some hills behind the runway where I've repeatedly managed to fall through the terrain. Usually the terrain system catches this and sends you flying into the air (probably breaking some stuff) but sometimes times I fall through. It's worse on Dres, there are whole areas on the equatorial ridge that seem to have no collision at all. Once you fall through on an airless world, you get launched back out by the singularity at the core and go flying out of the solar system. Made more difficult to learn these things by the near-certainty for the kraken to rip my lander+rover apart on approach when coming out of timewarp near the surface of Dres. I suspect the wheels being responsible for that one...

Regarding putting things inside the hull: It could just be some kind of menu that lets you add and scale features based on volume available, or it may be an actual part that is visible inside the hull in the VAB (the hull can be see-through during editing) but doesn't have physics, creating a puzzle for the player to fit things into their hull in a space efficient way. This second approach could add to the immersion when adding cargo or docking bays somewhere in the hull, since their position determines where the door will be and what internal parts might be visible when viewing the inside of the bay and help adjust to the center of mass.