Manwith Noname

@Acvila Indeed, you can find the a collection of packs which add TU shaders to Stock and some mods (including the original pWings) here... Edit: Oh also, @jrodriguez, in the spoiler below is an adjusted version of your supplied config. This is to show how the setup should occur to maintain functionality of the leading and trailing edge mesh switching.

This is really good to see, so thumbs up for getting that working but I have some observations and suggestions. 1) If TU isn't installed, the B9 colour system doesn't function. I assume this is a side effect of having to disable them to get TU functioning. Is it not possible, like I suggested in the PM months ago, to enable a switch system so default behaviour is to continue using the B9 system and if a flag is set by a config that wants to apply TU, the old system is disabled? Hmm, scrub this, I have it working now. 2) Remove the transform specified in the texture switch module. Right now, due to this, everything breaks when you try to switch the mesh for the leading and trailing edges. If you write the configs differently and make appropriate texture sets, then apply them in the right switcher, this edge mesh switch still functions... 3) Don't force a hard dependency on Procedural Parts. By all means, supply a patch that creates a set using textures from there if they are present (using the NEEDS field) but it would be preferable if a standalone B9 Proc Wings could exist. 4) Following on from 3, as can be seen in the pictures, make a set of default patches that look like B9 and can be added to easily through using FOR patching by others. I know what this involves, I've spent a bit of time looking through the default art assets and can see where the problems lie but it's achievable with a bit of time. I can help with this if you're interested, obviously I've fixed some things myself and half setup a means of having B9 alike recolour in these shaders. Though, I have other projects which should be the primary focus right now. It is already done...

@Shadowmage

@Shadowmage I'll get on it as soon as I can and report back.

@Shadowmage Maybe? It's late, I'm a bit brain dead. I must admit, I butchered the part massively but I do quite like how it functions. Everything works independently so B9 handles just the model changes and the standard TU texture switch module deals with the usual texture set side of things. This is essentially how I would like things to work, switching models keeps texture sets applied, switching texture sets has no effect on the meshes being displayed. I fixed one issue, that was straight forward, I just forgot to add the fairing transforms to the B9 switcher. I'm reasonably sure I've seen posts in the past about engine plumes in the editors but I'm not entirely sure what caused them. There could also potentially be issues with using a 1.8 plugin on 1.9. I just want to test the concept and see how it functioned. This is the config, obviously you won't be able to use it due to missing textures and what not but it might give more of an idea of how I set it up. Edit: I think I understand your suggestion. Essentially the extra info block and part variant modules would allow for the material control to display in the GUI but it would all be tied to a particular variant? This would of course work, I just like the ability to switch between texture sets on specific meshes so you can mix and match say, a straight metallic set on some meshes with recolour on others. Basically, I like that flexibility but to some extent it's not essential. What bothers me the most is being limited to 3 user definable colours / materials when a part could be broken down to allow more. Another edit: Haha, might need to switch out colliders too...

The Solution!...well, maybe? Every time I think of variants, I think of Aliens. We should nuke the thing from orbit, it's the only way to be sure. I've tried manipulating the module in cunning ways but all I managed to do was break the editor. So, the idea that's been kicking around my head for a long time is to completely replace the stock part variant system with something else that I know plays nice with TU. Ladies and gentlemen, I present to you, the "variants begone" part switcher...sponsored by B9 Part Switch. *drumroll* So, the proof of concept works it seems. Sadly, it comes with one or two issues right now. I feel like this should work with a bit more time digging out how to set up the B9 part switch module. Then again, I might find that this is also an area that B9 just will not solve. Another drawback if I can get it all to work is it becomes a dependency but I kinda feel that a lot of people will have it installed anyway due to other mods incorporating it. I might see how Firespitter mesh switch functions in this area too but not tonight I suspect. Thoughts and suggestions on this are welcome. I've had my fun for the evening goofing around. Normal business may resume.

The Problem with Variants Alright, some people might be wondering "I don't get it, what's the problem? You've got it all mapped out and it's working". Allow my eccentric rocket building enthusiast friend (definitely not me) to demonstrate more visually. They decided they quite liked the general scheme of the engine as it was but wanted to spruce it up a little. They made the red layer steel metallic and knocked up a close approximation of the orange paint with a bit of shine in the green layer. Not quite content with the original ball thingamie, they make it a nice shiny gloss white. Overall, they're quite pleased with how it turned out despite the engine block having to follow suit with the main base. Now, this is all fine, in isolation but when it comes to painting rockets, our eccentric rocket building enthusiast has visions of a grand design. Hmm, ok, their taste isn't fantastic but this just will not do, will it? You see, this little sneaky bugger of a shroud is locked to the same colour palette of the engine and doesn't necessarily fit with the scheme they wanted on the rest of the rocket and you know they couldn't possibly commit similar crimes against rocketry design to the engine. Right? This is just a bit of fun to set up for the next post. More news at eleven. It gets better, I promise.

Talking Stock So, after splurging inner thoughts and reasons for why some stuff will always remain secret until finalised, given this is a development thread I figure it might be an idea to give some insight in to current progress on covering 1.9 parts. Here we can see the Skipper engine in its not so natural habitat of undergoing recolour implementation (I suddenly have a feeling I might have done that joke before...apologies). No, it doesn't look too special right now because the first order of the day is to lay out the colour mapping and finalise it before working on the metallicglossmap and potential diffuse texture adjustments. The engine currently uses PartVariants (shown as the three placed engines) and consists of 4 main meshes. Mount1, the outer shrouding seen on the right. Mount2, the ring plate and some pipe extensions in the middle. Engine, the main manifolds and block which appears in all 3 variants. Right now, I'm still undecided on what to cover with the "green layer". The 4th mesh is the engine bell, which while using the stock part variant system will remain unmasked. Technically, it could be painted but limitation of the stock variant system mean colours (or better put, materials) across meshes start coming in to conflict at some point. I've had an idea kicking around for some time now on how I might be able to work around this but I'm hoping to follow up on this post with another covering that at some point. It might come tonight, it might come next week depending on how quickly I can get it up and running around other commitments...assuming it works of course because right now, it's just an untested idea.

You never need to apologise for not being on the internet. The "real world" is far more important. This is an answer but perhaps not the answer I was looking for. I wonder if you have actually seen it in a way. I didn't really want to give out clues but you mention something here which is on the right track. This also highlights why I thought this would be fun, it's curious how people pick up on different things.

Hold up...wait a minute... This was mentioned in passing during a conversation and, well... Light sources now show up at full spec it seems. Unity? KSP? TU? or all of the above?! Edit: I'm suspecting the recent camera changes.

Ok, small wall of text incoming. Your question is fine but coupled with some other recent posts I feel it might be worth clarifying a couple of things. I want every part available in KSP, including mods, to use TexturesUnlimited and have recolour. No exceptions. I want them all to play nicely with one another. No exceptions. Is this possible? Yes, however, it's going to take a huge amount of work. A certain mod that crushed my soul when it appeared is likely in the order of 1000 - 2000 hours work, maybe more. I estimate this because I've already covered the same parts over the course of approximately 6 years, on and off. A single part can take anything from 30 minutes to 5+ hours depending on complexity and how suitable the existing art assets are. I'll admit, some of that time is down to my own indecision of how to lay things out and general mulling over of hurdles I encounter. When I think of how long I have spent on Stock alone and consider that it is still a way off being perfect... Now, covering stock parts is fairly straight forward. Squad are open to people modding their game and they have a set of guidelines on what is and isn't allowed. Follow those and all should be fine and dandy. When it comes to altering other mods, I take a different approach and have done since 2014 when making masks for KerbPaint. I start working on it and when it reaches a state where there is something reasonable to show, I contact the mod author. I ask them if they have any objections to this becoming publicly available and eventually offer them the option of a preview download to inspect if they wish. If the mod author is absent, I revert to their license after some months. To date, I have been able to find agreeable terms with mod authors I have contacted and in only one case am I reverting to the license due to an author being absent, while in another, I'm effectively extending permissions granted from 5 or 6 years ago as the mod really hasn't changed but the license is also permissible. Having permission for one mod from an author however is not permission for another mod of theirs as far as I am concerned unless it was specifically proposed in the original enquiry, so the process is repeated where this isn't the case. I also don't generally announce ongoing projects for two reasons: 1) The author might object and so the work never gets released. It's not fair on anyone for me to post preview pics or make comments until permission has been received. 2) My own sanity. I've made starts on a couple of things which I've vaguely hinted at in the past only to drop the project for the foreseeable future due to a number of reasons. Generally, I have a number of projects on the go at once. It relieves the frustration to jump between them when I find problems on a particular part but have motivation and time to do conversions, while also giving the brain time to chew over how to solve it. As of now, I have three undisclosed projects on the go, two of which I have permission to upload but there are some things I want to do before that happens, which comes back to the time and motivation just mentioned. This also kinda leads to, sometimes, when you've been spending all your free time working on something, for a game you don't really play because you want all these wonderful toys before you do, you just want to take a break and actually play something else or generally enjoy other things in life. To end this comment where I started, I also appreciate that realistically what I want will never become a reality. It's going to take more than just little ol' me slogging away at least. I hope people can read this and understand why some things don't exist or get mentioned right now, however disappointing that might be. To lighten the mood and relieve some of my own frustrations at least, let's play a little game called "spot the odd one out".

Those artefacts are "normal" when HDR is enabled. I've noticed they tend to emanate from the horizon, particularly where water is involved. If I look to the horizon where land meets the sky, they rarely occur. I've also noticed that the transparency issue with stock part shaders and HDR seems to produce negative images...

New toys! Does the old AO suffer from the same banding due to the far clip? That might be reason to consider having both options if not.

While I personally think the HDR disco lights are quite amazing (no really, I've just spent a good 20-30 minutes moving the camera around getting them to popup for entertainment), it might be worth adding more importance to that as a warning for people with epilepsy. When I wasn't so distracted by the multicolourstroboscopes, I started playing with actual settings... I think I'm likely to lose entire weeks tweaking this.

As previously mentioned, these features are present in 99% of other games. Go look at the KSP2 previews and you'll find the same effects set to eleven. I would agree, by default, they might be "over the top" but it's configurable and much like I had with KS3P, I'll be making my own subtle configs. Small amounts of AO and Bloom really do make a huge difference, adding depth and impact to the scene without the eye bleeding. At least here, you can customise everything to your liking whereas in most other games, these settings will be either on or off to the developers tastes. Edit: Here, this menu is likely what you are missing... Downloaded, installed, disabled some things, tweaked 3 or four sliders....no more vaseline or overgrown "shadows". ;D @Shadowmage Are there plans to introduce TAA or other post process anti aliasing?

Haha, yeah, that caught me out in the last page or two when trying to fault find your issue. I'll add a note in the OP so it's clear.

Indeed, you're not alone. Every time a new part appears using it I die a little inside. I wouldn't worry about it too much, I just figured I'd ask the question before I get to the point with them where I'm making the masks and planning it all out. Well, I've configured things the simple way for now but haven't plotted out the textures. I've also had an idea knocking around in my head for nearly a year on how I can most likely get around this but I've never tested it out. I might try it and weigh up the pros and cons. I suspect you're thinking in regards to a single mesh object? I have essentially been doing this through material blocks where more than one mesh exists and in most cases, it's been fine following the main three colours / materials simply due to the general design of the part and how I have wanted things to "flow".

Yeah, I thought that might be the case, it's good to dismantle everything for learning purposes. I just thought I'd let you know that there is a way to reduce the amount of work and that is the intended purpose of certain parts within the recolour pack. Essentially, it's modular but provided in a single download for convenience. While I'm here... @Shadowmage Is there a way I haven't found that enables a material block to display as separate colour controls within the GUI? In the past, I've worked around this with multiple texture switch modules but on the new engines, I kinda have to use part variants due to the game object switching and ideally, I'd like to have more than three "colour" options. I tried using multiple part variant switchers so one would handle only the object changes and the other would flick between shaders and texture sets but this broke the game, haha. Well, it loaded but the editor scenes didn't like it one bit.

@Arco123 Is it a video or a write up? Is this something you do regularly or a one off? By all means, you can post it here and I can link to it in the OP if it's something that will be more generally useful. Like wise, if you have a thread or place you post guides and tutorials, you can stick it there and provide a link.

I started but shelved it to come back to... There was bigger fish to fry at the time.

Ok, this has kinda been covered above but I'll explain more specifically in relation to these packs. The colour mask dictates where user control can occur, where the colour mask is black, the resulting look for the part is taken from the "metallicglossmap". Every part (well mostly) has it's own texture for this (in varying states of completion). So, for the MK1 cockpits, I have a greyscale texture which is specifically defining how reflective and how metallic an area of a part is where recolouring can not be applied. The "shiny" set uses a plain white texture placeholder and then has metal and smoothness values defined in the configs to reduce them to a percentage of "1". The placeholders exist so that every set can have a texture slot defined for a number of reasons. Essentially, yes, this is normal. If you want to change this, go in to the "Extras" folder and open the metallic texturesets config. You'll see the values mentioned and you can change them to how you see fit. The metallic set is intended for people who want to make a config set with dedicated metallicgloss textures, or even replacement MainTex, BumpMap... if someone wanted to go that far. Its purpose is to ease creation of more options, plus, it was the "thing" everyone became familiar with when TexturesUnlimited appeared. Without that config, people tend to ask "where is the shiny set?". While my main motivation was bringing over and upgrading my old KerbPaint masks to function in TU, what I also want is the option to use other sets that I was hoping someone else would jump on. It was enough work converting and tidying up the KerbPaint masks (because the format was slightly different) and once Stock came up to a certain standard and usability, inevitably I look at all the other mods I would want to play with and think "They need a lick of paint too". I'll get the screenshot you asked for and edit it to the end of this post shortly. Edit: Oooh, for giggles, have some "hot" stuff... Though it's kinda hard to see the glass reflections there. Another edit: The screenshot you were looking for...

For KSP 1.7.x releases of TexturesUnlimited, I'm reasonably sure you don't need this part. Things changed and TU defers to using stock controls. Can I ask, how far do you intend to go and do you ever imagine you would want to release this? I ask because I've structured the recolour pack a specific way to reduce the amount of work others might need to do to add more sets and also allow every pack to play nice with each other. I'm not saying you have to but this is ultimately the reason for TURD being structured the way it is. Without some sort of "standardisation", everyone will be limited to just choosing a single pack. With standardisation, everyone can focus on making their own pack as an addon. The "Standardised Switching", was always intended to become its own download for this purpose. Essentially, you don't need to apply the stock setups because that's already done. You can take the metallic config or the recolour config and with a bit of renaming plus find and replace, you have an entire template to go through and all that needs to happen is pointing texture paths to your own.

Yeah, crack on and let us know what you find with your particular mod set. Part of me does suspect that you may find it all works after chucking everything back in and the issue was primarily down to some update you may have missed. Specifically, the most recent version of TU does address a similar problem with fairings you brought up later (them being totally black). It may of course break again when a particular mod or config goes back in but at least when that happens, it narrows down the search field for clues as to how it might be fixed. I might have a bit of time later to try and reproduce things if you manage to break it again but I'm out helping a mate with his house move. Trying to solve the mysteries of the previous owners DIY "improvements".

@Arco123 Sure, anything you find out will be helpful. I've just been trying to break things my end to no avail, threw in KS3P, Planetshine, Texture Replacer with WindowShine. Actually, WindowShine broke things but not in the way we're trying to find, quite the opposite in fact. I'm off to bed.

@Arco123 This is what I'm trying to find out. If a clean KSP and just the required mods works, then we can start narrowing down potential mod conflicts. If it doesn't work, then we need to start looking at why that is. It's just a process of elimination.