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

Not an matter of memory, it's the shader replacement hitting things it shouldn't be. Again, this is fixable, I'm just holding off until .23 for tweakables.

Yes, that one, near the top of the file you should see the assembly loader output noting all the mods that are loaded - This will tell me right away if it was properly loaded. Then I can look later down in the file to see both if the module manager overrides are occurring, and then if it is loading the paint masks with parts.

If I could receive a copy of your output log just to make sure the plugin is being properly initialized, that would help me diagnose the issue. In more general news, for those of you awaiting an update, I'm mostly waiting for the .23 release's "Tweakables" feature as being able to associate metadata with parts in editor and have proper load order and instancing is hopefully what will fix most of the pending lurking issues.

It can be shared as stock, paint will be saved with craft when the mod is installed, and lost if the craft is saved while the mod is not installed - Additionally reloading configurations will prevent parts from being painted until the game is relaunched. This is definitively NOT a memory issue. The current version does not check all the shaders in the renderers when it overrides shaders, causing it to occasionally screw up and apply the shader override to all child renderers, including particle effects. I left off on my mod trying to rewrite that section when work caught up to me, so while the particle painting is a definite 'will be fixed' next update, I've been dawdling about unable to work up the motivation do a proper update ontop of work (As it would require a bunch of new masks). If work lets up over the next few weeks I do intend to come back and do a proper update with proper support for science modules and fixes for paint leaks, though at this point I'd have to get past having fun with science to continue B9 support.

This means that the KSP window wasn't drawn, because of Alt-Tab or the monitor was switched off. You'll see allot of that if you alt-tab out

To those of you reporting that the mod has broken, if you could provide the output log from KSP by either link, PM, or post so I can make sure the mod is loading properly, I'm at wits end as to what would be causing this issue. Would need to see either a loading or runtime error in the log to see what's going on

I've not experienced this conflict myself? The way I use the "P" Key shouldn't actually block or be blocked by any other plugin, and given it only works when mousing over a paintable part, how bad is the issue?

At the moment, I don't have any plans to do the unpainted metal parts, like the Lander-can, the metal plates, Xenon Tanks, or parts that have a distinct purposeful coloration, like the Ion-Engines, largely because they are just solid metal and don't have any obvious repaint-able aspect, or repainting. Been busy with life past few days, but I've been working my way through B9 support while trying to solve some of the remaining material selection problems.

Did some digging: The way module gimbals work is by rotating on the horizontal/vertical axis based yaw/pitch inputs respectively. The "Target" rotation at any time (What you see without the response speed) is simply whatever steering the craft is receiving times the gimbalRange. The fun comes in with what exactly the gimbalResponseSpeed is- It is, essentially, a scaling factor for the critical damping accomplished by linearly interpolating towards the target. The way to think of it is that each time step, it takes a certain percentage step towards the Target rotation, allot like how when turning on Fine Controls will slow the input. High values make it more responsive, low values make it less responsive, however unfortunately it is relative to physics deltaTime as opposed to being in some form of measurable degrees-per-second. It is however a scalar, so 2 means it is twice as fast as 1, 0.5 makes it twice as slow, etc, and assuming nominal conditions it should converge in about (1/gimbalResponseTime) Seconds, converging faster when under time warp. The way to think about it is basically a scale for the speed of the gimbal, faster is faster and lower is slower, but that it works much like fine controls. Secondly, gimbalTransformName simply refers to the name of the transform in your part that is actually rotating- Like how for most engines, it's only the exhaust cone that does the rotation, not the engine as a whole. I typed "EngineRoot" only as I didn't have a reference config up at the time.

The fields for ModuleGimbal are: gimbalResponseSpeed - float useGimbalResponseSpeed - bool gimbalRange - float gimbalLock - bool gimbalTransformName - string From what I can tell, gimbalResponseSpeed isn't used anywhere unless useGimbalResponseSpeed is set to true An example would be: MODULE { name = ModuleGimbal gimbalResponseSpeed = 10 useGimbalResponseSpeed = true gimbalRange = 10 gimbalLock = false gimbalTransformName = EngineRoot } Gimbal Lock appears to be if the gimbal starts off as locked or not, though I'm not sure why you would define this in your config for anything other than VTOL's, but it may be useful. Hope this helps!