pg17

Maybe you encountered a bug (repeatedly), because I had several instances of relay workings for me. For example I had one 130Gm satellite in high orbit around Kerbin, another one in high orbit around Jool and it's moon, and I could control my craft in low Jool orbit with only the probe core integrated 200Mm range without any issues. While in other instances I lost connection with KSC because I didn't have the range to hit any "relay" (as I understood, every antenna is supposed to act as a relay in ksp2... but I don't know if it's only for the "real" ones or if the integrated ones are also concerned). Also double check the following thing (I, for one, made the mistake) : Make sure your two crafts/relays have the appropriate range to send and receive. A craft with a 200Mm range can't be controlled with a 130Gm antenna unless it is not farther than 200Mm from it (in the game you can't send instructions to your craft if the craft can't "reply back"). Side note for information: the occultation system isn't implemented yet (we are many who really hope it will come).

I concur! I don't know if this should be this solution (or something like having multiple color coded stacks with only one active, like those multiple shortcut bars in RPGs) but we need something to address the underlying issue. At the point I am in the game this is among the most frustrating things for me. I would take any form of improvement! I often build rockets delivering multiple vessels at once (for example a station, a lander, a communication satellite, a science return vessels, ...). Assembling it all together always result in an awfully long and messy stage "stack". It would also be helpful if those stage groups could be "locked" even outside of VAB too, so that when docking, the groups of each vessels are preserved. Maybe the groups could also be linked to the main shortcuts on the left (braking, solar panels, lights, ...) in a way as to trigger only the corresponding elements in the active / main groups.

The cleaner font really improves things! I can't wait! On the other side, as others have said, it really emphasize the need to get rid of the pixelated art direction. I understand it might have sounded like a good idea, I understand it was someone's baby and they were proud of it (and in a way, it was consistent and really well done), it's just that it doesn't work regarding readability and effectiveness to communicate information to the player in a game like KSP. On the opposite, and I know some will disagree and I respect that, seeing the skeuomorphism of KSP1 really makes me like the more contrasted and identifiable color scheme for some elements (like rcs & sas activation, altitude vs speed on the navball, ...).

That is exactly the kind of cases that calls for more procedural parts. It would need to be balanced with a max length set around the point where it is considered too long to not have a noticeable or expected bent (at that point you have to really assemble two truss together and compute the joint). That being said, I second the idea of having some sort of sub assemblies with approximated simulation in specific steps. Especially payloads like satellites or rovers secured in a closed cargo bay during takeoff. I think they could be approximated as a single block with proper mass & CoM without losing too much. But it's hard to say without knowing exactly what happens and what kind of computations are done under the hood. For really complex systems like physic simulation, I tend to trust (hope?) that the dev team already thought of such simple optimizations. So, it is either that they had a good reason not to implement them, or it is already in development / planned.

Just a quick thought (in addition to the suggested alerts) : it could be nice to have a timeline in the UI, with a dynamic or logarithmic scale, where you could see maneuver nodes and specific events (you could hover a label to get the type of event, craft concerned, time remaining and a "fast forward to" button). Also, I don't know how multiplayer will work exactly, but it could also be used to see where (or in fact "when") each player is currently at.

I agree, multi-goal missions (with known objectives from the start) seems better than multi-step ones (where you discover the next steps along the way).

I roughly agree with all your suggestions except for this part : I agree with something like a 10 to 20 rolling quicksaves, but starting back at 1 every time you start the game is not fine. I don't always make a proper save before leaving the game (and I'm probably not the only one). They can use the save datetime to know which one is older and should be overridden. As for point 8, I agree, but in my case I mostly had the reverse issue. I launch an apollo style mission (or a station with empty modules for futur use), fail, revert back to vab to make a few tweaks, launch and I realize halfway into the mission that I have stowaways in my lander and won't be able to bring back everyone in the return capsule.

I'm a simple man, when I see a sensible request for more procedural parts, I press the like button.

Currently, and despite the optimization improvements, it would probably end up killing most of our computers, or at the very least be an interesting powerpoint slideshow. That being said, if it could work, that would be awesome! From my recent experiences with docking, it looks like the 2.2km range also apply to the keyboard shortcut that allows to switch between vessels "on the fly".

The way I see it, it would be non blocking (meaning you could do the same things you can currently do, it wouldn't magically prevent you from landing anywhere for exemple), it's just that instead of getting most of the advance knowledge from the wiki (some of the knowledge I talk about isn't currently visible in the game, though that could change), you would get the option to learn it through the game with science experiments, and it would need to be balance in a way as to not prevent players (especially new comers) from experimenting things by the "trial and error" method while allowing advanced players to better "plan ahead" and optimize their missions even more. That being said, I wouldn't mind at all this being a difficulty option. It would have the additional benefit of allowing the player to optout of discovering everything again in an ulterior playthrough. And even if you don't activate the option in your first playthrough, chances are you won't visit, check and remember data for every system and every planets or moons so you would still have knowledge to "discover" in a new playthrough should you decide to activate it then.

On one hand, I think devs ressources should be spent on more important things, but on the other hand, I agree this could be fun! So maybe it's a good idea for a full fledged mod (that would add proper controls, ux and ability to create courses).

This doesn't seems like an easy things to do before takeoff (in a way that doesn't result in a plane design totally imbalanced). It would be interesting to try, but I suspect that wouldn't change anything in the way the game considers things once the two crafts been attached.

In game graphs and charts that gets completed through experiments would be awesome. I wasn't sure about suggesting it, because adding a whole data visualization system seemed like a lot of work on top of what I already suggested, but I would love it ^^ Thank you very much I didn't knew about that one, thanks for pointing me in the right direction (for now... because I agree with you, I still think this should be in the base game).

You're right! Interstellar levels of time warping are a bit concerning in that regard.

In my case, what I'm expecting is rovers to be reliable and useful. Let's take Opportunity as an example: it was planned to drive 600 meters away from the lander, and ended driving 45.16 km in roughly 14 years (this is overall time mission so if you took into consideration driving time only, it would be less but still very slow). In reality, it can be scientifically interesting to drive just 600 meters away from your lander, in KSP not so much... unless you are very close to a biome boundary. So you need to drive farther away. And so, for the same reason nobody wants to play in 1x speed for interplanetary transfers, I would like (in an ideal world) to be able to drive my "slow" rovers in 4x speed or more, in a reliable and stable way (meaning I should have issues only if I made a badly designed rover or if I tried to drive like Sébastien Loeb ). In short, I would either like to be able to drive a slow rover reasonably "fast" through time warp or to have "things to do" with my sluggish and frail rover in a reasonable distance from my lander (thus justifying I built it and brought it there in the first place). Of course, low gravity bodies will always be hazardous to drive on (as they should!), but they should be hazardous because of the environment, not because of some incomprehensible wheel behavior, bugged parts, invisible bumps and pothole, timewarp changes or quick reload. That being said, I'm not saying this is an easy thing to fix by any means.