Electrocutor

Very nice. Thank you.

Models are made of one or more meshes. Whether you choose to apply the shader to all meshes or just specific ones is up to you. The original documentation can be found here: https://github.com/shadowmage45/TexturesUnlimited/wiki/Config-Documentation Note that the documentation is not up-to-date and you need to switch a few words around to match the newer syntax. Yes you can; the shader can be assigned via model or via part. You may want to read this thread to see countless examples, questions, and other information provided already in this thread. No. The transparent shader works the same way as all the KSP translucent shaders, but adds smoothness/metallic. You can also use it in place of cutout shaders if the alpha values do not require the threshold. @Shadowmage You may want to update the github wiki to reflect the current syntax. You may also consider adding a spoiler FAQ to the OP to include a bunch of the questions from throughout the thread along with your answer in a formatted way.

KSP has an exterior model and an interior model. Upon activating the IVA-visible mode, it puts cameras and render textures in to pretend to be like transparency. It gives the appearance like the insides are being rendered in the main game camera, but they are not: the IVAs exist in their own separate root object and there are merely cameras that allow you to see them. The screenshot @alexus used earlier of RoverDude's cupola with the chair inside is visible because he modeled the interior of the glass within the exterior model.

It's always difficult to maintain motivation on such a huge project; might I suggest breaking it down into sub-releases until everything is eventually done? For example, you seem to have the majority of mk2 parts completed or mostly complete; so why not release mk2 only to start, then get feedback and work your way through iterations until you are pleased with the final product of mk2; then proceed to give the same treatment to other groups? As for compression issues and performance issues using high resolution textures... there is really only one true solution to that problem and that is to make the models for parts the way they should have been to start with: each material/color separated into their own sub-mesh and use a single set of small tiled/seamless textures shared across all parts. This is, unfortunately, a huge model undertaking; so for now at least, just use what you have. Most people are already used to KSP's lack-luster graphics, so simply having a full implementation of recoloring options that is easy to install and use is their biggest desire. As a side note, you may want to get in touch with @DoctorDavinci to combine recoloring efforts (from DCK). I expect he wouldn't mind having metallic and reflective options alongside his existing recolors, and TU recolor has support for patterning. This may also help you to figure out how to setup MM patches that allows others to add additional color or pattern presets without interfering with existing ones. My guess is that you would want to integrate with the PartVariants vanilla module as a common-ground, then have the recolor GUI available for customization. Keep in mind that you can set any material properties within a PartVariants TEXTURE node, such as... VARIANT { TEXTURE { _MainTex = _MaskTex = _MaskMetallic = _MaskColor1 = _MaskColor2 = _MaskColor3 = } }

Well, some stock variants change both model and texture. It is better to have a single module, but as you stated above, this leads to a quickly out of control number of permutations if you want to tint across all possible texture and model variants.

For convenience: opengl and d3d9 suffer from micro-stutter and performance issues d3d11 and d3d12 have a broken icon shader (fixed via mod) any but d3d9 in Windows has a part icon offset bug all in Linux have a part icon offset bug d3d9, d3d11, and d3d12 render the local+scaledspace cubemap incorrectly. (This was only an issue with d3d9 in 1.3.1) d3d11 is mildly unstable, but the highest performance d3d12 is heavily unstable glcore has no known issues except the part icon offset bug I'll note that Unity has only maintained d3d9 support (which is the only officially supported api on Windows for KSP) as a legacy backward compatibility up until the version that Squad/PrivateDivision used in v1.4. Newer versions of Unity have completely removed even legacy support for d3d9.

Unfortunately, it looks like Squad/PrivateDivision is specifically only fixing this per operating system; if that is truly the case, then Mac and Linux will have it fixed, but Windows will remain broken. The Linux fix should be included in 1.4.3, so we'll know then.

The caveat with having 2 ModulePartVariants is that you'll make yourself unable to be compatible with other mods. MODULE { name = ModulePartVariants VARIANT { name = Model1 GAMEOBJECTS { transform1 = true transform2 = false } } VARIANT { name = Model2 GAMEOBJECTS { transform1 = false transform2 = true } } } MODULE { name = ModulePartVariants VARIANT { name = Tex1 TEXTURE { materialName = Model1Mat _MainTex = path1 } TEXTURE { materialName = Model2Mat _MainTex = path2 } } VARIANT { name = Tex2 TEXTURE { materialName = Model1Mat _MainTex = path3 } TEXTURE { materialName = Model2Mat _MainTex = path4 } } } I'm trying to figure out why you are attempting to use MM value lookups; are you trying to add color tints to pre-existing variants that were made from another mod? If so, then you would either have to use option1, or else standardize that every part would have 2 ModulePartVariants and index0 is always model-only and index1 is always texture only.

Usually decals have transparency cut-off, and thus need to be excluded from TU.

Little confused, I thought you were going to make them variants? This still adds new parts.

If you just want a colored version, use PartVariants. KSP_MODEL_SHADER { model = path-to-model without .mu MATERIAL { shader = SSTU/PBR/Metallic PROPERTY { name = _Metal float = 0.0 } PROPERTY { name = _Smoothness float = 0.3 } } } @PART[part] { MODULE { name = ModulePartVariants VARIANT { name = Yellow displayName = Yellow primaryColor = #ffd300 secondaryColor = #ffd300 TEXTURE { _Color = #ffd300 } } VARIANT { name = Metal displayName = Metal primaryColor = #808080 secondaryColor = #808080 TEXTURE { _Metal = 0.75 _Smoothness = 0.75 } } VARIANT { name = MetallicYellow displayName = Metallic Yellow primaryColor = #ffd300 secondaryColor = #ffd300 TEXTURE { _Color = #ffd300 _Metal = 0.75 _Smoothness = 0.75 } } } } // https://forum.kerbalspaceprogram.com/index.php?/topic/173208-partvariant-color-tinting/ Check out my PartVariant guide linked in the OP for what options you have there. In your case, if you happen to have an exact material name that you want changed to help limit what is affected, you can do that. If you specify a mesh= in the KSP_MODEL_SHADER, then only those meshes will use the TU shader, so the _Metal and _Smoothness parameters are ignored for any but those materials. You can also specify materialName= in the PartVariant to make the changes only apply to that specific material.

The popup is new because people would install TU, but not follow directions and then ask why it wasn't working. With the popup, it will explicitly tell the player what is needed to use TU.

You can refer to my PartVariant Guide for an example in the OP that shows what is needed for VARIANT to not step on each other. As for naming of VARIANT's to not step on each other, perhaps something like author_name would make sense because each author would be sure to not use names that conflicted with their own patches. VARIANTTHEME is trickier due to limitations of ModuleManager. The only viable solution I can think would be to adopt a standardized theme set such as has been done for CommunityResourcePack. For what to call the default variant, the game automatically uses the name "Basic", but parts that use variants in stock usually use a color scheme name instead.

You need to run KSP using -force-glcore if you are using TU.

@juanml82 What RoverDude might be willing to put into MKS by pull request would be if you modified his existing textures to include a specular layer and also added normal maps. He may also be willing to include variant textures, such as color-coded Tundra and Duna. If that's the case, then it would be far easier to give them TU treatment on your own afterward.

RoverDude's stuff will take you some time to do it right because most of his models are a single mesh and most of his textures do not include specular. If you just want to make them metallic, then that is easy: just use the KSP_MODEL_SHADER syntax to set the shader, then use stock variants to give an option for Metallic. If you want to do some recoloring, then you'll want to create your own Mask and MetalGloss textures. You _could_ do a recolor across the whole part, but that will look a strange since everything would be recolored instead of just the painted white/gray parts. Shadow says the flicker will be resolved in the next release of TU: it was a bug introduced in the 1.4 version having to do with transparencies. Keep in mind that if you create mask and metal/gloss textures for MKS, you cannot release it because MKS textures are all rights reserved, so any derivative textures cannot be put into their own mod and it highly unlikely that RoverDude would include them with MKS as he is wholly against TU. The original stock cfg on the OP does not support recoloring, it is just a generic cfg that enables specular, reflections, and metallicy. Also, be sure you followed the instructions on the TU page and run KSP via -force-glcore. The porkjet stock one only affects porkjet parts, but allows you to recolor them whereas the original stock one covers all parts (pre 1.4), but merely adds specular, reflections, and metallicy directly. I am working on a much better version but it requires the new TU and new MM be released. It's been mentioned that the porkjet stock cfg may have issues with the current game/TU version: I've not had time to confirm this yet.

There are different shaders that TU has. One shader allows diffuse, normal, metallic/gloss, occlusion, and emissive. That said, the cfg options allow for static values across an entire mesh, so if there is a particular mesh that just has a bunch of metal parts, it's easier to just them to static values. There is also a stock shader that uses the alpha channel of the diffuse as specular which can then be used with a static metallic value. In addition, there is a Masked PBR shader that allows you to use a uvmap to specify pbr areas (3 per map), then colors and normals can be assigned to those sections individually. Honestly, just talking is hard to show, so once I'm able I'll make some examples. I had once made a generic cfg, yes; but during the 1.4 update, TU gained a bug dealing with the stock MODEL{ texture= } replacement, so it won't work right until the next version is released. Also, I now incorporate the stock variants alongside TU to keep the GUI clean. I usually do a Dark, Orange, and Green variant that are non-metallic and preserve everything as originally made by the artist except to tint meshes with the 3 new KSP color schemes so people have an option to make colors match. I then have a Metallic and a Shiny Metallic variant that use TU metallic. In this way, the default look is exactly as it was originally made, but people can choose between KSP colors and metallic variants.

This is a misconception. If the original texture does not contain a specular, then making it look right does become more difficult as it requires a cfg specific to that part instead of just a mass generic cfg, but does not require any redoing of textures, especially if the model has been broken into some sub meshes. Setting proper specular within the main texture does indeed make it look better, but is not required. After the new version of TU and MM are released that address a number of bugs, I will make a few examples for CobaltWolf and see if he wishes to include a TU patch.

Is there a way to use Kopernicus to make a ring that is made of terrain scatter boulders with collision enabled?

Would it?

Is there a way to check if a named root node exists, then create it if not? i.e. %VARIANTTHEME[Metal] { %name = Metal }

ModulePartVariants does allow you to set shader=; so in theory, all of TU could be used within the part module. Unfortunately, it does not search asset bundles for the shader, only the built-in ones, so you have to pick one TU shader and stick with it, having been set via KSP_MODEL_SHADER. You can then use ModulePartVariants to allow different settings. Unfortunately, the mask shader and stock shader are separate; so if you allow the part to look as the artist intended, you cannot also create a variant that uses repainting; vice versa also applies. An example: @REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited] { %enabled = true } KSP_MODEL_SHADER:NEEDS[TexturesUnlimited] { model = (path to model) MATERIAL { excludeMesh = flagTransform shader = SSTU/PBR/StockMetallicBumped PROPERTY { name = _Metal float = 0.0 } } } @PART[(part)]:NEEDS[TexturesUnlimited] { MODULE { name = ModulePartVariants baseVariant = Basic VARIANT { name = Basic displayName = Basic primaryColor = #ffffff secondaryColor = #ffffff } VARIANT { name = Metallic displayName = Metallic primaryColor = #808080 secondaryColor = #808080 TEXTURE { _Metal = 0.75 } } VARIANT { name = MetallicShiny displayName = Metallic Shiny primaryColor = #C0C0C0 secondaryColor = #C0C0C0 TEXTURE { _Metal = 0.75 _Smoothness = 1.75 } } } }

I just re-added the link to the old Stock TU cfg for now. I'm working on something more involved, but it'll be awhile. Consequently, @Manwith Noname should eventually release his own stock TU mod, but I've no idea how far along he is.

No? I wonder if google changed links when I uploaded a new revision.

When you release this pack, would you mind including a TU patch along with it? It would be something along the lines of: