Manwith Noname

It is part of the base package. You might have a mod that interferes?

I take it you are still using the version from CKAN? Please use the version provided with the recolour download. If that doesn't fix it, you may be experiencing a conflict with other shader mods you have installed. Also of note, might be worth uninstalling a few things. You are installing things that are increasing your load time but ultimately failing to function. As one example, you apparently have the OPT recolour pack installed but not the OPT mod.

Maybe. Which TU are you using? Also make sure the rendering quality preset is good or higher.

@Spartwo Yes, it is technically possible to have both stock and restock models available and maintain the recolour functionality on stock parts unless things have changed. Not sure if anyone ever did it but it needs Restock to be reconfigured so it adds everything as new parts instead of using and replacing existing part names. The blacklist would also need to become a whitelist. It's fairly simple but time consuming as you need to handwrite each part. An example from the Restock wiki... https://github.com/PorktoberRevolution/ReStocked/wiki/Restoring-Stock-Parts

I would look at the MK4 Spaceplane pack as it is another Nertea mod and follows his same methodology. For this part in particular it looks like you need to setup a material section in to your TextureSet that covers the mesh CommonHatchRound. As an example of multi material setup of a Nertea part, see below...

Your best bet for setting the recolour set as default is by find and replace in the standardised config. I've covered this previously in this thread. Basically each texture set should mostly have common suffixes so finding currenttextureset = Default_ and replacing it with currenttextureset = MWNN_Stock_Paint will sort that in a jiffy... well use correct syntax and words, I'm just going from memory. Having it painted in something other than RGB needs the colour block presets changing in the texture set and that really will need a module manager patch. It's something I had considered doing long ago but I avoided it because half the point was for people to colour parts / craft themselves. Edit: Example for finding and replace... https://forum.kerbalspaceprogram.com/topic/174188-112x-textures-unlimited-recolour-depot/?do=findComment&comment=3481141

This is likely due to your graphics settings in game causing the reflection probe to be disabled. You need the reflection refresh mode to be set to something other than "off" but also your overall graphics preset needs to be "good" (I think) or better.

If you are using this to install Textures Unlimited, simply replace the dll with the one that is bundled with the Stock Recolour pack or if necessary, uninstall TU from CKAN and manually install the supplied version. P.S. Sometimes fairings do not behave themselves but the result when that happens in my experience is different from what you have shown and typically happens after a revert to hangar if I recall correctly.

@Phoenics Going to guess from your description of the errors you do not have the base stock recolour pack installed or you are missing a dependency for whatever pack you are trying to use.

No. The included ReadMe file should state the one exception. The dll is taken from the dev branch as it contains an important feature relating to PartVariant integration. Certain parts of the configs do not work correctly without this dll as is stated in the OP and the ReadMe. I am also not aware of what version number should be stated in the version file as the dev branch file is the same as the master last I looked.

@Spartwo Hehe, I don't know what the forum software is doing or if it is my currently inebriated state but that should be the link on the front page?! Is it not redirecting others to the overall GitHub releases page? Edit: Ok, even while...tipsy...I have changed the link to the overall releases pages...that seems weird to me but we should be good!

Kill your foes in style Thanks to the time and dedication of @Spartwo you can now paint BD Armoury parts for added flare in your simulated war games. Link in the opening post. @InterstellarKev Maybe at some point if nobody else does. I don't have the DLC. I've considered getting it but I have not really played KSP in years, I only load it up to make colour packs. @grandmastergoober Unfortunately Restock is not currently paintable. @jebycheek Another unfortunate response, not easily solvable. Needs a shader wizard to fix and as of now, that's not me. Happy coronation weekend everyone. Long live the King!

@JadeOfMaar Well, at least I'm likely not going mad. Thanks, that's good to know.

@daddydante88 The current most effective way is to use the save and load pattern buttons on each part. It would conceivably be possibly to program an "apply to all" sort of logic in to the base TU plugin but it's not something that exists and I suspect it is unlikely to unless I learn C# and a whole load of best practices. An alternative if you wish to start from something other than the red, green and blue bases is to decide on a useful palette, configure colours if required and then point to them in the base texture set config. The base texture set ultimately looks like this once the commented out lines are removed... The main, second and detail colours in the COLORS block can be set to anything configured as a colour preset but you would need to do this prior to loading the game. You can find colour preset files in the base TU folder or in amongst the recolour files for a reference to create new ones or find appropriate existing ones to assign.

Forgive this drunken old fool if this was covered in the comments above and I missed it or I have made some sort of faux pas but...what am I missing?

Just a quick note that the stock recolour pack has been updated (completely delete existing stock packs when updating to prevent conflicts and errors) and a new "pGlass" pack is available for anyone using either or both of the procedural wings mods with the existing recolour pack. The main focus of the stock update was fleshing out the science parts so everything can be painted. The pGlass pack was the result of a conversation a while back and gives an option for creating procedural glass type things from procedural wings. It still has assorted rendering issues but some may find it useful. Note, the "Clear Glass" colour preset does not automatically make any part translucent. It's just there to give a reasonable starting point when this texture set is selected.

@Arqane The quickest and simplest workaround is to open up the following files... 112x_Standardised_Switching.cfg 112x_Standardised_PBRMetallic.cfg 112x_Standardised_Switching.cfg In each of them use CTRL+F to find [mk2DockingPort] then change the :NEEDS section on that line so it reads [TexturesUnlimited&!Restock] It's worth changing the KSP_TEXTURE_SET lines relating to the part also. @CalixK First things first, I have not gone through all the parts in the pack but at first glance this is a great step in the right direction. I can further comment on some things I see but to first answer a previous question about choosing values, the best way I can explain how to understand these is they essentially set the value of the base texture that will result in the slider value of 255 giving a corresponding pixel value of 255 in the shader when rendered in game. This then means that the values along the slider should give a corresponding and representative output. So if a base texture contains an area you want to paint and it is mostly a value of 127/128 when measured inside PS or GIMP, using a value of 0.5 in those normalisation parameters would scale the slider allowing you to get a full range of colours when trying to paint that area. The three values separated by commas represent the areas of a texture covered by each of the colours used in the paint mask. So the first number is the normalisation value for the red area, the second number is for green and the third number is for blue. Strictly speaking, it's the pixel value so areas where red and blue might overlap to composite in to a magenta will be treated twice and results may be undesired. A good starting point for finding suitable values is to use the colour picker tool and look at the values in your image editor (photoshop). You may find it useful to desaturate textures based on luminance and using the values extracted from the resulting greyscale texture. This is what I do to get the colour normalisation value so it maintains all the existing artwork character in terms of "fake shading" for artistic purposes. It maintains the look of the part even if some of the pre existing texture works was really about faking ambient occlusion. This method may not always get you a result you are 100% happy with and sometimes I manipulate or completely recreate the diffuse texture to get something more akin to what I want. The metallic and smoothness values are typically found by educated guessing then trial and error tweaking. To some extent this is an artistic choice I would say. With the in game GUI sliders for these at 255 values, I want the bulk of the painted areas to be close to fully smooth but not necessarily obliterating all detail and conversely not only making a tiny portion of an area completely smooth. I've kinda waffled a bit so I'll wrap that up here and say, I am going to be reworking and adding to my OPT base pack because way back when I converted it to more current standards I did so very quickly and some things have changed in the TU plugin since that were not part of the consideration when I was doing so. Some things will not be drastically different but I mainly notice I did not normalise areas of the texture as I would have been. Before I pass comment on certain aspects of your legacy pack I suppose I should state anything I say is not meant to discourage you or otherwise diminish your efforts, what I have seen is genuinely a good beginning. It's mostly finer details and artistic interpretation that I see that I feel can elevate the pack. Some of them you may have plans to do. Some of them you may have just not noticed. Some of them you may just consider unimportant. All are reasonable positions. I also only bring this up because you said you consider it finished, so I guess I should ask, do you actually consider it finished or do you just consider that "hey, I get everything up and running with colour mapping" ? Trust me, I have been there. The stock project when I first converted it from KerbPaint was very much incomplete and just, "hey, you can muck about with colouring". Even today, I am still working on improving things in the stock pack. As a result of this and a conversation elsewhere I see some parts have been added to the base OPT I need to get covered and noticed the things I previously mentioned that I feel need to be brought more in line with my current methodology in stock.

@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.