Electrocutor

If you look at the source to KSPF, it's pretty simple. [KSPField(isPersistant = true)] public string InternalModel = null; public override void OnLoad(ConfigNode node) { this.part.partInfo = new AvailablePart(this.part.partInfo); SetInternalModel(); } private void SetInternalModel() { if (string.IsNullOrEmpty(this.InternalModel)) { return; } ConfigNode oConfig = new ConfigNode("INTERNAL"); oConfig.AddValue("name", this.InternalModel); this.part.partInfo.internalConfig = oConfig; } The PartInfo is usually a single object shared across any part instances that are made from the same part; in this case, I just copy it and create a PartInfo for every part instance, so it can be different for every instance, and store/load the values from fields.

In my own game, I am using batch-generated and edited normal and metal/gloss maps on all my buildings and all scenery objects use the TU shader except for a couple where the TU shader caused z-fighting that wasn't previously there; I also generated normals for terrain textures. Unfortunately, since these are generated from the game's actual textures I cannot release a mod that includes them. Some artist would have to remake all the textures themselves in order to release them in a mod. @Bottle Rocketeer 500 @Shadowmage has a program that scans a texture and gives you the normal values, or you can just use gimp and desaturate then check the gray level in the region you want to normalize. My hope for TU configs was that part authors would include patches that allowed optional TU support (just like they do for tons of other mods like TAC, USI, tweakscale, etc), but @Nils277 is the only one who packaged compatibility that I know of aside from the couple packs that require it. With the new KSP shader, part authors could break up their meshes and make their parts have PBR in the stock game themselves as well (for non-emissive meshes), but I haven't seen anyone adopting that either yet.

I've been working on it off and on a long time, but it's still a long way out.

So... I need some direction on what to work on that people would want to use. Here are the current things I have in the fire, some feedback on what to prioritize would be nice: There and Back Again: A Kerbal's Tale A story-driven mod that includes all sorts of stuff, but the main purpose is a timeline progression of tech, parts, missions, contracts, etc that makes sense. The story starts like the Wright brothers where Kerbals can just make a basic wooden glider with a pedal-powered propeller A propeller runs on a resource named Torque, which is generated from a part called Pedals (command-seat-like), which use a resource named Stamina that Kerbals possess and can be refilled by eating snacks. stock part default upgrades this includes things like removing a bunch of the probe cores so instead of having different parts that allow different navigation features and such, they are all the same part with progressive upgrades. engines and things start out as being less efficient and become more as tech evolves standardized parts remove all stock parts and replace them with standardized versions. it is effectively a new base set of parts for KSP that utilizes existing models/textures and or license-allowing mod models/textures along with dynamic capacity. i.e. There is one tank for solid, liquid, and gas for each bulkhead profile, but variants exist for 1, 2, 4, and 8 multiplier capacity, each having a number of visual variants. Ven Stock PBR give pbr treatment to Ven's stuff via Blender and Textures Unlimited I was actively working on this until @Nertea dropped the dev post about the new restock mod: as they serve the same purpose and this one is being actively developed, I'm thinking of waiting for its release and then giving it pbr treatment instead KSPF Continue work on the framework I've been tinkering on for years that would allow much more ease, efficiency, and consistency to other mods. You can think of it as something like SKSE for Skyrim, only less low-level. Other I'm always open for suggestions on things people want to see.

@EnzoMeertens Given your license, do you know if any of the part-testing mods have packaged your visual damage states into their own mods? This is such a great mod for visualization of impacts, I hate to see it slowly fade into obscurity.

All I heard was *grumble* *grumble* giving me all these free fixes and graphic updates so quickly *grumble* *grumble* I very much like this update... personally, I think they should have waited on 1.5 to include these things with it; it resolves a bunch of short and long-standing issues aside from the graphical updates. What are the bits that are currently in pieces on the floor?

@Kerbas_ad_astra Did you see the two new variant properties? disabledAnimations and disabledEvents These should help with some of the Ven variants like docking ports so the animation buttons and action lists are correct for the currently selected variant.

Have you come up with a list for this yet? ... and will it be made in tandem with this or only started after the base restock is complete?

New in 1.6: VARIANT -> disabledAnimations = comma? delimited list of animations to disable for a given variant VARIANT -> disabledEvents = <module name>.<event name> (should also be comma? delimited) I'll add these to the OP once I figure out exactly how they work.

I'm unfamiliar with the ins and outs of upgrades, so would need the details of exactly how they do and don't work. Have you tried doing upgrades at the root MODULE level instead of under VARIANT? It's possible that you could surround VARIANT with an upgrade so that a single VARIANT only becomes available after the upgrade is applied (if upgrades support nodes and not just values). If you can figure out the exact needs and functionality of upgrades, then we can work around it.

Okay, thanks.

StockPBR_Templates { SpecularFixed { MATERIAL { name = SpecularFixed shader = TU/Metallic float = _Metal, 0.0 float = _Smoothness, 0.2 } } Transparent { MATERIAL { name = Transparent shader = TU/Transparent/Metallic float = _Metal, 0.0 float = _Smoothness, 0.0 } } } ---- Other File ---- KSP_MODEL_SHADER { model = Squad/Parts/Command/Mk1-3Pod/Mk1-3 #@StockPBR_Templates/Transparent/MATERIAL { } @MATERIAL[Transparent] { mesh = Flag } #@StockPBR_Templates/SpecularFixed/MATERIAL { } @MATERIAL[SpecularFixed] { mesh = M1-3 } }

UrlConfig { name = KSP_MODEL_SHADER type = KSP_MODEL_SHADER parentUrl = StockPBR/Squad/Parts/Command/Mk1-3Pod/Mk1-3 KSP_MODEL_SHADER { model = Squad/Parts/Command/Mk1-3Pod/Mk1-3 #@StockPBR_Templates/Transparent/MATERIAL { } @MATERIAL[Transparent] { mesh = Flag } #@StockPBR_Templates/SpecularFixed/MATERIAL { } @MATERIAL[SpecularFixed] { mesh = M1-3 } } } I'm on 3.1.1. I changed it so it only had a single line to follow instead of multiple of the same node type, but it still isn't working right.

@blowfish So... the new version of MM no longer puts the translation of cfg into the cache, but instead the pre-process commands. Is there still a way to see what the actual output cfg is after processing? My scenario is that this... #@StockPBR_Templates/MATERIAL[SpecularFixed] { } ... does not seem to be copying the SpecularFixed one, but instead the first MATERIAL node it finds. I wanted to see the post-process cfg to verify.

When I did all the moving about and put ModulePartVariantEx as part of a larger project, the name of the PartModule changed. The module is simply named ModulePartData now, and will encompass all part-level properties that currently do not persist, including the internal model, which I've renamed to InternalModel. i.e. ModulePartData/InternalModel. This may change again in the future (or not) depending on how KSPF moves forward. Sorry for the confusion.