Manwith Noname

Heh, yeah, I know I can do that...I was just hoping to not have to. Edit: At least...for how ever many textures that need converting. To be clear, I'm not expecting anything to change and when it comes to the crunch I'll probably go through everything again because I'd need to make the other textures. I only really started posting to see if I had interpreted the information in the thread correctly and see if that is what was required. In the small hope that I had read it wrong and that the current masks would be ok. Just putting feels out to see how much work is actually needed.

So close... ...back to the drawing board. Which image? The one from in game or the gimp gallery? I suspected I might not be explaining things very well but I'll try again. The game image was made so I can better see how the RGB channels are mapped. The gimp gallery shows the three channels in isolation and then the complete mask to highlight how reading the channel data works rather than relying on "solid" RGB. Edit: Should probably add this image to as it's the one that directly relates to the imgur album.

Easiest thing for me to do right now would be direct you to the download for the KerbPaint pack which is as far as I got with them before getting annoyed with other KerbPaint problems. Google drive. Anything with 122 at the front was "adapted" to work with the current models at the time. Most have some sort of 3 layer pattern, MK2 and MK3 stuff for example. Heh, when I look at some now I want to redo them as they were done quite a while ago and I have developed better techniques. Some for example I made through pure guess work and trial and error due to not being able to see all the model texture...then I worked out how to reveal it. Edit: Actually, looking at your example above and reading how those need to be defined, I should be able to knock them up quite easily from my gimp files. Problem is, redistributing them since the maintex will contain part of the original diffuse.

Yep, this is exactly what I'm used to with current KSP and KerbPaint, minus the shiny shiny. I can see why you might need extra maps for defining some things (bump, AO) but I don't understand why you need to make a colour mapping mask and then another mask to define where the colour mapping goes. At least that's how I read your information in the other thread. In my playing about with your current configs, I made the second and third layers black and only used the first. I did however quite like the super chrome effect by putting spec and metal full on all of them.

Honestly, you don't know how many times I have wished for an automated conversion process for various things... To give you more of an idea of what the current masks look like... ...which ends up looking like this (for the cones at least)... Given that 1.4 could potentially bin it all I think I'll hold fire on doing anything beside learning how this works. I've got a tax return to do...

Aaaaannnd.....that's enough to make me stop. This will be the third (I think) time they "redesigned" parts and I've had to redo masks. I might faff about a bit with things but I just tried hacking in to your configs and got a whole load of nope. Roughly translated as full specular and metallic, so I feel like I'd probably need to make the other textures required and create fresh configs which...I don't have the time for right now if it's all going down the can when 1.4 comes out. I haven't played KSP for over a year, let alone kept tabs on development. Do we know if 1.4 is far away? *Goes searching*

@beaucoupzero Heh, I would love to help but it appears your images didn't get embedded. I should also add, I will be looking to transition my masks to the following mod going forward... It pretty much does what KerbPaint could do and more (including things I had wished for with KerbPaint like blocking meshes....damn you black flare!...and I think multiple masks per part, which I tried in vein with KerbPaint). It's considerably more complex and not as easy to use but I feel it's the only way forward if anyone wants a system like KerbPaint provided. It's shiny (literally) and new. I'm not suggesting you should move to it right away if you have KerbPaint working mind you since currently stock recolouring is fairly limited with Textures Unlimited at this moment. I am essentially offering these masks to someone who has made good progress on the configs in the hope it will be a reasonably speedy transition. There seems little sense in me doing the work they have already done there and them doing the work I have already done here.

So I've had a bit of a play about and I have a proposition. Short term, would you like some base coat masks (completely red with black cutouts) for all the stock parts so things like windows and end faces don't get "painted". I have pretty much completed the Stock parts (didn't do anything in the engines folder and can't recall what was achieved with the Utility folder but the rest should be there) with my work on KerbPaint. Loading them all up and simply disabling the green and blue channel will provide that. Longer term, I might "re-layer" the masks to work with this system so it has full 3 channel functionality if need be. I've only downloaded and slapped things in my install to see it in game so I'm not au fait with the config structure and inner workings of the mod yet. Going to go and have a play and see if I can get them working as is and what monstrosities I can produce.

I kinda missed this part but if that is at all on the cards, it would be fantastic. Primarily because I have most of the stock parts already masked in some way shape or form and the thought of going through them all again to "re-layer" them fills me with dread, plus I have a workflow built around that method. There are some parts I wanted to revisit and some with only a red base coat but due to KerbPaint having some issues due to lack of maintenance I kind of lost the enthusiasm. I'm not a coder and I'm not even a graphic artist but I can "paint by numbers" in 3 colour channels and fudge MM patches! I have only made the masks I have because I didn't want to see what KerbPaint offered die completely and this seems like the perfect mod to move those on to with all it's bells and whistles on top. I have an idea of how to move forward short term which I will take to @Electrocutor's thread since it is entirely about the config work he has already done more than functions of this mod.

@Electrocutor Thanks for that information. @Shadowmage Another thing it makes very easy is blending. Nose cones and fairings for example I typically applied a base coat and then overlaid in another channel a slowly fading to transparent layer from the tip.. I don't have any screenshots handy to demonstrate it but hopefully you can picture what I mean.

You might do it that way so to repaint the entire texture in a uniform colour in game you only need to adjust one layer, then the other two are used for detail or not at all. There's not really a "proper" way to do it. KerbPaint did it the way I described and you've done it another, neither is right or wrong it just depends on how you approach it. In the image above, the red channel sets a "basecoat" and the green and blue add detail. I only wished to clarify how it functioned to see if I could easily configure my current masks to work with this mod so stock becomes available. So thanks for clarifying.

With regard to how the colour masks work, am I reading it right that they need to be "flat" RGB, as in you are not reading individual channel data for the layer as such? I'm probably not explaining it too well. If, for example, the mask has yellow parts, which would be red 255 and green 255 with blue 0, can this mod recognise that the primary layer is "red" and the secondary layer will place the "green" channel on top of the primary? I have a whole bunch of masks I made for KerbPaint but got slightly demotivated due to various rendering issues like the light flare on landing gear being "painted" or parts with masks not casting shadows. It looks to me like these issues are resolved here.

Minus points for expressing doubt Seeing as you got this far, I'll say this...the shader maps look like they are still there, it's just the configs that are missing. This old post might be useful in bringing certain parts back too. If you look at the config in "complete" KerbPaint download, you can extract the code that will paint the pwings and possibly procedural parts. Screw it...here's the code that's probably missing... Couple this with the procedural wings download in the post I linked and you should hopefully be somewhere near to what you expect. Just copy the text in the spoiler and paste it in to a text file and name it "whateveryouwant.cfg" Edit: Oh....seasons greetings and a belated merry solstice.

I have not played KSP in a while so I have not tested KerbPaint with the latest 1.3.1 (or 2?) build but I was using it with 1.3. Normally, not much changes between minor updates that should cause a plugin to break severely so I would assume it still functions as well as it did (which was with some issues) but parts being purple (or pink) was a problem with configs calling shaders not correctly defined in the dll and maybe using OpenGL or DX11. I can't remember 100% what renderer caused an issue or if it was resolved but I'm fairly sure that was a problem at one point. The answer would be in this thread somewhere no doubt. Anyway, I was working on correcting the configs to work with the problems I am aware of within the dll and they can be found here along with the paint masks. I must stress, it's not what I would call complete. Some only have a base layer and some may well not have a mask at all (mostly engines and parts in utility and science perhaps). Basically as is often the case, life got in the way and motivation wore thin with certain issues I cannot resolve (shadows not rendering for parts with masks). Without properly testing things myself, if you want to check KerbPaint functionality in the latest version of KSP this is what I would do... 1) Download the KerbPaint zip here. 2) Download the latest dll and replace the one from the first link. 3) Delete the KerbPaint.cfg and all the paint masks (all the files that a named XXXXX_Paint). 4) Place the files from my archive above in the appropriate folders. Edit: The astute may notice the files contain a version number and it's not 1.3 but I assure you, many of the masks and configs were created after the 1.3 update, I just kept on naming things 122 because....reasons. Another edit: While I say above it's not complete, it contains a lot more masks relevant to the current release than the original KerbPaint archive. Happy painting.

You are awesome!

14th April 2016. You can just mouse over their name in the OP @Skylon Ah, yes. I can remember encountering that too. I haven't got round to wheels in my ongoing update of the maps. It might be possible to avoid it with what I'm about to ask about.... I wonder if anyone who reads this my be able to throw me a bone? I don't have any 3D modelling software installed and because I'm not a 3D modeller I kinda don't want to KerbPaint has a command that allows a map to target a specific "sub model" (my term, don't know what else to call it). The best way I can try to explain this is with the part I'm primarily concerned about currently, the fairings. The way the part is made, there are multiple textures for different parts of the model. The fairings themselves are obviously procedurally generated but that shouldn't be a problem as I have previously had maps working on the procedural fairings mod. The difference being, I think, the mod had one texture that covered not only the base but the procedurally generated shell too. With the stock fairings, my paint is being applied to the base only so I'm looking for a term to use with the "specific = x" command within Kerbpaint which I'm hoping will only apply the map to the shell itself. Can this term be found if the model was opened in something like Blender? I could probably get the map applied with the deep replace command but it will still apply the paint to the fairing base I suspect....actually...I should go and try that... Edit: Never mind, I solved it. I must have typo'd or something because I'm pretty sure I tried the solution prior to posting.

Oh wow! This looks like some awesome work improving things. Kinda disappointed about the "ticking sun" but it explains why that is used in many games with day night cycles I guess. Interesting.

It needs addressing. There's a whole load of nonsense occurring over something completely unrelated to KSP. Send them home.

Bully 2: Jebediah's Skool Dayz.

Ah well. Can't wait for 1.4

Erm...did this same issue with parts get some love? There's no specific mention of it. Thanks for all the hard work.

@Azimech I was going to get to that eventually. I've had a similar thought about asking a shader wizard nicely if they could take a look. Just to confirm though, shadows are still an issue and you don't need to go to the runway to notice it. In the SPH, they don't cast shadows either...well...the flag decals do. I have also encountered an issue with using "DeepReplace" that needs to be investigated as I'm not sure it happened in the past, though it may have and I just got lucky that I never encountered it. Basically, if you have a part that uses "DeepReplace", everything appears as you would expect (there's another issue with it painting the old style flags but I can live with that as I would disable them anyway) when painting the craft you have created but when you load a saved painted craft, things get a little wonky. Firstly, every part attached to it takes on the "DeepReplaced" parts scheme. Then, if you repaint a "DeepReplace" part, every part attached to it takes on that new paint scheme as you do so. It seems from my testing however, simply hovering over the affected parts and pressing "P" will revert them back to their saved scheme. I tried playing with the "Specific" command but I feel like a blind man trying to hit a bullseye on a dart board. On the shadows, I suspect something has changed with how KSP casts shadows or somehow the shader now overrides the component that does so. I know that something did change with shadows in KSP as Squad have acknowledged a problem with them and I have seen in one of the weekly updates they resolved it (shadows are not solid and have lines of light appearing in them). I would be tempted to see what happens with this fix from Squad as it may negate any need to start messing with KerbPaint. This fix may even have been pushed in to the 1.2.9 pre release but I'm not sure as I have not opted in to it. Edit: Uch, typed this out once then accidently closed the tab. Slight update on the DeepReplace issue. Most parts attached "downstream" do not take on the parents paint when loaded, they do so when you try to repaint that parent. It just so happened that the part I had connected was affected by the command and so the parent paint was applied to "seperate" parts. It seems older parts are a problem in general due to how they were made and textured. Things tend to play much nicer on the newer models.

@gomker The code that creates the shader or the map that determines how the colours are applied? I have not the foggiest clue about the code but it looks neat enough to me. The maps however...they're old and don't fit the current selection of parts in many cases, which I'm hoping to rectify...though I'm not an artist really, just indulging my creative side and hoping to not see this mod die completely through neglect on this side. My current plan is to at least get everything working with a decent base coat that doesn't cover cockpit glass...though I have a tendancy to try adding the 2nd and 3rd layers.... ...you can largely ignore the colour scheme. It's just so I can visualise the RGB layers from the maps. At least if I put together a complete, tidy base coat set, others can add their own flair with the green and blue layers that go on top.

Well, I only know about the configs I've used in the past and how to make the shader maps. The plugin and shader code themselves is well beyond me...though I can spot things that are plain English So, at this stage, what I'm seeing is if the lines starting at 113 in the shader loader source could be changed to this... case "EmissiveBumpSpec": name = "KerbPaint/Emissive/Bumped Specular"; break; ...then we will be back to the configs calling the right shaders to be loaded.....I think. I'd need to check each shader file to be sure but they look good aside from this so far.

Ok, tested and using emissive bump spec no longer causes pink parts but the lights still don't function. I looked at the shaderloader source and it's now calling just straight bumpspec... case "EmissiveBumpSpec": name = "KerbPaint/Bumped Specular"; Is there a problem with the emissive bump spec that means it can't be used? https://github.com/gomker/kerbpaint/blob/master/Unity/kerbpaint_shaders/Assets/EmissiveBumpedSpecular.shader I'll admit, I'm not sure how critical this is. I started just using the Emissive Specular shader and that functions well enough but I always used the bump version in the past.