DeltaDizzy

So the "mag boots" werent a feature? huh...

I am most excited for the in-warp burning and new tutorials!

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.

Plumes will never be the same again, thats for sure.

You need to go to the github repository (there is a link in the first post on the thread) and download the "v1.7.0-Development" branch. Be warned that the parts are subject to change at any time and for any reason, so don't use it in a save you care about.

Well the flyby is only to change the inclination, which is why I had wondered about it.

How well does TOT work for planning multistep transfers to very inclined bodies? (like Ulysses if it was rendezvousing with a comet)

The IVAs for it contain props provided by that. They are in a seperate mod because several of Nertea's mods reuse those props.

Finally some good-looking aluminum-powered death sticks!

To do that MKS needs to write the current/predicted power consumption (which one depends on whether you are in flight or the VAB) to a KSPField (that means some code additions are needed) and the rest can be in a config. Edit these values as needed. PARTMODULEHANDLER { // The name of the module name = <the module you want to add to the simulator> // The type of handler - can be Power or Heat type = Power // The name of the handler to use handlerModuleName = GenericFieldDataHandler // Is this shown in the UI at all? visible = true // Do we use solar distance attenuation? solarEfficiencyEffects = false // Is this module a producer by default? producer = false // Is this module a consumer by default? consumer = true // Does this item start off as active in the UI? Should canonically be true for constant sources/draws simulated = true // Does this item count as a continuous power source for the purpose of the UI? continuous = true HANDLER_CONFIG { // Field to poll in editor editorFieldName = <field to ask for power consumption> // Field to poll in flight flightFieldName = <field to ask for power consumption> // Multiply the output by these if you need to. Convention is that a consumer is negative. editorValueScalar = 1.0 flightValueScalar = 1.0 } }

Follow this tutorial, it seems to cover everything: https://www.youtube.com/watch?v=77W2JSL7-r8. When you get to the coning part, using the CollisionFX repo.