Manwith Noname

@CalixK It looks like the texture you are using for the metallicglossmap has the alpha channel / spmoothness layer completely white / opaque. I recommend starting out with the alpha channel being a 1:1 copy of the RGB layer. You can tweak and manipulate it later with a combination of the graphics editor you use and the normalisation vector values in the config. The normalisation vectors values only apply to the areas masked to be painted. Any area unpainted needs to be manipulated via the texture values. The main thing to understand about the metallicglossmap is how it is being interpreted by the shader. For the shader being used here, the red channel of the RGB layer determines the metal value applied. Strictly speaking, this should be 1 or 0 but artistically you can use values in between, particularly where materials transition. Rather than just editing the red channel, it is easier and possibly better with regard to block compression (not tested) to have all RGB channel values the same and essentially a greyscale image. Alternatively you could just work in shades of red but I found that too strange to visually process when I tried it out. The alpha channel is used to determine the smoothness and is greyscale. Hope that helps.

@CalixK Alright just to provide what I think will fix it, a quick check leads me to suspect it is the mesh naming due to case sensitivity. So for example you need to use the mesh names Wing_D and Wing_E instead of wing_d and wing_e. A couple of notes about this and some other advice... 1) There are a number of tools out there that it will greatly benefit you to be aware of. a) One is built in to Textures Unlimited itself. If you find the GeneralConfiguration.cfg file there is an entry to enable UV exports. I highly recommend loading the game once with this feature enabled and only whatever models you want to export installed then disabling it. If you have lots of parts mods, it will take a very, very long time to process them all so I'll reiterate, only enable this with the parts you want to export in the GameData folder. You can even remove the majority of the Squad parts folder but for simplicity I would leave that alone. That said, modern CPUs may fair better than the aging Haswell chip I have as a mental reference. I should try this on my newer chips but I digress. The game will look like it pauses at a certain point during loading. It will create a folder in the game install that will contain wireframe UV maps for every part it detects in the game as svg format alongside a text file that details various properties about those parts. You can ascertain the correct mesh names to use via these files. The UV maps can also be useful when imported in to your graphics editor of choice to help understand where the mesh is transposed in the 2D space. I suspect once you play around with this you'll understand it. b) There are some other mods that can be useful in this regard also, like Object Inspector or DebugStuff. As an example... ...this gives you a visual indication of the mesh name and wireframe within the game if you prefer that over exporting the UV maps and text data via TU. c) Blender and the KSP plugin. Kind of a mix of both of the above. You can view the model, the UV map, the textures. I typically load in to Blender when UV maps and textures are all over the place making it difficult to see what is where. While I prefer to do my actual painting and texture authoring within GIMP, Blender has been infinitely useful at times to just paint on a model and see where that appears on a texture. d) Other softwares and utilities may be available that can do the same things. Use whatever you find that suits you best. 2) I don't know how far you are in to this but I would highly recommend not adding your configs and textures to the existing OPT Recolour files and folders. Make a new TU_OPT_Legacy or simlarly named folder that sits alongside the other existing "packs" and store your files there. It's not that I have a problem with you altering or adding to the files but if I update my OPT pack (which I kinda feel it could probably do with a refresh at some point to add more layers on some parts), you'll end up having to transpose your work over again or worse, potentially losing it if you did not have a backup. The sooner you do this, the less laborious it would be. Plus, if you complete covering Legacy parts and want to share it, compatibility will be almost ensured without people having to overwrite the existing OPT pack files.

@NaviG Usually the lack of emissive texture showing is a result of the alpha layer being set for transparency. It can be fixed with a modified copy that set the alpha channel values to 1. @CalixK Probably best to post the config code so I can glance over it either here or via PM. Things that can lead to this off the top of my head are typos, which can sometimes be hard to spot when you've been staring at text for hours and incorrect mesh assignment if you are trying to specify those.

@Sidestrafe2462 Ok, copy and paste the contents of the code block in the spoiler to a normal text file. That file can be named anything and placed anywhere inside GameData but perhaps put it in with the pWings TU configs. This is for ye olde pWings, not B9. This has issues, some of which are apparent in the previous screenshot. Other things to note, this just reuses the existing textures. Things could be better with custom textures that would essentially be a flat single colour with some dirt perhaps but if you play around you'll better see why it never went further than testing with existing textures.

@Sidestrafe2462 Yes...kind of. That is something I experimented with some time ago with limited success. At least with what I was looking to achieve anyway. It got shelved because of a number of rendering issues. I can perhaps look and see if something has changed internally with KSP that fixes these problems but I suspect they might need a shader wizard to jiggle with TU internals.

Re-sourced Resources The base recolour package has been updated with a focus on parts under the resources folder. Now your survey and mining vessels can receive a matching splash of colour. Alongside this there has been some more polishing of other parts including the MK3 fuel tanks. The MK2 and MK3 Expansion packs have also been updated and corrected for changes surrounding the not so new docking ports. As usual, I advise deleting the corresponding existing recolour folders to avoid any potential conflicts.

Some catch up... @yoyotam3 Yeah, fairings are a known issue. Mainly when trying to apply the stock shader. Using a recolour shader should work, with other slight issues. @Baleurion Essentially, yes, to my knowledge there are no publically available packages for the mods you listed. Unfortunately. @Joker58th Thanks for the heads up. Fixed locally, kinda want to do some more to the base pack as the updated MK2 and MK3 expansion packs rely on some changes there. No ETA but Soon™.

Err, well...that was a surprise when logging in... I hope anyone who has downloaded and used the various iterations of recolour mods over the years has found enjoyment from them and am humbled.

@DeliriumTrigger Confirmed. Just downloaded everything and tested it. Aside from launching you can also save and reload the craft in the editor to fix the rendering issue. It seems like something weird with material changes and render layers causing it that gets fixed with a full refresh / reload.

@DeliriumTrigger Putting my money on Depth Mask. I had that in the back of my head in the earlier post as I can recall experiencing issues with it in the past. My recollection was that it broke recolouring though but it kinda fits with what you see. Edit: Actually the more I think about it, it did what you kinda see. Certain viewing angles of where the depth mask was would make the rest of the part invisible. This was back in 2019 though and I may not have had mesh targets on everything...but this is still broken for some reason.

@Akagi You don't necessarily need to open the .mu file. You can often just go by what the textures show you in photoshop or GIMP coupled with the mesh export function of TU. If you want to work in 3D, like Blender, you need to get the KSP blender tool plugin. @DeliriumTrigger I don't mind looking through the module manager cache, even if it's huge (CTRL+F for the win) I am mainly curious to see if we can find anything because even if it cannot be resolved, assuming we find the problem, at least we then know what the problem is.

Yes. Probably the simplest thing to do is install the stock recolour, copy the Recolour_Texture_Sets.cfg and Colour_Presets.cfg files and move them up one level out of the TU_Stock_Recolour folder. Do the same with the Metal_Texture_Sets.cfg file inside TU_Extras. You can now delete both those folders. Then in the TU_Standardised_Switching folder keep the standardised texture sets config but delete the other two configs. You basically want to end up with all the Texture Sets config files, the colour presets (though these are not overly critical) and the placeholder textures. The textures need to remain in the folder path they come in or you need to edit all the file paths in the configs to match wherever you put them. Alright, that's a bit weird and I suspect a conflict of some kind. First thing that comes to mind is another TU config set, typically those that apply a metallic look to a bunch of stuff just through text files and not with textures. It used to be the case that the Texture Switch module would simply override MODEL_SHADER configs but maybe something is amiss. Perhaps the best thing to do is paste the contents of you module manager cache file to somewhere like pastebin and drop a link here and I'll see what I can see with regard to how the part ends up. Procedural Parts should come with its own set of TU configs but you need a specific fork, like this one.

Yes, you just need to insert the line... crew = #autoLOC_20827 ...in to the Mk1-3 Pod PART module of the g_docking.sfs tutorial save state and start it again. Something like this... PART { name = mk1-3pod cid = 4294634394 uid = 3817944765 mid = 4004293368 persistentId = 643397188 launchID = 1 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 symMethod = Radial istg = -1 resPri = 0 dstg = 0 sqor = 0 sepI = -1 sidx = 0 attm = 0 sameVesselCollision = False srfN = , -1 attN = bottom, 4 attN = top, 1 mass = 2.31799984 shielded = False temp = 304.62609337808368 tempExt = 305.11675208761795 tempExtUnexp = 305.11673133775491 staticPressureAtm = 0.98840547378581445 expt = 0.5 state = 0 attached = True autostrutMode = Off rigidAttachment = False flag = Squad/Flags/default rTrf = _default modCost = 0 modMass = 0 moduleVariantName = moduleCargoStackableQuantity = 1 crew = #autoLOC_20827 EVENTS { } ..... You could also edit the persistent.sfs the game created when you tried to play the tutorial and continue but I would suggest starting the tutorial again.

As a result of a discussion elsewhere I performed some checking of files and the replacement docking tutorial save appears to have omitted the crew from the "Kerbal Rescuer" ship. In the original file, Valentina is the assigned crew member. crew = #autoLOC_20827

A brief report from an initial install and run... https://github.com/meirumeiru/InfernalRobotics/blob/develop/Resources/GameData/MagicSmokeIndustries/Parts/Rework_Utility/Probe/Misc/IR_DockingPort/part.cfg MODEL { model = Squad/Parts/Utility/dockingPortJr/model } ...needs changing to... MODEL { model = Squad/Parts/Utility/dockingPortJr/dockingPortJr } Also of note, a few errors and exceptions on the large and small suspension. Looks like all the module indexes need to be incremented by 1 or move the IR Variants module to the end of the file. Edit: Just to say I haven't used anything in anger yet. Noticed the update, installed and ran. Spotted some errors and exceptions as I have them log to screen. Briefly glanced at what they were.