bigyihsuan

It would be real nice to have an official ModuleManager; you wouldn't need to install another mod and you could just write a quick patch into a text file, put it into GameData, and KSP2 will load it like everything else. If we could also not use the Module Manager syntax, maybe use JS/TS/JSON or something that's not MM syntax, that would help with accessibility a little bit.

I've been around in the modded Minecraft community long enough to see us balkanize ourselves by MC version and mod loader many times. 1.2.5, 1.7.10, 1.12, 1.16, 1.18 and beyond; Forge and Fabric (mainly). All you get with this splitting is that mods either: Stay and continue to be developed on a specific MC versions. Get abandoned on an old version and continue to be developed on newer MC versions. Get abandoned entirely in favor of the other mod loader. Get abandoned entirely because the mod author doesn't have the time to keep up with the plethora of mod loaders and MC versions. All of these are not ideal, and all you get is annoying players rudely requesting ports to X version and/or Y mod loader, and exasperated mod authors that eventually give up and never touch the MC modding community again. KSP1 was an anomaly in my view, because you can use old mod for an old version and usually it'll work with few (new) bugs on the newer versions. I really don't want to see "mod loader wars" in KSP, because I don't want to deal with that feeling of "oh that seems like a cool mod; oh, it's for an incompatible mod loader/version..."

See title. In the picture below, the left one is "black" with the color set to red, and the right is is "black" with the color set to blue.

As it is currently, the "main" craft is centered onto the center of the screen. This is fine normally. However, since you can't close the parts menu, it makes the screen feel "lopsided", because you see more portions of the VAB to the right of the craft than on the left of the craft. This is different from how KSP1 does it, which centers the craft on the visible portion of the editor, rather than the center of the entire screen. This picture shows the offset needed to "center" the craft on the visible part of the VAB, i.e. the craft should be on the purple line to be "centered":

I didn't notice that those are Saturn-style clamps. Purdy. Tomorrow is probably "and here are 6 LRBs for your Mun mission"

Procedural engines would be hell to implement. Though, if Simple Rockets 2/Juno can do it, surely KSP can as well.

Procedural tanks, trusses, and fairings are a main want for me. The tanks they don't need to be that procedural, if it let me combine the 4 sizes (1x, 2x, 4x, 8x) into 1 part, I'll be happy. Trusses are an interesting thing, because so many missions would benefit from a light-weight structural component as an adapter, core structural part, etc. It'd also make a great payload/interstage adapter if we can make it hollow/ring-shaped. Fairings are a given, we have those already in KSP1.

Debug code is still code: it'll be compiled into the executable anyway, regardless of its purpose. Even if the debug code is never run, and is logically unreachable normally, sometimes compilers optimize it away and make unreachable code reachable.

Reaction wheels are OP in KSP1, in real life reaction wheels are actually pretty weak, need despinning, etc. and you usually use RCS instead. I welcome this change, I slap RCS everywhere to keep control manageable anyway.

Debug builds are, in general, slower due to extra stuff being put into the executable (code symbols, line numbers, extra debug-only code, etc) to help with debugging;. When you build software/a game for release, you usually turn on release mode to strip out unneeded code and data meant only for debugging.

Because it will get that development time. Remember, this is just the first release of the early access. It'll (hopefully) get better as more dev time gets put in.

but it is before release; it's before the version 1.0 release As for system specs, I'm somewhere around the recommended specs, thankfully: Intel i7-13700KF NVIDIA GeForce RTX 3070Ti 32 GB RAM Plenty of HDD space I'm aiming for 1440p, and I'm not expecting higher than 60fps, since KSP with ~200 mods couldn't reach that at 1440p. I'll be ok; I've played KSP with worse specs and worse FPSes.

I have spent the entire day reading forum posts and Discord messages complaining about the recommended specs. If sort of childish complaining is what the KSP community has come to, so be it. I am firmly in the camp of "These specs are most probably over-estimated, and needs more low-power PCs to determine the minimum. This is the first alpha release: optimizations will come in time, and the requirements will go lower as development continues." Seriously, do the complaining people know the meaning of "Early Access"? Were you expecting a fully polished, 100% complete game as a first release in a series of in-development snapshots? People seriously need to temper their expectations.

SteamDB reports that 2 new packages for KSP2 were uploaded at around 1PM EST. I wonder what that could be? https://steamdb.info/app/954850/subs/

Metallic red, matte white, matte black.

KSRSS is at 1x scale, which is smaller than JNSQ (~2.5x-ish scale). Most parts (including stock) are overpowered for 1x scale, and turns out to have realistic (-ish) performance on 2.5x scale systems. Thus, most stock-alike mods (like ACK) are made with 2.5x scale in mind, which leads to more realistic performance. In your example, instead of Block 1 being able to do TLI with the core at 1x, at 2.5x it can instead barely get to orbit, with the ICPS doing the actual injection.

Do you have screenshots of this?

The interstage fairing is the black one, and it (should) have at least 3 nodes: a floating top one, a node on the top of the base, and a bottom node. (EDIT: there should be interstage versions of all the fairing base parts, actually (except the thick base), so these instructions apply to the others as well) Attach the base to the rest of the stack using the floating node. This node will decouple if you set the base to decouple. If you're using a procedural thrust plate, attach to the middle node on the thrust plate. Change diameters and height as normal. Attach your fairing parts. Build the rest of the rocket off of the bottom node.

The fuelswitch upgrades are in their respective engine branches. You can make a new science/career save, use cheats to unlock the whole tree, and browse the nodes as you need.

welp that's a new BDB update

Here's my take:

B9 is compatible with 1.12.4, you need to set the CKAN supported versions (title bar > Settings > Compatible Game Versions > check 1.12). This will make mods marked as "incompatible" for 1.12.4 available (B9PartSwitch is marked as compatible with max 1.12.3).

I've been having trouble landing on Armstrong, what are your designs for sky cranes, bouncy balls, etc for landing manned capsules onto the surface? (of note I've found the Landertrons mod that adds in some SRBs that can automatically activate when you're close to the ground, maybe it can be of use? Maybe combine with Smart Parts so that you can have a sky crane that decouples from the capsule when vertical velocity is 0 near the ground?)

Feature request for a 3-noded part with hidden node for engine mounts, shrouds, etc: https://github.com/KSP-RO/ProceduralParts/issues/333

Based on what people are saying, so landing back on Armstrong is more like landing on Duna? Where chutes alone aren't enough, and you need something else (bouncy ball, rockets, etc) to land safely?