Shadowmage

Nice to see you around Indeed, Stone Blue posted the link to the GitHub repo above. If you need anything opened up, or have any questions, feel free to reach out. Work has been keeping me too busy to do any actual modding work recently, but I do try and at least keep up on correspondence. https://github.com/shadowmage45/KSPWheel

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 (though I am a bit out-of-touch with the code having not worked on it in awhile). If removing the config line doesn't solve it, let me know and I can see about finding some time to investigate.

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 code).

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.