Shadowmage

Thanks for posting it. The only thing I can think of is the 'baseModuleIndex' is somehow interfering with the initialization process; specifying that config line should only be needed when there are multiple KSPWheelBase modules present. You might try removing those lines from the relevant PartModule nodes and see if it corrects the problem. If that doesn't resolve it, it will take some (probably minor) debugging work to figure out where and why it is failing. Likely that the issue is a simple omission or typo in either the code or configs that I'm not seeing from my brief review (

Hmm.. the array that is having the issue is likely the array of wheel colliders. Quite possibly an incorrect wheel collider index specified in the configs. Would you mind posting those up so that I could take a peek? In general if one of my mods throws a null-ref or out-of-bounds exception, it is a problem, and is likely to cascade to other issues especially if it happens during initialization such as this. I think the only way to 'fix' it will be to find out what is causing it and correct it (likely an incorrect config, but could be some obscure and as-yet-undiscovered issue with the

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;

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 updat

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 ti

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 supp

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 new

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

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 encoun