Electrocutor 642 Posted June 7, 2019 (edited) 23 hours ago, linuxgurugamer said: Ok, so it seems that the material name is, in most cases, the name of the transform. Given the data below, what are the materialNames? This part has three textures defined in the MODEL stanza, only one of which has a corresponding line below MODEL { model = RetroFuture/Command/2m1xCockpit/rectCkPit texture = rectCkPit_DIF, RetroFuture/Textures/rectCkPit_DIF texture = rectCkPit_NRM, RetroFuture/Textures/rectCkPit_NRM texture = rectCkPit_EMI, RetroFuture/Textures/rectCkPit_EMI } I dumped the data using DebugStuff for this part: Reveal hidden contents [DebugStuff] +med2mPodA T:Untagged L:0 (Default) | Transform - med2mPodA | Part - med2mPodA | Highlighter - med2mPodA | ModuleScienceContainer - med2mPodA | ModuleCommand - med2mPodA | ModuleScienceExperiment - med2mPodA | ModuleSAS - med2mPodA | ModuleReactionWheel - med2mPodA | ModuleColorChanger - med2mPodA | ModuleTripLogger - med2mPodA | ModuleKISInventory - med2mPodA | ModuleKISInventory - med2mPodA | AudioSource - med2mPodA | AudioSource - med2mPodA | AudioSource - med2mPodA | Rigidbody - med2mPodA | |--+model T:Untagged L:0 (Default) | | Transform - model | | | |--+RetroFuture/Command/med2mPodA/med2mPodA(Clone) T:Untagged L:0 (Default) | | | Transform - RetroFuture/Command/med2mPodA/med2mPodA(Clone) | | | | | --+med2mPodA T:Untagged L:0 (Default) | | | Transform - med2mPodA | | | | | --+med2mPod_Exterior T:Untagged L:0 (Default) | | | Transform - med2mPod_Exterior | | | MeshFilter - med2mPod_Exterior | | | MeshRenderer - med2mPod (Instance) - KSP/Emissive/Bumped Specular | | | | | |--+Airlock T:Airlock L:21 (Part Triggers) | | | | Transform - Airlock | | | | CapsuleCollider - Airlock | | | | | | | ---Ladder T:Ladder L:21 (Part Triggers) | | | Transform - Ladder | | | CapsuleCollider - Ladder | | | | | |--+Airlock T:Airlock L:21 (Part Triggers) | | | | Transform - Airlock | | | | CapsuleCollider - Airlock | | | | | | | ---Ladder T:Ladder L:21 (Part Triggers) | | | Transform - Ladder | | | CapsuleCollider - Ladder | | | | | |--+Airlock T:Airlock L:21 (Part Triggers) | | | | Transform - Airlock | | | | CapsuleCollider - Airlock | | | | | | | ---Ladder T:Ladder L:21 (Part Triggers) | | | Transform - Ladder | | | CapsuleCollider - Ladder | | | | | |---bulkHead T:Untagged L:0 (Default) | | | Transform - bulkHead | | | MeshFilter - bulkHead | | | MeshRenderer - rectFuselage_EMI (Instance) - KSP/Emissive/Bumped Specular | | | | | |---extWindow T:Untagged L:0 (Default) | | | Transform - extWindow | | | MeshFilter - extWindow | | | MeshRenderer - med2mPod_EMI (Instance) - KSP/Emissive/Specular | | | | | |--+podEyeCover T:Untagged L:0 (Default) | | | | Transform - podEyeCover | | | | MeshFilter - podEyeCover | | | | MeshRenderer - med2mPod_ALPHA (Instance) - KSP/Alpha/Translucent | | | | | | | ---fwdLowCam T:Untagged L:0 (Default) | | | Transform - fwdLowCam | | | | | |---COL_med2mPodA_collider T:Untagged L:0 (Default) | | | Transform - COL_med2mPodA_collider | | | MeshCollider - COL_med2mPodA_collider | | | MeshFilter - COL_med2mPodA_collider | | | | | |---COL_med2mPodA3_collider T:Untagged L:0 (Default) | | | Transform - COL_med2mPodA3_collider | | | MeshCollider - COL_med2mPodA3_collider | | | MeshFilter - COL_med2mPodA3_collider | | | | | ---COL_med2mPodWindow_collider T:Untagged L:0 (Default) | | Transform - COL_med2mPodWindow_collider | | MeshCollider - COL_med2mPodWindow_collider | | MeshFilter - COL_med2mPodWindow_collider | | | ---Surface Attach Collider T:Untagged L:0 (Default) | Transform - Surface Attach Collider | SphereCollider - Surface Attach Collider | ---_default T:Untagged L:0 (Default) Transform - _default so would this be correct: This is not working: VARIANT { name = Stock displayName = Stock themeName = Stock primaryColor = #ffffff secondaryColor = #dddddd TEXTURE { materialName = rectCkPit_DIF _MainTex = RetroFuture/StockScheme/rectCkPit_DIF } TEXTURE { materialName = rectCkPit_NRM _MainTex = RetroFuture/StockScheme/rectCkPit_NRM } } 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 } Edited June 7, 2019 by Electrocutor Quote Share this post Link to post Share on other sites
COL.R.Neville 108 Posted June 7, 2019 dont you have use the EXTRA_INFO to list the bump maps etc? TEXTURE { materialName = med2mPod _MainTex = RetroFuture/StockScheme/rectCkPit_DIF EXTRA_INFO _BumpMap = RetroFuture/StockScheme/rectCkPit_NRM _Emissive = RetroFuture/StockScheme/rectCkPit_EMI } Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted June 7, 2019 1 hour ago, COL.R.Neville said: dont you have use the EXTRA_INFO to list the bump maps etc? TEXTURE { materialName = med2mPod _MainTex = RetroFuture/StockScheme/rectCkPit_DIF EXTRA_INFO _BumpMap = RetroFuture/StockScheme/rectCkPit_NRM _Emissive = RetroFuture/StockScheme/rectCkPit_EMI } 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). Quote Share this post Link to post Share on other sites
linuxgurugamer 15,624 Posted June 7, 2019 I've made progress, but still have one more issue. The following works, kind of. It correctly puts the retro in, but when I go to stock, the part turns a greyish white. I'm missing something with the second texture, I think, but I don't know what to set the materialName to. MODULE { name = ModulePartVariants primaryColor = #484D54 secondaryColor = #484D54 baseDisplayName = Retro baseThemeName = Retro VARIANT { name = Stock displayName = Stock themeName = Stock primaryColor = #ffffff secondaryColor = #dddddd TEXTURE { materialName = med2mPod _MainTex = RetroFuture/StockScheme/med2mPod_EMI _BumpMap = RetroFuture/StockScheme/med2mPod_DIF _Emissive = RetroFuture/StockScheme/med2mPod_NRM } TEXTURE { materialName = rectFuselage _MainTex = RetroFuture/StockScheme/rectFuselage_DIF _BumpMap = RetroFuture/StockScheme/rectFuselage_NRM _Emissive = RetroFuture/StockScheme/rectFuselage_EMI } } } Quote Share this post Link to post Share on other sites
COL.R.Neville 108 Posted June 8, 2019 dont all the bump maps end with _nrm? and the emissives _EMI? that might be where its going wrong at. Quote Share this post Link to post Share on other sites
linuxgurugamer 15,624 Posted June 8, 2019 (edited) 1 hour ago, COL.R.Neville said: dont all the bump maps end with _nrm? and the emissives _EMI? that might be where its going wrong at. I have no idea, but you gave me an idea and it's working now. I think that the original part has more textures listed for the model than are actually used. Once I realized that, I redid the textures using the materials which were actually there, and it's now working. For anyone interested, the working code is here: MODULE { name = ModulePartVariants primaryColor = #484D54 secondaryColor = #484D54 baseDisplayName = Retro baseThemeName = Retro VARIANT { name = Stock displayName = Stock themeName = Stock primaryColor = #ffffff secondaryColor = #dddddd TEXTURE { materialName = med2mPod_EMI _MainTex = RetroFuture/StockScheme/med2mPod_EMI } TEXTURE { materialName = med2mPod _MainTex = RetroFuture/StockScheme/med2mPod_DIF } TEXTURE { materialName = rectFuselage_EMI _MainTex = RetroFuture/StockScheme/rectFuselage_EMI } } Edited June 8, 2019 by linuxgurugamer Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted June 8, 2019 @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. Quote Share this post Link to post Share on other sites
linuxgurugamer 15,624 Posted June 8, 2019 51 minutes ago, Electrocutor said: @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. They were. It's an old mod which I'm updating. Quote Share this post Link to post Share on other sites
COL.R.Neville 108 Posted June 8, 2019 that what i like doing too making stuff from .2 work now but having to learn blender and unity since some of these old models are using shaders and stuff that wont work anymore and are baked into the mu object which is probably more accurate instead of saying model hehe. Quote Share this post Link to post Share on other sites
linuxgurugamer 15,624 Posted June 8, 2019 20 hours ago, Electrocutor said: @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. As it turns out, my configs were wrong. They do follow the naming convention, and I am now making good progress with it Quote Share this post Link to post Share on other sites
smartdummies 12 Posted June 16, 2019 Is it possible for KSPF to change values for the effects? I am specifically looking at the localPosotion so that I can adjust the plume positions to match the different models Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted July 2, 2019 On 6/16/2019 at 3:28 PM, smartdummies said: Is it possible for KSPF to change values for the effects? I am specifically looking at the localPosotion so that I can adjust the plume positions to match the different models 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). Quote Share this post Link to post Share on other sites
swjr-swis 2,603 Posted July 2, 2019 6 hours ago, Electrocutor said: 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). Speaking from an almost total absence of knowledge on the subject: couldn't the API part upgrade mechanism be (ab)used to trigger KSP to re-read/adapt base values? Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted July 3, 2019 (edited) 18 hours ago, swjr-swis said: Speaking from an almost total absence of knowledge on the subject: couldn't the API part upgrade mechanism be (ab)used to trigger KSP to re-read/adapt base values? 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. Edited July 3, 2019 by Electrocutor Quote Share this post Link to post Share on other sites
smartdummies 12 Posted July 7, 2019 On 7/2/2019 at 8:08 AM, Electrocutor said: 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). If I am reading this correctly then I would assume that since the EFFECTS node is not a module you are not able to make changes to it via KSPF Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted July 9, 2019 On 7/7/2019 at 10:48 AM, smartdummies said: If I am reading this correctly then I would assume that since the EFFECTS node is not a module you are not able to make changes to it via KSPF 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? Quote Share this post Link to post Share on other sites
smartdummies 12 Posted July 11, 2019 Hmm. I might have to look. I have been trying to see if I could use the part variants to remove the duplicated parts in Realism Overhaul, mostly engines, and my last issue has been the plumes. RO uses RealPlumes and Smokescreen which uses the EFFECTS node. If there is an alternate to that then maybe I can get that to work. Quote Share this post Link to post Share on other sites
smartdummies 12 Posted August 8, 2019 As I go through all the items I need changed for what I want to do I think that I might just need to write my own code as there are a number of config nodes I will need to touch that are not modules and I will need a way to change child nodes and specify which nodes to be changed. I appreciate you help and thoughts. Quote Share this post Link to post Share on other sites
linuxgurugamer 15,624 Posted October 14, 2019 (edited) @Electrocutor I have some additional information you can add to the guide. This arose when the costs were not making sense in a new mod I'm working on. Upon initial instantiation, the cost of the part will be the sum of the base cost plus the cost of the baseVariant. The base cost includes the cost of all resources in the base part as defined in any/all RESOURCE stanzas as is normal with parts Upon changing variants, the cost is equal to the base cost plus the cost of the new variant plus the cost of any resources which may have been changed in a part module. This is important when dealing with (among other things) fuel tanks. If the amount of one or more resources has been changed, that's going to affect the final cost. If a partmodule changes the amount of resources, it has to have an IPartCostModifier which accounts for the changed resources. Edited October 14, 2019 by linuxgurugamer Quote Share this post Link to post Share on other sites
Stone Blue 1,713 Posted January 14 (edited) First, I apologize, as I'm sure its just something dumb I'm missing, but i am trying to add a part variant (just to texture switch), to a Procedural Fairings part. It already has an existing part variant module, with 4 variants set up. I just want to add this additional one. I cant seem to get this patch to work. My MM syntax feng-shui is rusty, so i dont know if its that, or I'm missing something with how the stock variant system works... vOv Anyone have a clue? @PART[KzProcFairingSide1]:NEEDS[ProceduralFairings] { @MODULE { @name = ModulePartVariants %VARIANT { %name = 3SL %themeName = 3SL %displayName = 3SL Generic %primaryColor = #0D1C32 %secondaryColor = #935209 %TEXTURE { %materialName = fairing1 %_MainTex = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D %_BumpMap = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N } // EXTRA_INFO // { // <info name> = <info value> // // // Known Examples (ModuleProceduralFairing) // FairingsTextureURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_D // FairingsNormalURL = HorizonAeronautics/Assets/Aero/HA_3SL_PayloadFairing_N // } } } } The part doesnt use the stock ModuleProceduralFairing module, but i copy/pasta'd that from the example in the OP, just incase, and for reference for myself. Edited January 14 by Stone Blue Quote Share this post Link to post Share on other sites
Stone Blue 1,713 Posted January 16 Ok.. I got it to work. Yes, it was my MM feng-shui. This: @MODULE { @name = ModulePartVariants %VARIANT needed to be this: @MODULE[ModulePartVariants] { VARIANT Quote Share this post Link to post Share on other sites
Random Annoying Guy 16 Posted March 12 Anything known of disabledEvents? Quote Share this post Link to post Share on other sites
Electrocutor 642 Posted April 2 On 3/12/2020 at 1:00 PM, Random Annoying Guy said: Anything known of disabledEvents? I've not messed with it, but it should be things like turning lights on and off. If you disable the event then it wouldn't be an option. Quote Share this post Link to post Share on other sites
MacLuky 464 Posted May 8 This looks awesome, but I keep struggling. Does anyone have an example of how to for example turn a panel to red or a tank to blue? Quote Share this post Link to post Share on other sites
MacLuky 464 Posted May 10 (edited) Okay, I got this far: @PART[Panel0|Panel1|Panel1p5|Panel2|Triangle0|Triangle1|Triangle1p5|Triangle2|EquiTriangle0|EquiTriangle1|EquiTriangle1p5|EquiTriangle2] { @MODULE[ModulePartVariants] { +VARIANT { name = Duna displayName = Duna themeName = Duna primaryColor = #cc0000 TEXTURE { shader=KSP/Bumped Specular (Mapped) mainTextureURL = PATCH_LIB/duna_temple/red color = #943828 _BumpMap=SquadExpansion/MakingHistory/Parts/Structural/Assets/Panels_Gold_NRM _SpecMap=SquadExpansion/MakingHistory/Parts/Structural/Assets/Panels_Gold_S } } } } The panels do show up in the VAB in red but the variant in the slider is still called Dark. As I launch the craft it reverts back to dark grey.... Not sure where I make a mistake. Anyone that can help? I checked the .craft file there it also lists the selectedVariant as Dark. So why isn't the name of the variant "Duna" @Electrocutor do you have an idea? Edited May 10 by MacLuky Quote Share this post Link to post Share on other sites
