DeltaDizzy

It was developed for use on a spyplane but was planned to be uprated as Pratt and Whitney's SSME entry.

Chinese stuff is one of the most under-represented areas in KSP Modding so it'll be great to have a high-quality Long March mod!

OPSEK can be largely (if not completely) made with Tantares, as it's essentially just the Russian Orbital Segment on its own. I don't know much about LOS, but with the number of generic station parts it has I would be surprised if you can't use Tantares to build LOS as well.

I don't know of any IntelliJ/JetBrains plugins, but Sublime Text and Atom both have KSP CFG plugins.

I'd really like if you kept doing these little mini-updates while saving big stuff for the dev diaries, but this all looks so neat! I am wondering how easy it will be to create a matte look on the parts though.

At least for me, KSP 2 being polished, stable, and well-rounded is worth the wait.

Wow! And out of nowhere too!

I've heard both, but it really depends on who is doing it.

Just a heads up, it's better to edit new comments into previous posts than to make a bunch of posts at close to the same time.

A soft deprecation is just making the parts inaccessible from in-game (like removing them from the tech tree and the editor part lists). The parts are still loaded, so existing crafts still work fine. Hard-deprecation is when the files themselves are deleted from the mod distribution, breaking any crafts that use those parts. Generally soft-deprecation happens first to give players a chance to retire anything using those parts before they are hard-deprecated.

Tech Tag Foundation Background For some time now, @KerbalKore and I have been working on a pseudo-historical tech tree (named CWPT) , with parallel American, Soviet, and European branches. The vast majority of the US branch uses Bluedog Design Bureau. However, BDB has several hundred parts, and configuring each one individually would be a mammoth undertaking. In light of this, we decided to instead 'tag' every part, thus allowing us to use tags to group parts and greatly lessen the workload. Soon enough, I realized this could also be helpful for other tech trees wanting to incorporate BDB, resulting in the decision to split out the tags into a standalone mod to be released first (after the tree itself has had months of delays due to IRL circumstances). I also realized that the tags as they exist now are not the best suited for generic use, as they group parts into the real rockets/spacecraft. This makes sense if you aim for a historical-ish progression, but not so good for a purely gameplay/balancing-focused progression. How it works TTF is essentially a giant ModuleManager patch that adds a single line to all supported parts of each supported mod: @PART[name]:FIRST:NEEDS[mod] { %techtag = tagName } Then, when a tech tree mod loads, it can assign parts to nodes based on the tag, instead of the part name: @PART:HAS[#techtag[tagName]] { @TechRequired = nodeName } Part modders are also given the option to allow the tags to be added directly into the part configs, as is being done with BDB.' NOTE: It shouldn't really be an issue, but any patches that use or affect the tags MUST run before LAST[TechTagFoundation]. Any custom fields inserted into part configs throw log warnings if they are still there when KSP compiles the parts. To avoid log spam all tags are removed from all parts in the aforementioned ModuleManager pass. The Point Currently, the tags are simply the names of rocket stages or spacecraft, meant to align with the original goals of CWPT. In the interest of easing the burden on other tech tree makers, I am asking what level of granularity and what 'categories' of tags should be used.

At long last, the FFT Pantheon is complete (except for FFT itself).

Like this? https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/946

That's done in Blender yes.