Manwith Noname

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.

Hehe....NOOOOOOO! A clean install of KSP, Module Manager, Textures Unlimited and the TURD configs. Also don't forget to set the reflection mode to anything other than off.

1.8.1 should be fine I've got both a 1.8 and a 1.9 install with just the latest TexturesUnlimited release and the stock recolour, plus module manager. You don't need the source folder, only the 000_TexturesUnlimited folder.

@Arco123 Alright, just to get everybody on the same page, can you make a completely clean install of KSP. Keep your current install as it is just create a new install with no mods, then only add this release of Textures Unlimited... https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.5.10.25 You should be fine using KSP 1.8 (I did test that release there briefly) and you can just copy over the TURD folder. Also don't forget a suitable Module Manager, whatever is in your current install should be fine but to some extent grabbing everything fresh from their download links is probably the best thing to do. Essentially, let's start with something clean and simple, then go from there. This setup "should" work.

Err...ok...I'm a doughnut. I still had my reflections disabled.

@Arco123 Alright, I've just tried something and managed to reproduce this. It's a conflict between TU and KS3P. Strangely, I had previously tested this combination in KSP 1.8 and it was mostly working. Need a bit more investigation...or wait (patiently) for @Shadowmage's currently named TUFX. Edit: Any future readers, see below, I was a doughnut.

@Arco123 Yeah, see my "Another edit" in the post above. I'm convinced you just need to adjust the "Reflection Refresh Mode". Edit: Although, saying that...even with them disabled, I think you should get reflections in the editors. Maybe something else is up.