DeltaDizzy

Per-Save Screenshots v1.1 is out, adding a new Depth Mode. Depth Mode saves the https://en.wikipedia.org/wiki/Z-buffering as an additional screenshot to [save name]/depth every time you take a screenshot while it is enabled. These depth buffer images can be used in imagine editing software to create a depth of field effect. They will likely need contrast stretching, but to preserve game performance, plugin complexity, and artistic freedom, the buffer images are provided raw and "as-is". Depth Mode does not currently support Screenshot Supersize, as all data manipulation and processing is done manually. Depth Mode is enabled by default, but can be disabled by using ModuleManager or editing GameData/PerSaveScreenshots/PerSaveScreenshots.cfg. Feedback on Depth Mode and suggestions for improvement are welcome. Known Issues: The mod will often take 2-3 depth screenshots at once. I have not tracked down exactly why yet but am working on it. The "fade-out" from white to black happens very early and quickly as objects get farther away. I have deliberately chosen not to re-grade the images myself to improve in-game performance and to allow for maximum artistic freedom. A contrast stretch is recommended before using them as a depth mask. Example Images:

Version 1.0.1 has been released, fixing a bug where UI hiding was never enabled in the flight scene. Now available on GitHub, CKAN should pick it up soon.

I do I just need to remember to check them now that I'm back at uni haha

Per-save Screenshots | Organize your screenshots! Per-save Screenshots makes it so that when you take a screenshot, it is placed into a folder within the game's Screenshots folder that corresponds to your saved game. No more melting pot of all your screenshots, letting you find the ones you want quicker and easier. It also provides a "depth mode", letting you take depth screenshots that can be used in external programs like Photoshop to create Depth of Field effects. To take a depth screenshot, use F8. DOWNLOAD CKAN (Recommended) Manual (GitHub) License: MIT CKAN is HEAVILY recommended, as it manages the dependencies for you. I will not spend a lot of time troubleshooting manual installs, and will just redirect you to CKAN. To report bugs, file an issue here. Bug reports must include the mod and KSP versions, a copy of your KSP.log file, and minimum reproduction steps. Known Issues: The mod will often take 2-3 depth screenshots at once. I have not tracked down exactly why yet but am working on it. The "fade-out" from white to black happens very early and quickly as objects get farther away. I have deliberately chosen not to re-grade the images myself to improve in-game performance and to allow for maximum artistic freedom. A contrast stretch is recommended before using them as a depth mask. Thanks to @OrbitalManeuvers for the suggestion!

To be fair I never said anything about the rockets! Before this the farthest id gone was a Duna orbiter and Eve lander and wanted to try and fully commit. I did give myself a bit of an out in that I technically only have to orbit each body (and in the case of Jool there is probably some assist wizardry that can be done to recycle orbiters). So far it hasn't been too hard on the lander side but I haven't gone to vacuum planets yet...Dres will be fun (and its orbiter is probably my favorite yet)...

Gotten back into the game recently and have been doing a "visit every planet, land if possible but orbit (for scansat) absolutely" run. Additional rule is no replica payloads and that has made it quite fun indeed! The orbiter program is SUNBEAM and the lander program is FRESNEL. SUNBEAM 1 FRESNEL 2 (1 went to minmus) SUNBEAM 2 Tomorrow will add on my Eve/Duna orbiters (SUNBEAM Block 2/2+), my Dres orbiter (SUNBEAM Block 3) and later on my eve/duna landers (FRESNEL Block 2)

Minor Planet Sampling| V1.0.1| Unkerballed science with asteroids! (image taken in Sandbox) Have you ever wondered why Squad added comets and a Rosetta recreation but required kerbals to do any science at either them or asteroids? Wouldn't it be nice to have a reason to send missions to asteroids earlier on in the game, to add value other than mining or proving you can capture one? Minor Planet Sampling solves this by allowing probes to perform the surface sampling experiment that comets and asteroids are equipped with! Due to technical reasons and modding effort required, the vessel doing the collection *must* have a part onboard that can act as a science container, so the Breaking Ground sample arms and the stock surface ore scanner have been given the ability to store one experiment. REQUIREMENTS ModuleManager HarmonyKSP Neither of these are included in the download! DOWNLOAD CKAN (Recommended) Manual (GitHub) License: MIT CKAN is HEAVILY recommended, as it manages the dependencies for you. I will not spend a lot of time troubleshooting manual installs, and will just redirect you to CKAN. To report bugs, file an issue here. Bug reports must include the mod and KSP versions, a copy of your KSP.log file, and minimum reproduction steps.

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.