Shadowmage

https://github.com/shadowmage45/KerbalFoundries2/blob/master/GameData/KerbalFoundries/Parts/ALG-Large.cfg#L214 That is the line that controls the 'max load' of the wheel at its default scale, listed in....metric tons I believe (been awhile...). Your actual load for that wheel should only be 25-30% of that 'max' value to accommodate for driving forces -- the 'max' value is the point where the wheel starts to incur damage/starts to over-stress -- if it exceeds that max for too long, it will break. Anyway, you can patch that value to increase it to whatever you want (an absurdly large 999999?). Or patch that KSPWheelDamage module out entirely to remove the ability for it to break altogether. Can also simply turn off damage/breaking in the mod settings IIRC (though that applies to all wheels).

I've heard of the issue, but do not no the exact cause. Likely it is something in the Unity Post Processing stack that isn't playing nicely with it. Would have to know exactly what triggers these screenshots (is it Unity built-in code, or KSP custom code?), how they are processed, etc. Seems probable that it is KSP custom code, calling some custom routines on their custom camera rigs, which are then ignoring the post-process framework (and/or are unaware of the framework, which may be manipulating settings that they rely upon). (this 'supersize screenshot' feature was added after I stepped away from mod development, so I have zero information on it)

Feel free to put in a PR for this change and I can merge it into main branch for inclusion in the next release. Good work on finding the solution

Honestly one of the most reasonable requests I've seen posted. I did have a set of patches for the stock wheels put together at some point, but hadn't been updated in quite some time -- https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches Probably a good starting point; unless the stock parts have changed, the existing patches should likely continue to work. There were definitely a couple that needed some tweaks though. I'm not sure I'll personally have time to get too involved in the near future (life and work still occupying my time), but hopefully the link above can provide something functional in the interim (or possibly provide others a start on the conversion).

Is it not working under the recent KSP versions? Never hurts to give it a try...

Not provided with TU itself. This is mostly a 'framework' for other modders to use. At one point several others had started creating configs for the stock + DLC parts (basic retextures, full retextures, full recoloring masks, etc), but I'm a bit out-of-touch and do not know the current compatibility status or location of those mods. Hopefully someone else can respond with that info

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)