Electrocutor

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.