Wyzard

Well, all of the features are in progress already. Multiplayer, for example, is the last item in the "roadmap", but IIRC they've talked about how they're already testing with it internally. I expect that the foundations for all this stuff is already in place, and the steps in the roadmap are just getting each feature finished and "polished" enough to enable for users — not starting on each feature from the beginning. Also, remember that KSP1 was in Steam early access for about two years, and early versions could be bought directly from Squad for nearly two years before it even became available (as EA) on Steam. This doesn't seem drastically different.

SystemHeat aside, the CryoTanks mod makes normal tanks support cooling, but the special cryogenic tanks are more efficient at it (less EC usage). The SystemHeatBoiloff patch overrides that and makes them all the same, but I suspect that's a bug, and I just submitted a pull request to make the special tanks better again, in the same proportion as before.

More specifically: CryoTanks has built-in boiloff support where, if cooling is enabled, the tank consumes EC to refrigerate itself and prevent boiloff. Radiator parts aren't relevant for this; the tank has its own invisible implied radiators or something. The optional SystemHeatBoiloff patch replaces that with a different implementation, where the tank doesn't directly use EC, but it emits heat to SystemHeat, which routes it to actual radiator parts. (And those radiators consume EC instead.) In either case, tanks that hold cryo fuels have an "enable cooling" button in the tank's right-click menu. (@JohnyCraft, it sounds like this is the part you'd overlooked.) It's enabled by default for the special insulated tanks added by the CryoTanks mod, but disabled by default for "regular" tanks.

I think it's implied that the tank has a heat pump to actively push energy up the temperature gradient, from the cold side to the hot side. But if you're using cryo tanks together with other things that need cooling, you'll probably want to use separate loops anyway, because different parts have different ideal loop temperatures. (Cryo tanks want to be 300K; electrostatic engines want to be 350K; mining drills want to be 400K; the Convert-O-Tron and the plasma engines want to be 500K; nukes want to be upwards of 750K.)

People using Steam will already have the option to buy KSP2, from Steam. It's pretty weird for a game bought from Steam to act as a storefront for non-Steam purchases of a different game, especially when that game is also sold through Steam. And the KSP1 in-game main menu already has a link to the merch store; that's not something that needs a separate launcher program. Fortunately, the launcher seems to be Windows-only. Doesn't show up on Linux or Mac.

The OP says: "The 1.0 version of KSP 2 will include significantly more features than the Early Access version, such as what you see on the roadmap plus other items added along the way."

I like this! Cryo tanks needing actual radiators is exactly how it ought to work, and it makes the low-temp radiator parts more broadly useful. (That plus I've been making a point of using more NF ion engines in my current playthrough; I like that those need cooling too.)

I'm surprised to see so many people saying things like "they want $50 just to test an unfinished game" — like, no, it's $50 for the complete, finished game, to be delivered later, basically a preorder with a $10 (edit: $60 was speculation, not an official number) discount. And in the meantime, you can play unfinished versions if you want to. And it's not just KSP1 with nicer graphics; it's clear they've made a lot of architectural improvements under the hood. KSP1 is fun, but it's always been kinda rickety, especially with mods; KSP2 should be a more solid and stable foundation since it was designed from the start with a clear idea of what features it needs to support, plus lessons learned from KSP1's limitations. I'm disappointed, though not really surprised, that the EA won't support Linux (yet); I'm unlikely to actually play it much at first, unless it runs well in Steam's Proton or my (much older) Windows computer can handle it. I plan to buy the EA regardless, though, since I think it's worth it. Steam tells me I've played KSP1 for about 3500 hours; at $70 for the game plus expansions, that's about 2 cents per hour, which makes it one of the most economical games I've ever bought. I expect KSP2 will be similar, even if I have to wait a while.

You created an account just to complain about gimbals and couldn't be bothered to provide any details whatsoever about what you think is wrong? Bruh, don't be a jerk.

I haven't noticed any problems, and minor patch updates generally don't break most mods.

Yeah, I don't actually need those, nor even have any specific use in mind for them — just wanted something to fill the otherwise-empty space there, and figured it might be handy at some point to have an 0.625m docking option.

My first small station in my current save, built for a "space camp" contract. And it fits perfectly in a KW 2.5m expanded fairing! (Doesn't have enough hab space for all the kerbals that'll be staying there for 40 days, but I figure that's OK since it's a space camp: the campers will take turns living in the hab ring, the core station parts, and their own docked crew capsules, to get a breadth of different experiences.)

Designing a station just now, I noticed that the PPF-B "Blimp" 2.5m inflatable hab has an entry cost of 9500, but the PPF-A "Dirigible" has an entry cost of 103500, about ten times as much for just twice the size. I'm guessing one of those is a typo, but I'm not sure which — the Blimp costs less to unlock than the 1.25m Winston and Volleyball inflatable habs, but the Dirigible costs much more to unlock than the 3.75m habs. The Blimp's per-part cost (after unlocking) is 10350, exactly one-tenth the Dirigible's entry cost, which is less than the Blimp's own entry cost (most/all of the other habs have an entry cost that's more than the per-part cost). I can patch the parts locally to have a different price ratio, but I just wanted to report the possible bug in case there's another bugfix release. (For my local patch, I think I'll make the Blimp cost 50% more than the Eclair for both entry and per-part since it's the same length and holds 50% more kerbals, and then I'll make the Dirigible double that. But if the official numbers change in a later release, I'll adjust funds in my save accordingly.)

The fairing attaches to the bottom of the core and other parts attach to the bottom of the fairing. So if you're building downward, place core first and then fairing; if you're building upward, place fairing first and then core.

It's a reference to the phrase "the world is your oyster", which is an idiom that means "you can do anything you want". In this context, the sentence is saying that by placing the thrusters carefully in different locations on different axes, your spacecraft can have freedom of movement and rotation in all directions. (This sounds to me like a hint that you shouldn't just place them in symmetry around a cylinder like you'd do with many other RCS thruster parts.)

Coming back to KSP after not having played for awhile, I noticed that ReStock's 1.25m "EP-12 Engine Plate" appears in-game even when MH is installed, which also provides an EP-12 Engine Plate. The other ReStock engine plates are hidden via MM when MH is installed, but the 1.25m one doesn't have the flag to make that happen. (Maybe MH didn't provide a 1.25m engine plate before 1.12? I don't remember.) Anyway, here's a patch for anyone who's interested: @PART[restock-engineplate-125-1] { # Hide when MH is installed &MHReplacement = True }

Are you actually unable to load the crafts? I also uninstalled this recently (because I think Waterfall provides lighting effects of its own) and the craft loading window says "unknown part modules" in red on each file, but it doesn't prevent opening the file; the game just ignores the data for the unknown modules. And then if you re-save the craft, that ignored data won't be included in the new version of the file, so the warning will go away. (The game's craft-loading window is quirky, though: you have to open it, close it, and open it again to actually see the warning go away after re-saving a craft.)

Understandable; thanks for explaining. Maybe it's just the contract pack making it awkward, wanting several experiments together, so a contract that would otherwise be "send a lander" becomes "build a base" because of one experiment. I've changed the situationMask locally using MM to keep the contracts suitable for landers, but I might re-enable it later and start actually building bases. :-)

On a related note: I've noticed that I get contract offers asking to perform visual observation, and now telescope observation, on the ground in various biomes: for example, right now there's a contract to perform seismic scan, gravity scan, and telescope observation while landed in Kerbin's grasslands, and another to perform visual observations landed in various places on the Mun. Those particular contracts are from a mod (Field Research contract pack), though I'm pretty sure they're based on the same config parameters that stock contracts use. I don't remember whether I've seen stock contracts asking for those experiments. So, I wanted to ask — is that intentional? It's not infeasible to do, but putting a cupola or telescope on a lander is a different sort of thing than a small part like a seismometer. It's not really a problem — I don't want to build landers like that, but I just don't take the contracts — but I wanted to bring it up in case it's a bug. I think (though I haven't tested) it's because the situationMask for those experiments includes the 0x1 and 0x2 bits for the SrfLanded and SrfSplashed situations. If it's not intended, please consider changing the situationMask from 51 to 48, so that the experiments will only generate contracts in space. (And, if it's a bug, sorry for not bringing it up until just after a bugfix release!)

Put the StationPartsExpansionRedux and StationPartsExpansionReduxIVAs folders in your GameData. Not their contents, the folders themselves. You don't need to (and shouldn't) pull out individual files and put them in different places. (This is how it's always worked, btw, and most mods follow the same structure: GameData/Whatever in the mod zip becomes GameData/Whatever in your installation. Nertea's Extras folder is like an auxiliary optional GameData, so Extras/WhateverElse becomes GameData/WhateverElse.)

Probably related: I've noticed that with this mod installed, the VAB part descriptions for the Breaking Ground deployable science parts show both a Cargo Part module ("cannot be placed in a storage container but can be manipulated in EVA construction") and an Inventory Part module ("a cargo part that can be placed in inventories"). Despite what the first one of those says, the parts can still be placed in inventories and deployed by kerbals, so despite the confusing message I don't see an actual problem — though I haven't tested beyond the quick smoke-test of deploying one on the launchpad. I haven't looked at technical details, but presumably this is caused by having both ModuleCargoPart and ModuleInventoryPart. Without the Part Volume mod, the Breaking Ground deployables only appear as inventory parts, not cargo parts.

I'm not sure how much of this is stock behavior vs. SystemHeat code, but I've noticed that having the SystemHeat heat exchanger on a craft causes the craft's EC to be reduced during timewarp. It's weird, though: not like a normal EC drain. Instead, EC goes down to a particular number and then stays there, and the number is lower at higher timewarp levels. Example craft to reproduce: stock 2.5m probe core and 2.5m battery, H250-64 cryo tank in LH2/Ox mode, four XR-500 radiators, and Garnet reactor. With just those parts, there's no weird behavior, but add a heat exchanger, go to the launchpad, and timewarp up to 10000x or 100000x and look at what happens with the EC level. It doesn't seem to make a difference which direction the exchanger is configured for, but increasing its temperature adjustment reduces the EC limit for a given timewarp level. For example, with the temperature adjustment set to 300, the craft runs out of EC at max timewarp (which is how I noticed it on an actual spacecraft). I'm guessing this is related to the exchanger's own power usage, but it doesn't happen with the cryo tank (which also uses EC). I have DynamicBatteryStorage installed, though I don't know whether that's involved. Also: while building that test craft in the VAB, before the reactor and exchanger are attached, take a look at the PAW for the radiators. "System Flux" flickers rapidly between 0 and -1, and "System Temperature" flickers rapidly between "3 / 3" and "3 / NaN", with the NaN appearing when the flux is 0. (The numbers are stable when the reactor and/or heat exchanger are attached.)

That's a Squad part, from the Breaking Ground expansion. It's plausible that there could be some sort of stock bug causing that, though it's more likely something caused by a mod (maybe one that does things with science parts). It's unlikely to be caused by CTT, though. CTT is just a ModuleManager patch that adds nodes to the tech tree; it doesn't contain any executable code and doesn't change the behavior of any parts.

I doubt it was a specific decision that the part shouldn't have KIS inventory; it's more like a KIS limitation. The part in question (MKS Ranger mini-hab) is inflatable and has no crew capacity in its default state. When crew seats are added by inflating the part, KIS seat inventories ought to be added too, but KIS doesn't support dynamically varying the number of seats like that. It just uses the base number from the part config, which is zero.

FWIW, the mechanics you described sound pretty reasonable to me. Seems like there are issues with unclear UI, but I don't see anything "missing" mechanics-wise. (And the "unclear UI" thing is halfway just that the documentation is unfinished.)