Shadowmage

1.) You are referring to an IVA 2.) Texture != Material. Model != Mesh. 3.) No, it doesn't have one mesh with multiple textures. It has one MODEL (XXXXXX.mu), that has MULTIPLE meshes inside of it, that each have multiple textures. 4.) You need to find the mesh-names and target them in your patch specifically. Here is the model mesh hierarchy for that model. Find which mesh each texture targets in the existing model, and patch it accordingly. [LOG 09:49:09.157] [DebugStuff] +S2000 T:Untagged L:0 (Default) | Transform - S2000 | Part - S2000 | Highlighter - S2000 | ModuleControlSurface - S2000 | KSPTextureSwitch - S2000 | AudioSource - S2000 | Rigidbody - S2000 | --+model T:Untagged L:0 (Default) | Transform - model | |--+Squad/Spaces/Mk1-3/model(Clone) T:Untagged L:0 (Default) | | Transform - Squad/Spaces/Mk1-3/model(Clone) | | | --+rotation T:Untagged L:0 (Default) | | Transform - rotation | | | |---Mk1_3_IvaShell T:Untagged L:0 (Default) | | Transform - Mk1_3_IvaShell | | MeshFilter - Mk1_3_IvaShell | | MeshRenderer - Mk1_3_IvaShell | | | |---Mk1_3_IvaProps T:Untagged L:0 (Default) | | Transform - Mk1_3_IvaProps | | MeshFilter - Mk1_3_IvaProps | | MeshRenderer - Mk1_3_IvaProps | | | |---Mk1_3_IvaMask T:Untagged L:0 (Default) | | Transform - Mk1_3_IvaMask | | MeshFilter - Mk1_3_IvaMask | | MeshRenderer - Mk1_3_IvaMask | | | |---pilotCamera_01 T:Untagged L:0 (Default) | | Transform - pilotCamera_01 | | Camera - pilotCamera_01 | | | |---pilotSeat_01 T:Untagged L:0 (Default) | | Transform - pilotSeat_01 | | | |--+pilot seat_01 T:Untagged L:0 (Default) | | | Transform - pilot seat_01 | | | | | --+seat T:Untagged L:0 (Default) | | | Transform - seat | | | | | |---Cylinder007 T:Untagged L:0 (Default) | | | Transform - Cylinder007 | | | MeshFilter - Cylinder007 | | | MeshRenderer - Cylinder007 | | | | | |---Left Arm Mount T:Untagged L:0 (Default) | | | Transform - Left Arm Mount | | | MeshFilter - Left Arm Mount | | | MeshRenderer - Left Arm Mount | | | | | |---Left Rudder 2 T:Untagged L:0 (Default) | | | Transform - Left Rudder 2 | | | MeshFilter - Left Rudder 2 | | | MeshRenderer - Left Rudder 2 | | | | | |---Right Rudder 2 T:Untagged L:0 (Default) | | | Transform - Right Rudder 2 | | | MeshFilter - Right Rudder 2 | | | MeshRenderer - Right Rudder 2 | | | | | |---Right Arm mount T:Untagged L:0 (Default) | | | Transform - Right Arm mount | | | MeshFilter - Right Arm mount | | | MeshRenderer - Right Arm mount | | | | | |---Rudder Anchor T:Untagged L:0 (Default) | | | Transform - Rudder Anchor | | | MeshFilter - Rudder Anchor | | | MeshRenderer - Rudder Anchor | | | | | |---Seat002 T:Untagged L:0 (Default) | | | Transform - Seat002 | | | MeshFilter - Seat002 | | | MeshRenderer - Seat002 | | | | | ---Stick002 T:Untagged L:0 (Default) | | Transform - Stick002 | | MeshFilter - Stick002 | | MeshRenderer - Stick002 | | | |---pilotSeat_02 T:Untagged L:0 (Default) | | Transform - pilotSeat_02 | | | |---pilotCamera_02 T:Untagged L:0 (Default) | | Transform - pilotCamera_02 | | Camera - pilotCamera_02 | | | |--+pilot seat_02 T:Untagged L:0 (Default) | | | Transform - pilot seat_02 | | | | | --+seat T:Untagged L:0 (Default) | | | Transform - seat | | | | | |---Cylinder007 T:Untagged L:0 (Default) | | | Transform - Cylinder007 | | | MeshFilter - Cylinder007 | | | MeshRenderer - Cylinder007 | | | | | |---Left Arm Mount T:Untagged L:0 (Default) | | | Transform - Left Arm Mount | | | MeshFilter - Left Arm Mount | | | MeshRenderer - Left Arm Mount | | | | | |---Left Rudder 2 T:Untagged L:0 (Default) | | | Transform - Left Rudder 2 | | | MeshFilter - Left Rudder 2 | | | MeshRenderer - Left Rudder 2 | | | | | |---Right Rudder 2 T:Untagged L:0 (Default) | | | Transform - Right Rudder 2 | | | MeshFilter - Right Rudder 2 | | | MeshRenderer - Right Rudder 2 | | | | | |---Right Arm mount T:Untagged L:0 (Default) | | | Transform - Right Arm mount | | | MeshFilter - Right Arm mount | | | MeshRenderer - Right Arm mount | | | | | |---Rudder Anchor T:Untagged L:0 (Default) | | | Transform - Rudder Anchor | | | MeshFilter - Rudder Anchor | | | MeshRenderer - Rudder Anchor | | | | | |---Seat002 T:Untagged L:0 (Default) | | | Transform - Seat002 | | | MeshFilter - Seat002 | | | MeshRenderer - Seat002 | | | | | ---Stick002 T:Untagged L:0 (Default) | | Transform - Stick002 | | MeshFilter - Stick002 | | MeshRenderer - Stick002 | | | |---pilotSeat_03 T:Untagged L:0 (Default) | | Transform - pilotSeat_03 | | | |---pilotCamera_03 T:Untagged L:0 (Default) | | Transform - pilotCamera_03 | | Camera - pilotCamera_03 | | | |--+pilot seat_03 T:Untagged L:0 (Default) | | | Transform - pilot seat_03 | | | | | --+seat T:Untagged L:0 (Default) | | | Transform - seat | | | | | |---Cylinder007 T:Untagged L:0 (Default) | | | Transform - Cylinder007 | | | MeshFilter - Cylinder007 | | | MeshRenderer - Cylinder007 | | | | | |---Left Arm Mount T:Untagged L:0 (Default) | | | Transform - Left Arm Mount | | | MeshFilter - Left Arm Mount | | | MeshRenderer - Left Arm Mount | | | | | |---Left Rudder 2 T:Untagged L:0 (Default) | | | Transform - Left Rudder 2 | | | MeshFilter - Left Rudder 2 | | | MeshRenderer - Left Rudder 2 | | | | | |---Right Rudder 2 T:Untagged L:0 (Default) | | | Transform - Right Rudder 2 | | | MeshFilter - Right Rudder 2 | | | MeshRenderer - Right Rudder 2 | | | | | |---Right Arm mount T:Untagged L:0 (Default) | | | Transform - Right Arm mount | | | MeshFilter - Right Arm mount | | | MeshRenderer - Right Arm mount | | | | | |---Rudder Anchor T:Untagged L:0 (Default) | | | Transform - Rudder Anchor | | | MeshFilter - Rudder Anchor | | | MeshRenderer - Rudder Anchor | | | | | |---Seat002 T:Untagged L:0 (Default) | | | Transform - Seat002 | | | MeshFilter - Seat002 | | | MeshRenderer - Seat002 | | | | | ---Stick002 T:Untagged L:0 (Default) | | Transform - Stick002 | | MeshFilter - Stick002 | | MeshRenderer - Stick002 | | | |---light_1 T:Untagged L:0 (Default) | | Transform - light_1 | | Light - light_1 | | | |---light_hatch T:Untagged L:0 (Default) | | Transform - light_hatch | | Light - light_hatch | | | |---light_1RED T:Untagged L:0 (Default) | | Transform - light_1RED | | Light - light_1RED | | | |---light_1 (1) T:Untagged L:0 (Default) | | Transform - light_1 (1) | | Light - light_1 (1) | | | |--+WindowFocusPoint T:Untagged L:0 (Default) | | | Transform - WindowFocusPoint | | | BoxCollider - WindowFocusPoint | | | | | ---WindowEyeTransform T:Untagged L:0 (Default) | | Transform - WindowEyeTransform | | | |--+WindowFocusPoint02 T:Untagged L:0 (Default) | | | Transform - WindowFocusPoint02 | | | BoxCollider - WindowFocusPoint02 | | | | | ---WindowEyeTransform02 T:Untagged L:0 (Default) | | Transform - WindowEyeTransform02 | | | |--+WindowFocusPoint03 T:Untagged L:0 (Default) | | | Transform - WindowFocusPoint03 | | | BoxCollider - WindowFocusPoint03 | | | | | ---WindowEyeTransform03 T:Untagged L:0 (Default) | | Transform - WindowEyeTransform03 | | | |--+WindowFocusPoint04 T:Untagged L:0 (Default) | | | Transform - WindowFocusPoint04 | | | BoxCollider - WindowFocusPoint04 | | | | | ---WindowEyeTransform04 T:Untagged L:0 (Default) | | Transform - WindowEyeTransform04 | | | --+WindowFocusPoint05 T:Untagged L:0 (Default) | | Transform - WindowFocusPoint05 | | BoxCollider - WindowFocusPoint05 | | | ---WindowEyeTransform05 T:Untagged L:0 (Default) | Transform - WindowEyeTransform05 | ---Surface Attach Collider T:Untagged L:0 (Default) Transform - Surface Attach Collider SphereCollider - Surface Attach Collider And because I'm 99% sure you'll not know what I'm talking about... here is an example that applies the existing stock textures to the existing meshes. Replace with your texture names, or whatever.... KSP_MODEL_SHADER { name = Stock-MK1-3-IVA model = Squad/Spaces/Mk1-3/model MATERIAL { shader = SSTU/PBR/StockMetallicBumped texture = _MainTex, Squad/Spaces/Mk1-3/Mk1_3_IvaShell_Diffuse texture = _BumpMap, Squad/Spaces/Mk1-3/Mk1_3_IvaShell_Normal texture = _Emissive, Squad/Spaces/Mk1-3/Mk1_3_IvaShell_Emissive mesh = Mk1_3_IvaShell } MATERIAL { shader = SSTU/PBR/StockMetallicBumped texture = _MainTex, Squad/Spaces/Mk1-3/Mk1_3_IvaProps_Diffuse texture = _BumpMap, Squad/Spaces/Mk1-3/Mk1_3_IvaProps_Normal excludeMesh = Mk1_3_IvaShell } }

Show me the source for what you are tring to do? What -exactly- are you trying to do? (about 1 more post way from being added to my ignore list...)

Texture slots. You know -- the things you plug textures into in the Unity Editor. There is one for Diffuse, one for Specular, one for Normal, etc, yadda. The configs have slots for textures as well, denoted by 'texture = <SlotName>,<TextureName>'

The same way if it only has one texture... KSP does not support multiple materials, so if a mesh has multiple textures on it, they are used in different slots. Put them in the corresponding slots in the config.

Thank you for providing the log file and screenshot. The more info I have the better the chance I can track down whatever is going on... For some reason TexturesUnlimited is not loading for you -- which is what is used to load that particular model. From your log: [EXC 23:38:58.524] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'. [EXC 23:38:58.525] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'. [WRN 23:38:58.544] File 'D:/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/001_ToolbarControl/PluginData/Debug.cfg' does not exist Caused by using an apparently incompatible version that is for KSP 1.3.1 (also from the log): [LOG 23:39:00.980] KSP-AVC -> D:\Steam\steamapps\common\Kerbal Space Program\GameData\000_TexturesUnlimited\TexturesUnlimited.version NAME: TexturesUnlimited URL: http://ksp-avc.cybutek.net/version.php?id=532 DOWNLOAD: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8 GITHUB: NULL VERSION: 1.0.0.8 KSP_VERSION: 1.3.1 KSP_VERSION_MIN: 1.3 KSP_VERSION_MAX: 1.3.1 CompatibleKspVersion: False CompatibleKspVersionMin: True CompatibleKspVersionMax: False CompatibleGitHubVersion: True TLDR: Update your TU version to the latest. And KSPWHeel. And CRP. And SSTU. They are all the 1.3.1 versions which absolutlely will not work with KSP 1.4.5. You can get them all from the SSTU Github -- https://github.com/shadowmage45/SSTULabs/releases Although I might recommend until waiting until I post today/tomorrows release, as it fixes a fairly major bug in the current versions. In fact -- you have a ton of outdated mods in your install, many that I know have updated versions. Might want to do a full mod audit and remove or update any that are still old versions.

Having done exactly this (see KSPWheel in signature)... Sadly some of ^^^ is still necessary. Unity simply does not expose low-level enough access to the PhysX API in order to sufficiently 'fix' the problems in KSPWheel. Squad is facing the same thing -- even if they did write their own custom wheel physics system, they would still be held hostage by and limited to what Unity will allow you to access. Notably there is no way for C# code to access the PhysX sub-step integrations, which would be mandatory for any sufficiently well developed wheel physics simulation. As an aside -- you could try using KSPWheel with the stock-part-conversion patch. The patch itself is WIP and hasn't been updated in many moons, but it still works better than the stock/Unity wheel system in most cases/for most parts -- https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock (requires installing at least KSPWheel, and then the patch set; use of KerbalFoundries is optional for the stock patches)

No worries; I was just concerned that the math was broken for some reason and had some fixing work to do. Glad to hear that is all it was

One major problem with your theoretical example -- the Stock Mk2-inline cockpit texture set is using 'tinting mode'. Thus the expected output with a user input of 1.0f/255 on the slider and a specular input of 0.75f/191i from the texture, would be ~0.75f/~191i. (1.0f * 0.75f = 0.75f) I have set the SSTU tank in the below image to the value of 191 for the specular slider. The MK2 cockpit I set the main(R) recoloring specular slider to 255. Seems to match the MK2 cockpit quite well, which would indicate that the outputs from the shader are exactly as expected for tinting mode.

IDK about your math (edit: actually, your calculations line up with my calculations now that I've re-read what you posted; are you saying that is -not- what is happening in-game?). I've included examples below where I've replaced all variable names with your constants. The output from manual calculation through the code lines up with the quick sample calcs I had done. For those inputs, in standard mode, the output should be 1.0 * 1.0 + (0.75 - 0.5) = 1.25f (or ~319i) (oversaturated, will be clamped to 1.0 by lighting engine) For those inputs, in tinting mode, the output should be 1.0 * 1.0 * 0.75 = 0.75f (or ~192i) All of the extra math regarding the 'm' variable only happens when the (mask.r + mask.g + mask.b) < 1. With a 'full' R or G or B mask for a pixel, the math should be simplified as-per above. The shader code with variable names replaced with constants from the above example. Top sample is for 'standard' mode, bottom example is for 'tinting' mode: //standard mode example fixed4 _MaskColor1 = (0,0,0,1) //this is the 'main' user selected color, corresponds to the 'red' mask fixed4 _MaskColor3 = (0,0,0,0) fixed4 _MaskColor2 = (0,0,0,0) fixed3 mask = (1,0,0) fixed4 spec = (0.75,0.75,0.75,0) //rgb = spec texture input, a = metal(unused in example) // the variable 'm' controls how much of the base texture color is used, and how much comes from the user-selected color // the brighter the colors in the mask, the more that the outputs are controlled by the user colors. Duller (or black) mask, means the outputs are controlled only from the texture samples fixed m = saturate(1 - (1 + 0 + 0));// = 0 fixed3 userSpec = 1 * 1 + 0 * 0 + 0 * 0; // = (1,1,1) fixed3 baseSpec = (0.75,0.75,0.75) * 0;// = (0,0,0) fixed3 detailSpec = ((0.75,0.75,0.75) - (0.5,0.5,0.5)) * (1 - 0);// = (0.25,0.25,0.25) output = saturate((1,1,1) + (0,0,0) + (0.25,0.25,0.25).r; // final output = 1.25,1.25,1.25 //tinting mode example fixed4 _MaskColor1 = (0,0,0,1) //this is the 'main' user selected color, corresponds to the 'red' mask fixed4 _MaskColor3 = (0,0,0,0) fixed4 _MaskColor2 = (0,0,0,0) fixed3 mask = (1,0,0) fixed4 spec = (0.75,0.75,0.75,0) //rgb = spec texture input, a = metal(unused in example) // the variable 'm' controls how much of the base texture color is used, and how much comes from the user-selected color // the brighter the colors in the mask, the more that the outputs are controlled by the user colors. Duller (or black) mask, means the outputs are controlled only from the texture samples fixed m = saturate(1 - (1 + 0 + 0));// = 0 fixed3 userSpec = 1 * 1 + 0 * 0 + 0 * 0; // = (1,1,1) fixed3 baseSpec = (0.75,0.75,0.75) * 0;// = (0,0,0) fixed3 detailSpec = (0.75,0.75,0.75) * (1 - 0);// = (0.75,0.75,0.75) output = saturate((1,1,1) * (0.75,0.75,0.75 + (0,0,0)).r; // final output = 0.75,0.75,0.75

I'm not seeing the problem? The maximum deviation from gray will be +0.5 (white) or -0.5 (black), thus 50%. Your main textures should never be very far from flat gray in portions that are masked for recoloring. That is the problem. Spec input should be 127 for any masked area on the texture. An specular texture input of 192 is basically saying 'add 65 to whatever the user selected specular color is'. (192 - 127 = 65). An specular texture input of 100 is basically saying 'subtract 27 from whatever the user selected specular color is' (100 - 127 = -27)

In tinting mode? It loads the full value from the original texture, and then multiplies by the user selected color/spec/metal values multiplied by the inverse of the mask intensity (so black mask = no effect from user input). In standard/non-tinting mode? The contribution from the original texture is much harder to explain; simply use the gray base textures as intended and it will work (really, the explanation is in the shader source code below). Here is the 'full' source of the PBR-Masked shader: //these values are the values sampled from the textures fixed4 color = tex2D(_MainTex,(IN.uv_MainTex)); fixed3 mask = tex2D(_MaskTex, (IN.uv_MainTex)); fixed4 spec = tex2D(_SpecMap, (IN.uv_MainTex)); fixed3 normal = UnpackNormal(tex2D(_BumpMap, IN.uv_MainTex)); fixed4 ao = tex2D(_AOMap, (IN.uv_MainTex)); fixed4 glow = tex2D(_Emissive, (IN.uv_MainTex)); // the variable 'm' controls how much of the base texture color is used, and how much comes from the user-selected color // the brighter the colors in the mask, the more that the outputs are controlled by the user colors. Duller (or black) mask, means the outputs are controlled only from the texture samples fixed m = saturate(1 - (mask.r + mask.g + mask.b)); // this calculates the user-specified color for this pixel by some dirty shader-swizzled vector math fixed3 userColor = mask.rrr * _MaskColor1.rgb + mask.ggg * _MaskColor2.rgb + mask.bbb * _MaskColor3.rgb; // just like the line above, but for specular fixed3 userSpec = mask.r * _MaskColor1.a + mask.g * _MaskColor2.a + mask.b * _MaskColor3.a; // just like above, but for metallic fixed userMetallic = mask.r * _MaskMetallic.r + mask.g * _MaskMetallic.g + mask.b * _MaskMetallic.b; fixed3 diffuseColor = color.rgb * m; fixed3 baseSpec = spec.rgb * m; fixed baseMetallic = spec.a * m; #if TINTING_MODE fixed3 detailColor = color.rgb * (1 - m); fixed3 detailSpec = spec.rgb * (1 - m); fixed detailMetallic = spec.a * (1 - m); o.Albedo = saturate(userColor * detailColor + diffuseColor); o.Smoothness = saturate(userSpec * detailSpec + baseSpec).r; o.Metallic = saturate(userMetallic * detailMetallic + baseMetallic); #else fixed3 detailColor = (color.rgb - 0.5) * (1 - m); fixed3 detailSpec = (spec.rgb - 0.5) * (1 - m); fixed detailMetallic = (spec.a - 0.5) * (1 - m); o.Albedo = saturate(userColor + diffuseColor + detailColor); o.Smoothness = saturate(userSpec + baseSpec + detailSpec).r; o.Metallic = saturate(userMetallic + baseMetallic + detailMetallic); #endif o.Occlusion = ao.r; o.Normal = normal; o.Emission = glow.rgb * glow.aaa * _EmissiveColor.rgb *_EmissiveColor.aaa + stockEmit(IN.viewDir, normal, _RimColor, _RimFalloff, _TemperatureColor) * _Opacity; o.Alpha = _Opacity; Edit: Trying to think of a good way to explain the masked shaders 'standard' mode.... On non-masked pixels (mask texture is black) -- the original textures are used without change. On masked pixels the standard diffuse/spec/metallic values for the pixel are used as a 'detail texture' applied on top of the user-selected color/spec/metal value. In order to facilitate using the original texture detail for both highlights and shadows, the base value for that texture sample is offset by -0.5. Thus a 1.0 (white) becomes a +0.5, and a 0.0 (black) becomes a -0.5; in this way the data from the original textures can both 'add' and 'subtract' from the user-selected color based on how far from neutral gray (0.5) that pixel is.

Standard mode in masked areas (simplified a bit): Output-RGB = TextureRGB - (127,127,127) + userMaskColorForSection //(it actually adds all THREE user colors... but only one _should_ be used based on the color of the mask for that pixel) Tinting Mode -- uses standard color multiplication (the same thing that happens when you use the _Color property): Output-RGB = TextureRGB * userMaskColorForSection Specular and metallic use the same maths as the diffuse RGB (either offset and add in standard mode, or multiply in tinting mode) Because the system is being used incompletely. Properly setup, using gray-based input textures, the range of 0-255 covers full standard (non HDR) color range.

Yep, can confirm; didn't even look at the alpha before. Specular layer is inverted in the texture compared to the diffuse, at least when I extract the channels using GIMP's Colors->Decompose tool. Looks the same when I simply view the channels of the raw image though... so.... yeah.... quite the 'oops' you found there. The real question is -- does the errant specular map show up like that in-game? Yes... yes it does. (note the non-shiny to shiny transition at the right side of the tank, near the end) (someone should report this to SQUAD so that they might fix it for the 1.5 release...)

What about it? Looks about like a standard texture file to me. (genuinely curious what you spotted in there...)

Which is, IMO, the only proper way to do it. Two separate models? Put them in two separate files.... (sadly, even that would not help solve this problem; stock was never supposed to have mesh-switching, as stated by previous devs multiple times, and thus I did not include any provisions for such features while developing TU)

Interesting... I haven't investigated the stock part-variant system much (undocumented, no source access), so I couldn't say for certain how they have those parts set up. A brief look at the part configs would hint that they are using a single model, and selectively enabling/disabling specific meshes based on the variant (something not supported by TU) -- as the collider mesh is not listed in the variants, I would assume it is always part of the model.mu. Perhaps that transform is 'disabled by default' in the model file, and only enabled specifically by the variant system at runtime? Thus when you use the model 'normally' -- it lacks a collider? Hmm.... yeah.... not sure TU could really support such a setup without branching out into some really ugly areas (model manipulation). I didn't realize stock was doing silly things like that... Will give it some thought though. Might be able to come up with a solution specifically to allow for support of those parts... without branching into dynamic model manipulation.

As long as you select your 'regular colors' -- sure. I cannot speak to what the default for any part are -- but the system is extremely configurable to get nearly any color/shiny/metal-ness look you want.

If you are 'updating' the parts to use TU -- you can remove all of that stock part-variant stuff and use TU's 'KSPTextureSwitch' part-module for texture switching (if even needed). Its a bit more aggressive of a patch, but there really is no way to get both TU + the stock system to play nicely together (mostly because I cannot change the stock code, and it is written with so many assumptions on part/model/material/shader setup).

KSP really is that CPU reliant. Chances are your old GPU was only at ~20% utilization (I have a gtx970, and it doesn't even turn on the fans most of the time when I'm playing KSP). Your new one is probably taking a nap and only being used ~10% of max. The only thing you can do is to limit how much 'CPU using resources' you employ; mostly physics. Fewer parts = lower physics load (all on the CPU). Unfortunately, not supported by KSP (and I don't even think Unity supports GPU physics yet). Nvidia supports PhysX on the GPU, sure, but the game engine and the game have to support it as well. You wouldn't notice much/any improvement. There likely would be one, but so minimal that it would be below human thresholds of perception. Edit: One thing I've not seen tested in regards to KSP is memory timings. More memory only helps if you were running out previously... but faster memory?.... IDK... would love to see some numbers though.

2.79 (work dev), 2.78 (home dev), 2.63 (old laptop that hasn't been updated). All versions work with the plugin that I linked.

Shader does not change the color. What you are likely seeing is the change in shading. Notably, most things will appear closer to neutral color when using PBR, but will also change based on lighting. Good luck Nobody else has used it properly either. Examples for all of it are here: https://github.com/shadowmage45/SSTULabs Basically -- make your diffuse/spec/metal textures flat gray (127,127,127), use a mask texture to specify portions that the user can recolor, and the users' selected color in the GUI will replace they gray in the diff/spec/met. Sorry, I do not offer tech support for Blender.

1.) Take the original part; 2.) sum the LF + O units. 3.) Multiply by 5. (stock LF/O is 5 liters per unit) 4.) Put that value as the 'volume' (as SSTU uses liters) 5.) Profit?!? If that does not work, let me know and I can take a look at the existing original part config and see where the differences may come from.

By using Blender ( https://www.blender.org/download/ ), and the .mu import plugin made by Taniwha ( https://github.com/taniwha/io_object_mu ). That is the only way that I know of. .mu files are a proprietary KSP model format, and you won't likely find support in any other software. Edit: While not to the same extent as viewing the models in Blender... Sarbian's DebugStuff mod will allow you to view model hierarchy and meshes from within KSP --

After comparing your config versus the setups that I've used on the SC-A/B/etc parts, it looks like one important line is missing from the CONTAINER definition that I unfortunately did not spot before: useStaticVolume = true That line tells the VolumeContainer that the volume specified will not change for that CONTAINER block -- otherwise it expects volume updates to come from an external module (e.g. ModularPart, ModularHeatShield, etc). Also note that the volumes specified in VolumeContainer are in liters and not m^3; as such I applied a 1000x multiplier to the volume you had originally specified. The below patch has been tested to work: @PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc] { -RESOURCE,* { } MODULE { name = SSTUVolumeContainer enableContainerEdit = true enableFuelTypeChange = true subtractMass = false subtractCost = false baseContainerIndex = 0 CONTAINER { name = Main Tank volume = 5486.8 useStaticVolume = true tankageVolume = 0 tankageMass = 0 defaultModifier = standard defaultFuelPreset = LFO resource = LiquidFuel resource = LqdHydrogen resource = Oxidizer resource = MonoPropellant resource = Aerozine50 resource = NTO resource = ElectricCharge resource = RocketParts resource = XenonGas resource = Ore modifier = standard } } } Proof:

?? All of the configs that I would create for SSTU already exist. So the time is now -- https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU-PBR/PBRConversions