Texel

Go ahead.

@Azimech While I intend to keep the temperature colors for Kerbpaint going forward, it's not too bad to make something hide them. The property exposed is _TemperatureColor, if you use Renderer.PropertyBlock you can override it on a per-renderer basis, as a snippet: var r = GetComponent<Renderer>(); // Get the renderer var pb = new MaterialPropertyBlock(); // Create a property block pb.SetColor("_TemperatureColor",Color.black); // Override Temperature Color in our block r.SetPropertyBlock(pb); // Apply the block That'll kill the temperature colors for anything. I don't know if KSP uses PropertyBlocks internally, or if they instance materials, if it turns out they do use them internally just get the property block already in use and update it. @linuxgurugamer Given I've now made a tool which can update the shaders, it seems best to include a package with the source that lets people update the shaders as KSP updates. Especially since they are not using Unity5's special material setups yet, I suspect 1.1.x or 1.2 will require another shader update.

So I have the shaders compiling and made a tool that goes alongside the KSP Part tools to export up-to-date shaders whenever squad updates them. I'll need to do some work to actually get the new shader format running with the mod, but before that, has anyone figured out why the UI doesn't seem to be working with the new KSP? Did the recompiled one posted by @linuxgurugamer resolve that?

So, licensing wise, I actually had a folder of shader sources I'd indented to distribute with the mod, but because the Part Tools shader sources are 'presumably' property of squad I shouldn't be redistributing modified copies of, I only included the precompiled shaders in the old mod. Whelp, looking at the sources now seeing how bad it would be to update them, turns out to save space (as compiled shaders can be huge) I had "#pragma only_renderers opengl d3d9" Whoops. So essentially, the precompiled shaders appear fine, they are missing some of the new stuff that had been added since (Temperature Color, and Burn Color, for the reentry emissive effects). I'm at a weird crossroads on how to update the mod though, since I can't distribute sources of Squad's shaders to others to be maintainable and I don't want to leave the community hanging dry for years again. Spending a bit of time seeing how bad it would be to make an add-on for PartTools that patches the shaders.

UnityEngine.Material *isn't* obsolete, as such; They removed UnityEngine.Material's string constructor; The section in particular that is going to cause an issue is: // Get the material var mat = GetComponentInChildren<MeshRenderer>().material; // Get the first material we find, hope it's right :D var shaderString = KSP.IO.File.ReadAllText<KerbPaint>(Shader, null); paintShader = mat.shader = new Material(shaderString).shader;/*UnityEngine.Shader.Find(Shader);*/ mat.SetTexture("_Mask", ProcessTexture(Texture)); ManagedMats = new[] { mat }; Unity should still be able to load the precompiled shaders, which are distributed in the zip under the KerbPaint/Shaders folder, as far as I am aware the Material Constructor was only obsoleted as it no longer compiles shaders. If that fails. Though I'd previously not released this source (as I was using these techniques for some of my work at the time), if your going to make new shaders or update to the new material system, you'll need the code for actually applying the recoloring logic: Again, it shouldn't be a big deal to apply this into the newer materials, but I'd need shader sources for KSP, and the old shaders were based on PartTools which I don't believe has been updated (If it has, please point this out so I can update)

If KSP uses Unity's 5's stock material shaders, it wouldn't be a particularly bad rewrite, do you have any info on the new shaders?

Props to Selfish Meme and Manwith Noname for continuing this, I updated the topmost post to hopefully let you cleanup the download confusion and released the license.

Great to hear! I am now required to include text on the usage terms, if you could PM me with links to your configurations I'll write up a license agreement to have you proof, list you as a contributor and get a fresh KerbPaint out.

Going to try to avoid having to recompile the mod if I can help it, at the moment I'm really just looking for updated .cfg's, anyone whose made updated/improved textures (I know there are some issues with the current release, for instance) for inclusion in the main download, as I'm going to need to update it to comply to the new terms and supply an updated version of ModuleManager. I know serveral people made additional mod support packs/cfg tweaks, but as I believe Manwith Noname put it, the licensing is weird with respect to distributing textures derived from KSP. Ideally what I'd like to see, is including a subfolder with appropriate cfg's and license for any masks/part configs in an addon, in addition to if somebody has completed stock support I'd be particularly eager to swap out the stock configs and credit contributors- That said, there are quite a few addon downloads in this thread, none with the kind of licenses I'd need to distribute alongside the mod, nor do I have the time or resources to download every additional mod and confirm compatibility (B9 support is what killed me in the first place)

Can anyone confirm for me if this is working with version 0.25? If so, I'd be willing to repackage it with an updated module manager and if anyone has a more complete/functional cfg for it to ship with, as the download needs to be updated to conform to the license inclusion rule changes in my absence.

Shocked to see there is still interest in this, but to spell out some of the issues with the mod and address Espresso's issues: First off, Kerbpaint worked by trying to find the associated renderers for a part, which atleast given the time of it's writing, wasn't particularly trivial. Internally, Kerbal Space Program didn't seem to be tracking what renderer objects were associated to certain parts, which is reflected in the highlighting behaviour- when a part was highlit by KSP, the game either lights only the direct renderer on the part object (for small parts, fuel storage, etc, this is fine) but doesn't properly highlight more complex, multiple renderer parts such as cargo bays and landing gears. For occasions when it does highlight them, it highlights everything hierarchically below the part in question, such as for selecting and dragging whole groups of parts. The short of this was, ultimately, I couldn't isolate on a per-part basis what was actually being colored. This lead to a number of issues, most noticably paint being inconsistent based on load order, landing gears or other non-colorable parts being colorable if child to a recursively colorable part, and a generally unpleasant experience with cruxes of unavoidable issues (Like particle effects having shaders swapped conditionally, symmetry breaks on docked ships, etc). Until that is resolved I'm probably not going to be updating Kerbpaint, as it wouldn't be possible to resolve it in a featurecomplete way. That said, addressing Espresso's points: -Ability to create a preset, to quickly apply colours to parts and a custom colour bar. Doable, but presets were rather dodgy as a whole. Quality recoloring is actually a Set Hue, Multiply Value, Shift Saturation, so the reference colors provided in presets were entirely irrespective of what they would actually do (Hence why, for instance, orange fueltanks recolour in dodgy ways, that still look good, but obviously not the implied result) -A button (Or shortcut) to paint all parts, and a reset all button. Presumably fairly easy. Under the hood, it's just module manager adding a component to parts that KerbPaint then looks for. Only difficulty I can think of is making sure that you only grab parts from a given vessel. -Not the ability to paint in flight (Unless with a part? Makes it more realistic) Again, what dictates the paint is strictly the component on the part, it's been a while since I've looked but that should be fairly straightfoward. -The ability to automatically make mod parts paintable, but only if it's possible. I'm not sure how to do this one. Kerbpaint is a component on a part, as such, you'd need some way of adding it to all parts, which may have unintended effects. Additionally without paint masks, the recoloring wouldn't be particularly meaningful, at that point your almost better off just multiplying the color on an object, which can be done much more easily (I think material.color works with KSP's default shaders, for example) -Make sure all parts painted the same colour are painted the same colour. (Possibly wipe the texture where paint is to be applied before it is painted, but if unpainted, restore it) The recoloring method is one I developed with my professional work, based on Setting Hue, Multiplying Value, and Shifting Saturation. It's main advantage is, it always looks pretty good and provides quality recoloring without banding or artefacting, or the typical darkening of multiplicative methods (It's close to how the color blend in photoshop works) - The caveat to this, is you can't set the color of a thing (Would end up with just a big, flat colored texture then), and there ultimately is not a good way around this. Ideally, if a feature like Kerbpaint were integrated into the base game, it would do all major coloring and base textures would be authored accordingly. If anyone is seriously interested in continuing the project, the shader sources were not included in KerbPaint, and while I'm doubtful as to how much the community would understand them, I'll happily provide the old sources and answer questions to my implementation on request.

They are renamed .png files - KSP automatically loads png files, so the extension was changed to make them load-on-demand.

Kerbpaint adjusts colors in HSV, but doesn't actually set any colors in HSV. To set a color in an HSV-space be simply apply a flat tone to the entire object. Instead KerbPaint sets the hue, multiplies the value, and adds or subtracts from the saturation by the set amounts. This means, given two textures with the exact same KerbPaint setting, the only way they would end up looking identical is if they are equally saturated. Basically, Kerppaint is closer to a photoshop filter than defining a target HSV, it does a recolor process but does not readily produce exact results. I did include a copy and paste selected values option, it wouldn't be to hard to make a subassembly that contains your favorite settings to quickly apply to other craft.

Very much so, if you'd drop me a private message

No, It's not dead. I'm just behind on my actual work and haven't had a chance to investigate 0.23 - The update process is going to require a fair bit of code to fix the looming thrust-shader replacement issue, then a bit more work with respect to actually making paint masks for the new parts (unless somebody wishes to volunteer paint masks for all the science).