Shadowmage

Yes, as far as I'm aware, pods without hatches (added from mods) is still an issue with KSP 1.9+. Also yes, this mod should work fine for KSP 1.9.x. Untested on KSP 1.10, but should work there as well.

Doesn't sound like it; changing the length (or diameter), should change the thrust + fuel amount, while maintaining a constant burn-time and ISP. Delta-V is irrelevant for a single part, and depends upon the configuration of the entire craft in order to make a meaningful calculation. TLDR: Something likely broke in one of the recent KSP updates (or has simply been broken for a long time and previously unreported). Yet another thing to add to the 'todo' list if/when I have time to return to development tasks. This link should work though (no clue why the posted one goes to Fandom; it shouldn't....) https://www.curseforge.com/kerbal/ksp-mods/sstu-shadow-space-technologies-unlimited

Correct. SQUAD supplied a pre-made reflection map for the VAB and SPH scenes rather than using run-time reflection probe rendering; however, they did not 'bake' the map properly which is why there is a difference in reflection quality between editor and flight scenes.

Is it all working properly for you now? (just wanted to make sure there wasn't an issue that needed further attention)

Have you turned on real time reflections in the stock game options? (generally, black reflections means the stock system is disabled; and as TU leverages the stock reflection system for its shaders, having it disabled also kills all of TUs shader)

That is the likely answer. Unfortunately, work is still keeping me buried, so I haven't been able to poke my head out yet to see what the damage is from the update.

Apologies, I cannot directly answer this question at this time. I wasn't even sure what a LUT was, how to use them, or why one would want to use them when I created TUFX, and as such, really didn't spend much time on implementing those features (they were implemented, but as I had no LUTs to use, or even know how/why to use them, it was never tested, or even verified to work). Likely that this is something I can look into more in-depth when I have time to return to modding development; finishing up any half-done implementations will be one of my first tasks (right after KSP version update fixes, and general bugfixing).

Those are both the part of the flight scene, there is no differentiation according to the game code and the GameScenes enum; hence they are treated the same. The list of GameScenes that I can directly query state on (and react to Scene Change events) is this: public enum GameScenes { LOADING, LOADINGBUFFER, MAINMENU, SETTINGS, CREDITS, SPACECENTER, EDITOR, FLIGHT, TRACKSTATION, PSYSTEM, MISSIONBUILDER = 21 } Note there is no separate listing for IVA/EVA/Standard flight. Just one scene -- FLIGHT. Possibility to work, sure. Plans to implement it -- not at this time. Yes, TUFX should be more or less all GPU processing. There will of course be some minor CPU overhead (As something has to send the data to/from the GPU), but the actual effects are all processed in compute and render shaders, entirely in GPU memory.

Unfortunately, from my understanding, this is an issue caused by KSPs insane camera clip settings (specifically the distance between the near and far planes); and as such, cannot be fixed without impacting regular rendering. Screenspace-AO effects are intended to be used on close to mid-range geometry, and as such that is what the effect authors focused on optimizations for. Not currently/no plans at the moment. Does KSP support Metal? Does Unity and their Post-Process-Packv2 support Metal? (honestly asking, have no idea; but any support by TUFX is entirely dependent on support in both of those other areas first) Probably will work, but will likely have a noticeable impact on frame-rates; low end hardware is where you start turning off such fancy effects, rather than looking to enable them. Some specific effects (or settings) will have a larger impact than others, and some of the effects are extremely cheap and fast, so you might be able to fine-tune what is enabled and how it is configured to still allow it to be usable.

You have to have TU installed, as it is a plugin-level compile-time dependency (IIRC e.g. the KSPWheel plugin won't work without the TU plugin also present; unless I somehow managed to do it without a dependency; honestly don't remember). However, you don't have to use the current configs/models/textures (which is where the reflection stuff is coming from). Go and download one of the older releases (from before the texture updates), delete the existing PBR configs/models/textures, and replace with the legacy ones. The old configs and models/textures will work just fine alongside the newer plugin. Actually, might be easier to simply download the older release, and manually replace/update the KSPWheel.dll with the latest version. Either way accomplishes the exact same thing if done correctly. TLDR: You can continue to use the legacy part configs / models / textures alongside the newer plugin; but such installation/configuration/etc is unsupported beyond the simple hints/instructions listed above.

You are using an old KSP, with newer mods. Don't do that. It will not work. Either locate the old versions of the mods, the ones written for your version of KSP; or don't use the mods until you are ready to upgrade; or upgrade your KSP to the version expected by the mods. Yes, but only if you use the proper version of KSP for all of the mods+dependencies. If you downloaded the most recent SSTU+TU, it requires KSP 1.8 or newer. No exceptions.

Looks like ModuleManager is borking out during startup -- and as SSTU and TU rely on ModuleManager to facilitate patching of texture sets into parts/etc, this will cause tons of other errors. [ERR 16:55:54.485] AssemblyLoader: Exception loading 'ModuleManager': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 I'm actually seeing similar messages regarding nearly all of your plugin-based mods. None are loading properly, throwing exceptions during startup. Surprised anything is working at all.... Furthermore, it looks like these errors are being caused by trying to run newer mod versions on an old KSP version: Kerbal Space Program - 1.7.3.2594 (WindowsPlayer x64) en-us Try updating KSP to 1.8 / 1.9+. SSTU and its dependencies should work on either of those versions, but the current versions are likely not backwards compatible with 1.7.x due to changes to Unity and DLL linking. (alternatively, you might try and find the older versions of SSTU + TU, but then you also need to find older versions of all the other dependencies, and any other mods you wanted to use; probably not worth the effort).

Thought I would stop by briefly, and at least say 'hi'. Been awhile Been a very crazy couple of months, and doesn't seem like the chaos is quite over yet, but things (at least in my end of the woods) are starting to have a bit of normalcy return. Nothing notably 'bad' over the past few months, simply crazy and busy, with a lot of extra sources of stress. The good news in all of this, is that I might be able to return to development in the coming weeks. If/when development is started back up will most likely consist of maintenance and bug-fixing for the issues uncovered and encountered the past while; still don't see myself having time for new content development for awhile yet. I saw the news on the upcoming 1.10 release, and it is likely that I'll start in on the updates (for all of my mods) shortly after it is released (possibly sooner, pending a few more r/l things clearing up). Timing seems appropriate for the next round of updates. With the announced delay of KSP2, gotta keep KSP1 active and kicking for at least another year Thanks all for your patience, and assistance with answering questions and providing help to others during my absence; much appreciated. Would you be able to upload a KSP.log file that I might peruse? That will usually contain information pointing to the source of the error. Usual causes for what you are seeing are lack of dependencies, incorrect installation, or unsupported hardware or operating system (might be some issues with OSX and Linux with TexturesUnlimited that I haven't sorted out, but should likely be able to fix in the near future).

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook https://github.com/sarbian/ModuleManager/wiki/Module Manager Syntax ^^ Those are the basic instruction manual for using ModuleManager for patching files.

Alas, I never made it quite that far, and even at 8k from what I did get done, there would be some terrible artifacts. I got stuck trying to figure out what the shadow_in and shadow_out variables used in the original code were supposed to do, and what the inputs for them should be to facilitate the volumetric shadows. No documentation on either of them, other than they were used for shadows... I don't touch anything regarding screenshots -- that is all internal KSP/Unity code; nor do I believe that the post-process stack should interfere with it. (not saying it can't, or isn't, but merely that it really shouldn't)