joratto

I really hope that doesn't just mean fulfilling the minimum requirements for the roadmap. Namely, "Colony Parts" and "Orbital Vehicle Construction".

I experience the same issue frequently. Reloading often also puts spacecraft into a spin. I've found that the effect is much worse around Mun, Minmus, Ike, and Gilly; all low-mass worlds. In these cases, a spacecraft's orbit will often spontaneously become suborbital when the spacecraft is loaded.

I've experienced the same on Ike. I've also experienced the opposite on the Mun, where a craft or a kerbal would initially load underground when approached, promptly plummeting to the core. Having multiple landed vehicles in the vicinity of each other is just asking for trouble in the game's current state.

I sure hope so, but I already expect several colony features to be omitted from this update (e.g. resource gathering which isn't confirmed until a later roadmap update). Furthermore, the roadmap only officially promises " Colony Parts" and "Orbital Vehicle Construction", so "just orbital colonies" would be compatible with that information.

So are we getting surface colonies with this update, or just orbital colonies at first?

Spend an irl hour in flight. Quicksave on final approach. Reload dozens of times before I successfully paradrop an uncontrollable pod at the kapybara’s feet.

The only new Kerbolar system planet I want is a discoverable “Planet X” type on a super distant, eccentric, and inclined orbit. You would effectively need interstellar technology to reach it for a flyby, let alone to land there, and if you landed there, you’d need to do so in the near-darkness of the dim Kerbolar light.

This appears to say otherwise

I assume that maneuver planning when you have no fuel is tricky in KSP2 because the game actually calculates a continuously accelerating trajectory now, which requires you to know your instantaneous mass and TWR. If you're out of fuel, your mass can no longer change, so any speculative trajectory calculations beyond your craft's capabilities would be inaccurate, and they would get more inaccurate as you get more speculative. KSP1 didn't have this issue because its maneuver planner assumed (inaccurately) that all acceleration was impulsive. Two possible solutions for KSP2: 1. Assume the spacecraft can accelerate without losing any mass for the "speculative" part of the maneuver. 2. Assume the "speculative" part of the maneuver is impulsive. Both solutions embrace the inaccuracy of a speculative maneuver, and would probably have to be accompanied by a clear ingame warning like "maneuver plans exceeding delta v budget are inaccurate!". The benefit of these kinds of speculative maneuvers is that they'd give you a ballpark idea of what you could do with a little bit of extra delta v, even though they'd be bad at predicting what you could do with a whole lot of extra delta v.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: Radeon RX 5600 XT | RAM: 32GB In KSP1, fairings could expand in the VAB when you moused over any part of them from top to bottom. Now, it seems like fairings only expand depending on the mouse's distance from the fairing's base, which makes it difficult to interact with any part of the payload that isn't right next to the fairing base, as illustrated in the attached video. Frequency: High Severity: Low Workaround: Either don't edit moderately tall payloads once they're inside a fairing, or angle the camera awkwardly so you can edit the payload while mousing over the fairing base. The latter workaround may result in some parts of the payload becoming occluded and un-interactable. Included Attachments: 2023-12-3012-35-43.mkv .ipsImage { width: 900px !important; }

Agreed. I’ve been on both sides of those Reddit threads. As much as I enjoyed it, the whole commnet system was ironically poorly communicated imo.

I think the distinction led to interesting gameplay in KSP1. You couldn't just fly every relay satellite with that one foldable antenna which is objectively better than practically every other antenna in the game in most circumstances. Instead, if you wanted a relay, you had to figure out how you were going to fit an enormous, non-foldable, un-aerodynamic, "bulbous" dish inside your fairing and on the side of your satellite. It was an interesting building challenge that inspired creativity, which is one of KSP's pillars of fun. The foldable antenna was great for atmospheric vehicles and deep-space explorers, but if it could also function as a relay antenna, then it would end up being so overpowered that there would be little reason to use any other antenna as soon as it is unlocked. I hope there will still be a good reason to use massive, awkward antennas at the very least.

Already did. Is there any way to check previously collected surface science flavour text?

Slight spoilers for minmus biome names ahead. Since visiting minmus in For Science!, I’ve noticed that most of the biomes are named after different kinds of ice and snow (e.g. “Arctic Ice”, “Snowdrifts”). However, I recall an ancient dev video that discussed the debate over the composition of minmus. Originally, the devs wanted it to be icy, but they found out that no amount of doped water could freeze minmus at kerbin’s distance from its sun. In the end, they decided minmus should be a “ceramic” planet (incidentally, I haven’t found any information online explaining how a ceramic planet would work irl; lots of volcanic glass, I guess?). So what gives? Have the devs changed their minds and made minmus icy again? Are the icy names just physically inaccurate labels that the kerbals came up with? Is it all just a reference to the ice cream memes?

I experienced a bug that may be related: OS: Windows 10 CPU: Ryzen 5 3600 GPU: Radeon 5600XT The breakdown seems to have been worse at a particularly thin connection between small docking ports, but the craft was launched docked. craft json text:

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 3600 | GPU: AMD Radeon RX 5600 XT | RAM: 32GB In multiple vehicles, I've noticed that telescopic ladders cannot be extended or retracted, instead displaying "blocked" if they pass over a closed cargo bay when extended, even if the ladder itself is connected to a separate part from the cargo bay, even if the extended ladder is visually separated from the cargo bay, and even if the ladders pass over the back of the cargo bay (opposite the doors). The workaround is to open the cargo bay first, and then retract/extend your ladders. Severity: Low Frequency: Medium A screenshot of an example craft with this issue is attached. This craft has two cargo bays; one small and light blue and one large and white. Notice that all ladders that would pass over either cargo bay are blocked and un-extended. Included Attachments: .ipsImage { width: 900px !important; }

If approaching a munar anomaly doesn't trigger music like this, then I want my refund immediately.

Do you understand that this is incorrect because of the bug reposted by @Scarecrow71? Whether or not you'd go on to argue that this bug is also game breaking is a function of the validity of your playstyle.

Lapat won't know what hit 'em

In light of recently implemented additional Kerbal hairstyles, (and my recent replaying of XCOM 2), I would like to be able to create, customise, and name my own Kerbals. I want to insert my friends and family into the game and watch them go on space adventures and/or explode. I hope such a feature is considered for a (reasonably far) future update. I can see it being particularly fun in multiplayer.

You don’t need a space telescope to know that Venus or Jupiter’s moons exist. Even Pluto was discovered from the ground! But I would still support limited access to detailed information like surface features until you launch a space telescope or, better yet, do an initial flyby. Normalise Grand Tours in KSP!

What’s with the purple Union Jack experiment? Space greenhouse? Life support confirmed! /s

I think something like scansat should take a realistic amount of time proportional to the rotation rate of the body in question and the orbital inclination of the satellite, even if only for the sake of realism. Maybe you need to think about the planet temporarily blocking your satellite’s access to the sun, for example. Features that encourage consideration of orbital parameters are generally a good thing. But in general I agree that time constraints usually don’t matter when we have time warp. My take is that if you only want to “slap a crew cabin onto a big cool rocket and see the stars”, you could just play starfield. KSP is not special because it’s about space exploration OR spaceship building. Lots of games already fulfil those requirements. KSP is special because it’s about space complexity. If players didn’t feel their options constrained by realistic design considerations, it wouldn’t be KSP. Constraints are what make problem solving fun. I like the idea of snacks/living space/comfort requirements that would discourage players from sending Jeb on a 300y journey to Deb Deb in a mk1 command pod. I think longer missions should encourage players to think more about life support. Take the example of a player planning a multi-year manned mission to Jool. With Kerbal well-being requirements, the player might be faced with a few very different mission design options. They could: - assemble a massive spin-gravity hab module for their transfer stage in LKO with plenty of snacks, living space, and radiation protection - look for faster, non-Hohmann transfer trajectories that minimise life support requirements, allowing for a simpler hab module - invest in the construction of refuelling outposts/hotels between kerbin and jool, where kerbals could rest in between trips. These could evolve into full blown colonies that can launch to jool directly The first option can have snack masses tuned so it’s not too debilitating, while still discouraging mk1 command module transfer stages. The second option in particular would be a great way to encourage players to branch out from the faithful Hohmann and discover new orbital mechanics with real world applications. There is currently very little reason not to use a Hohmann transfer for every interplanetary mission (Gilly doesn’t count), and we shouldn’t need to wait for torch drives and interstellar for other trajectories to be practical. The third option plays into the entire core gameplay loop of this game, and finally gives us more realistic reasons to have space stations. Also, Mars Cycler anyone??? I think constraints inspire creativity, and we should be careful about giving players too much agency to optimise the fun out the game.

That’s what I’m sayin!

Unlikely given that the mohole is right on moho’s pole, which is perpendicular to Kerbol (right?). But I’m assuming they wouldn’t change the position of the mohole, and maybe they would!