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:

That's a compiler error, it means there's a problem with the C++ source code you're trying to compile. I looked for KerbalSimpit, but I found C# code and different user names. Can you share a link to whatever it is you're doing?

Multiple builds can work; for example, Satisfactory calls their builds "Early Access" and "Experimental." They show up as two separate products in the Epic Games Store (I bought when it was exclusive there). The devs treat the Experimental build as a testbed that can change and break things every few weeks, with Early Access getting the consolidated, more stable work in longer intervals. However, this isn't realistic. Even ignoring the very low general quality of bug reports from rando gamers (someone submitted a "bug" report on the forum today complaining about the price), the experimental build bug tracker would be flooded with redundant reports of "show-stopping bugs" the team knows about and has deferred to a future patch. "They fixed X but not Y" syndrome. The signal to noise ratio would be near zero.

Asking here as well since not everybody has GitHub notifications enabled, apologies if a duplicate. Hi @OhioBob, we have been requested to add Eve Optimized Engines to CKAN. We only add mods to CKAN if it's OK with the author. Is this OK with you?

My guess is that nobody will try to completely replace the vessel tree structure with a mod, because it makes some important problems much easier to solve. You're in the VAB and you click a part to pick it up. In the tree structure world, any parts that are attached to it are picked up as part of the group, but the parent part stays in place and is not picked up. You can rotate the picked-up part freely, and since the whole group has just one attachment point to a parent, you can easily place it somewhere else. This is somewhat intuitive if your craft structure isn't crazy, and more importantly it's consistent and repeatable. Now repeat the same thought experiment in the free-form graph world. You have some part that's multiply-attached to several parts and has several other parts multiply-attached to it and some other other parts. When you pick it up, which subsets of those parts gets picked up? How do you manage the UI of re-attaching several different connection points somewhere else all at once? How would you explain to users how these things work? This is a larger scope than I would expect modders to take on. However, there is a KSP1 mod that handles one specific related case. You build your regular tree-structure craft as normal (taking advantage of all UX conveniences that model provides), and then at launch, it checks whether any unconnected parts are close enough to be attached (only for certain attachment nodes, though), and if so, it adds physics joints between them: You might very well see something like that for KSP2 as well at some point.

If your question is about docking, then stock KSP1 was already able to do this for many years (and KSP2 presumably would be as well): If you're mentioning docking as an analogy for an enhancement to the VAB, then my guess is that no, they won't do that.

From the other SpaceDock thread: Though I have heard that in some browsers it's ctrl-F5 instead, and I generally use ctrl-shift-R.

Which browser you use is not a factor in this problem. Reiterating in case anyone else scrolls to the bottom after another reply:

What about pasting a quoted form of it into the OP, so it's easier to spot?

That's because you used one browser to load those pages in the preceeding 30 days and not the other. @James Kerman, could you somehow mark that post as the answer to this? It seems people are still able to browse past it without reading.