Electrocutor

If you have the straight mylar on its own mesh: KSP_MODEL_SHADER { model = path/to/model MATERIAL { mesh = meshname shader = TU/Metallic keyword = TU_STOCK_SPEC float = _Metal, 1.0 } } If a mixed mesh: KSP_MODEL_SHADER { model = path/to/model MATERIAL { shader = TU/Metallic texture = _MetallicGlossMap, path/to/metalglossmap } } He also has a PBR Specular shader if you prefer that. From your OP, I'm curious if you realize that diffuse/albedo should be in dxt5 and normals in dxt5nm? Using PNG used to work well, but some time ago they now auto-convert to dxt format in-game (very crappily), and I don't believe bumps work in PNG anymore (used to be a grayscale height map that was converted in-game).

@Manwith Noname If you're active on this again, I can help you out with cfg stuff to make everything happy, but I'm terrible at making masks, normals, and metal/roughness maps.

If memory serves, this is one of the bugs with TU and PartVariants that's been there since the beginning: it caches the colors/material per part instead of per part instance. @Shadowmage So... KSP is FINALLY dropping dx9... albeit only shortly before KSP2 comes out.

You can create a single VARIANT and set it as the baseVariant, then it will only have one variant, but the variant icon will still show up for it.

The dev team ( @JPLRepo ) keeps the PartTools up to date for Unity (https://forum.kerbalspaceprogram.com/index.php?/topic/160487-parttools-updated/), and @taniwha maintains the blender plugin for import/export (https://forum.kerbalspaceprogram.com/index.php?/topic/40056-12-17-blender-280-mu-importexport-addon/). You can have more than one variant per ModulePartVariants partmodule. (https://forum.kerbalspaceprogram.com/index.php?/topic/173441-partvariant-guide/)

The airplane parts mostly use the specular KSP shader, which may be part of it; otherwise make sure that your outside surfaces are actually all marked as being outside. If you use the diffuse-only or specular+bump version, they will probably shade slightly differently. I'm not sure what value they use for shininess, though; as that is a fixed value in the shader.

You can accomplish this using PartVariants, but that's a kind of clunky solution for the default part.

I would have to code for it specifically, like I did with changing the IVA and resources; then test if it reads the changes or not. I thought EFFECTS was no longer used though since they created PartModules for different types of effects?

KSP does not include the Unity Standard shader with many options enabled. You can display diffuse-only. No normals, speculars, or any of the lighting options are included.

I haven't tinkered with them extensively yet; it is on my to-do list. Upgrades serve a different purpose though, allowing improvement via the tech tree; so I'd honestly like it better the other way around where an upgrade would unlock a more advanced variant instead.

There is a bug with ModulePartVariants that can delete attachment nodes. I made a bug report for that back when ModulePartVariants was first added to the game.

KSPF can change any property value on any PartModule as well as resources and the IVA model. It is only the base properties of the part that won't work currently because those are read in before any PartModule event is fired in the API (and I haven't found a way to make KSP re-read the values).

@linuxgurugamer For your example, you have 4 materials (med2mPod, rectFuselage_EMI, med2mPod_EMI, med2mPod_ALPHA). Each of these could have a diffuse, normal, and emission map. The fact that you are setting a _MainTex on two of these materials as an _EMI, which I would assume to be emission textures, and it looks right; makes me think that these meshes were very strangely setup. As can be seen in probeRoverBody_v2 from stock, that is not the usual way you use materials.

No. EXTRA_INFO is used if you have other addons or partmodules that interface with variants. For example, the shell textures with ModuleProceduralFairing (in stock).

rectCkPit_DIF and similar are just the names of the actual textures. med2mPod and the like that shows next to MeshRenderer are the material names. so something like: TEXTURE { materialName = med2mPod _MainTex = RetroFuture/StockScheme/rectCkPit_DIF _BumpMap = RetroFuture/StockScheme/rectCkPit_NRM _Emissive = RetroFuture/StockScheme/rectCkPit_EMI }

For everyone complaining about the new suits... you do know that they are based on the actual new NASA suit(s), tron-like glow lights and all? https://www.nasa.gov/exploration/technology/advanced_space_suits/index.html

There is no generic place to get/set the base part values, so I need to add them each. Which ones did you need? Just crashTolerance, breakingTorque, and breakingForce? [Update] Further testing has revealed that tolerances and breakings are the same as scale, rescalefactor, and many other part-level properties. Their values are read by the system before PartModules are loaded, so even if you change the value in a PartModule, the new values are not used. As yet, I have not found a way to make the game re-read these values after a PartModule loads. I know that I can set these during PartModule's OnAwake and it works, but during OnAwake the game has not loaded the PartModule fields yet, so you don't know what to set things to.

After checking the code, it seems I inadvertently removed the bit to set base part values (like mass or breakingForce) while messing with other stuff. Sorry about that. Will add them back in when I get a chance.

baseDisplayName changes the visual name of the implicit base variant. baseVariant sets the name of which explicit variant to use as base. My Addon called KSPF has a component named ModulePartVariantsEx which extends the functionality of variants to set any property of any PartModule. https://github.com/Electrocutor/KSPF/wiki/ModulePartVariantsEx

Each VARIANT you define is in addition to the base variant. Now, if you wanted the base variant to say set some value in EXTRA_INFO, then you would need to define an explicit variant for the base, and set it via baseVariant=. For Example: // optional battery MODULE { name = ModulePartVariants baseVariant = Basic VARIANT { name = Basic cost = 100 mass = 0.01 EXTRA_INFO { Resource/ElectricCharge = none } } VARIANT { name = BatteryIncluded cost = 1100 mass = 0.06 EXTRA_INFO { Resource/ElectricCharge = 1000 } } } This uses my ModulePartVariantsEx to allow EXTRA_INFO to set any other module property, but since the changes need to be removed when switching back to the original variant, I must explicitly define the base variant.

A lot of the various properties of PartVariants can be left out during debug as they will work fine, but leave a warning in the log. Not setting a name for the base variant I believe gives it the name 'basic'. Also, if you have nothing set in your base variant, there is no need to explicitly define it.

In the OP, notice that TEXTURE allows a materialName property. You can use the latest version of DebugStuff (https://ksp.sarbian.com/jenkins/job/DebugStuff) to see the name of the different materials on models. When setting the actual texture, you would always use _MainTex= and _BumpMap=. mainTextureURL is another property some of the KSP shaders has in them that map to _MainTex. I looked into this once a long time ago, but cannot remember why they had it, but figured out it is the same as setting _MainTex anyway. I think it had to do with resource unloading or something that is no longer used.

I think restock is used commonly enough that it may warrant a NEEDS[!ReStock] for the parts that are replaced. In the future, IL may even get a PR someday to place some lights on restock models, which would then have two patches: one for !ReStock and one for ReStock.

@Shadowmage You can add Procedural Fairings to the OP if you want.

The most complete TU implementation to stock was https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/ , but was never finished. I'm unsure if he intends to come back and complete it or not.