Idea

[Recognize-Me-]

Would there be a way to add something like dust or scratches to things that have been on different planets for extended periods of time? Like if you put a rover on Duna and leave it there for like 3 months (kerbal time) then it would start to develop a thin layer of red dust and maybe a few scratches. I would think you would be able to do it pretty easily. Just a thought

[Chezburgar7300]

That's a pretty sweet idea. If I knew how to I would . Shouldn't this be in general add-on affairs though?

[Boomerang]

http://xkcd.com/1425/

The idea is fine, but unless you've got a decent notion of how such a thing might be implemented, you're better off not implying that it would be simple to do. It's a good way to rub people the wrong way, including the people who might take a look at ideas like this and try their hand at it.

[artwhaley]

Hmmmm. Cool idea, but since it doesn't really add to gameplay, I'm not sure if it would be worth what it would take....

My idea for how to pull it off, and this is shooting from the hip, but you could look at how Kerbpaint replaces the KSP-Unity shaders to add an additional color layer. Now, they're probably taking advantage of the fact that the default Unity shaders have a color modifier on the diffuse channel, but KSP hides that, so Kerbpaint just has to add it back in. But it IS an example that proves you can replace the shader.

Unity seems to have provisions for combining textures, so you could make a 2048X512 texture with 4 squares, each with a different level of damage, and overlay the correct one over the diffuse and specular channels of the part after a certain amount of time landed on a body.

The other trick is that part -your plugin would have to record how much time each part has spent on a planet... that's not info that is available in stock... and parts that you've left on a planet are sort of forgotten by the engine when they're outside 2.4km. So you have to find a way to file away the time a part lands so you can check it the next time it gets loaded to see what level of damage it should show.

http://docs.unity3d.com/Manual/SL-SetTexture.html might get you started. It's seems like a fairly involved bit of coding plus a decent bit of memory overhead, between the textures, the combining operations, the additional draw calls (as this would look best if it used spec and normal layers, which would add draw calls to parts that didn't already have them), and tracking information for parts outside physics range, for no change in gameplay to me... but someone who's actually played with Unity Shaders Labs might not find it easy enough to be worth it.

Art

Edited December 30, 2014 by artwhaley

[Recognize-Me-]

http://xkcd.com/1425/

The idea is fine, but unless you've got a decent notion of how such a thing might be implemented, you're better off not implying that it would be simple to do. It's a good way to rub people the wrong way, including the people who might take a look at ideas like this and try their hand at it.

So the fact that I personally don't know how to do it but think it would be easy to implement would rub someone the wrong way? If anyone takes offense to me stating my opinion on how easy/hard it would be to do something that I suggested then they can move on to the next post. I wouldn't know the first place to start to implement this but the idea is very simple so I personally think it would be easy to do.

[Camacha]

I wouldn't know the first place to start to implement this but the idea is very simple so I personally think it would be easy to do.

I know a little bit about making things for games and it is not as easy as you purport it to be. The simplest ideas can be unbearably hard to do. I think this one should be doable with some work, but it is not a matter of slapping something together in a few hours for sure. And yes, it somewhat irks if someone suggests so readily something is easy without knowing the first bit about it

[Thesonicgalaxy]

So the fact that I personally don't know how to do it but think it would be easy to implement would rub someone the wrong way? If anyone takes offense to me stating my opinion on how easy/hard it would be to do something that I suggested then they can move on to the next post. I wouldn't know the first place to start to implement this but the idea is very simple so I personally think it would be easy to do.

It's rubs people wrong because they put a lot of effort into their hard mods, and people who haven't done it just saying it would be very easy to implement gets them angry. It's not as easy as you think it sounds.

[Greys]

So the fact that I personally don't know how to do it but think it would be easy to implement would rub someone the wrong way? If anyone takes offense to me stating my opinion on how easy/hard it would be to do something that I suggested then they can move on to the next post. I wouldn't know the first place to start to implement this but the idea is very simple so I personally think it would be easy to do.

It's not thinking that it would be easy that can be offensive, but that you're trying to look like you're suggesting something, btw suggestions don't go in this board; when really what you mean is "Someone make this for me". The general rule in communities like this is that if you want something done you're going to have to do most of the job yourself, and if you're not willing or interested in doing it, it's best you keep your ideas to yourself.

Making a catchall procedural system would be as close to impossible as you need to get before abandoning ship; but it'd be relatively simple to implement a system that reveals a dust or damage mask based on conditions; that's essentially what emissive animations do. The problem is that every part that exists would need to be enhanced to contain a custom damage/dust mask, and less significantly the KSP shaders would need to be expanded to match. This is not something that a single mod could do completely on it's own, part packs like B9 and KW would need to update to support it. This runs into the issue that you need to convince artists that it's worth their time to do more work before your mod is popular yet, when there's little benefit from them doing so, and significant side effects; and conversely if the mod does take off, any mod that isn't updated suddenly doesn't fit in.

This is the kind of feature that only Squad has the clout to implement because anybody else has to deal with the politics of getting the community to adopt, and Squad would undoubtedly go for the procedural system, and would do a bad job of it, permanently downgrading the visual fidelity of the game. (until somebody makes a mod to disable it)

[Agathorn]

I wouldn't know the first place to start to implement this but the idea is very simple so I personally think it would be easy to do.

By definition if something is easy then you should be able to figure out how to do it.

What "rubs" people the wrong way is people saying so and so is easy which belittles the amount of time, effort, and learning, they have spent to figure out how to do things. It seems I most often hear the "It should be easy" statement the most from the people with the least bit of clue as to how easy or hard something truly is.

It took you how many posts? 4? 5? to get a part pointing the right way in Unity. I assure you that building a robust realistic paint weathering system is infinitely more difficult in comparison.

[Gaalidas]

You could perhaps make use of some of those plugins that attempt to track time passage for the use of using up or generating resources for vessels that are currently unloaded by the engine. In fact, I remember that in the past there have been parts which would expand/retract and others that simply had a visual indicator to show their current filled status. If a system like that could be implemented where the resource represents the time it takes for the specific part to get fully scratched up according to this mod, and the visual indicator is the overlay applied in similar fashion to the shader modifying process of KerbPaint, then you might be able to get the desired effect. So, basically, the part would have a resource (call it "space-time sandpaper") and a module that slowly drains this resource based on the current conditions defined in a config node that corresponds to either a planetary body or empty space, and even different regions on planets with biomes could be defined. For certain percentages of this resource drain, the shader would apply a different mask which would produce these scratches/dust layers that again could be defined by the configuration, in an image likely. Upon re-loading that craft and using it another module, which only runs when the vessel is active, will slowly (more slowly that the drain, likely) regenerate this resource which would cause the resource-tracking module to reverse the state of the mask, stopping just short of a full recovery until either the craft is manually cleaned/repaired (maybe an EVA kerbal could perform these actions) or the biome/configured body was changed which would cause rapid recovery of this resource, followed by a subtle switch to the new mask.

So, in the end, not exactly simple, but also not exactly impossible. Again, however, making a mask work for all the supported parts without having to re-mask every textured part individually for each configured environment could be the near-impossible part. You'd need to be extremely subtle with the scratches/dust so that you could apply the mask to the entire craft without making it appear awkward. Also, you'd need to make sure you aren't blocking transparency, emissive maps, or any other effects that the base game makes use of. One of the issues with KerbPaint is that you have to use different shaders depending on what shaders the part already makes use of or you'll get some odd results. For parts with multiple objects that are skinned individually, you needed to tell the plugin to do a forced override which, if the mask was not perfectly aligned and colored, could make certain areas on the part look completely off.

The downside of such an openly-expandable environment such as we have with KSP is that we lack any standards that can be enforced when making new parts which would allow us to create add-ons such as this without having to worry about incompatibilities. This would be simple in many other platforms, but with Unity and KSP it could easily drive you utterly insane.

[Spacepetscompany]

Couldn't one just record the Date/Time of launch and time of landing (from the flight log) and then apply textures over time based on that? It'd require a plugin most certainly!