Shadowmage

To see the meshes I would import the model into blender using the .mu plugin. Alternatively, I believe at one point I had some debug tools in TU/TUFX that would dump mesh names for precisely that purpose, but haven't played with the mod or code in so long, I can't say for certain, or if it was exposed in the in-game utils or needed to be recompiled with debugging enabled. Those float properties are likely referencing single-attribute values such as 'metallic' property, where the input is in the expected range of 0...1. You can see a use-case example here in the project repository: https://github.com/shadowmage45/TexturesUnlimited/blob/master/TU-Examples/TU_StockPartFix.cfg#L26 There it is being used to set the 'smoothness' value for the shader.

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)

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)