HebaruSan

It will give you transfers to other vessels, if you target them and they're in space. Landing isn't a transfer, so I won't be working on that.

Reading one of the earlier threads about this...

I look forward to seeing your citation, @Majorjim!. I've been quite curious how people convinced themselves this was a thing.

Done.

FYI, you went backwards on SpaceDock (the previous release was entered as 1.9.20.2):

I asked in another context where people thought that higher part counts were promised, and I received a link to an interview with a Youtuber, who asked how the availability of "new hardware" had affected the development process. Nate responded, in part: ... which the fan base interpreted as a commitment to dramatically improve performance for high part count craft, as can be seen in a few comments above (much like what happened with the "slay the kraken" comment, which just means "we will have a process for fixing bugs").

DPAI was for me like training wheels. Once I got used to it, suddenly it "clicked" for me how to do most of it with the navball. The alignment indicator is nice, but would be nicer as just an SAS mode.

The support for bots is kind of nice. The cloud software that CKAN runs would be hard to monitor otherwise, but when we started we dumping its warnings and errors into a #netkan-bot channel, suddenly we were able to keep up with what's happening pretty easily.

The "kraken" was a problem with interplanetary journeys going awry because of floating point precision problems (solved by way of the "floating origin"), not wobbly rockets. https://wiki.kerbalspaceprogram.com/wiki/Version_history#v0.17 https://www.kerbalspaceprogram.com/ksp/api/class_krakensbane.html If you use it to mean any and all bugs, then that kraken will never be slain.

Probably this:

Hi Nate! If/when non-Windows platforms are added, it would be important for tools like CKAN to be able to get the version of the game programmatically. In KSP1 this information was provided by the buildID.txt file, which contained the build ID which software could map to the version, or the readme.txt file, which had a line at the start of the changelog specifying the version. Currently for KSP2, neither of these files nor anything similar exists, so we can only get the version from the properties of the KSP2_x64.exe file, which is a Windows-specific solution. Any chance of adding something resembling the buildID.txt file before/with the release of non-Windows platforms? (Just wanted to try to get this into your field of view before it becomes an emergency. Cheers!)

This would be sensible if an automated background burn could consistently succeed/fail the same way that manual burns do. If you've done a long burn with nuclear engines in KSP1, you have seen that burns can stop for reasons other than insufficient fuel. If engine shut-down due to overheating will still be a thing, then executing burns without the full physics sim running starts to look unlikely.

It would be good to specify which keys you're pressing and what response you're expecting. The notes suggest there may have been a relevant change in the latest patch: Traditionally, pitch inputs are "reversed" in flight sims because you pull up/back on the joystick to tilt the craft up and push forwards/down to tilt it down. Later this schema was applied to mice and spread to other kinds of games like FPS. (This is why many games have a "reverse mouse Y" checkbox in the settings, some of us got used to that and find the "normal" orientation unusable.) And IIRC KSP1 applied it to keyboard inputs. It may simply be that you have a different expectation of what is normal and what is "reversed" from the devs.

Maybe put the latest affected version in the title, similar to the convention for mods: "[0.1.1.0] VAB explodes on click"

FYI, sometimes you can find an answer to a frequently asked question if you scroll up and read previous responses: