Electrocutor

Have you had any luck in creating preset color groups/collections or not messed with that?

@Nils277 If you wanted to add some stock variants, you can just make the different materials use different named Unity Materials and set the _Color within the variants to give different options (for example, matching the soviet/russian green/orange or what not). https://forum.kerbalspaceprogram.com/index.php?/topic/173441-partvariant-guide/ The TEXTURE->materialName property sets which unity material it modifies. I noticed you decided not to use the newer TU cfg I made a while back (link). Do you not want the TU recolorable options available? I was going to work on updating them for the 1.6.1 release of TU, but I want to be sure to do it in the way that you wanted to use.

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.

So you made your own cfg for sspxr? If you want to fix it, change the shader for the glass to the transparent version.

Like I said, setting rescaleFactor and scaleFactor during the onAwake of the PartModule works fine. So it just becomes a matter of me going out to get my persistent values myself. I had just wondered if there was universal "re-make this part' method call: as obviously it is re-read when you revert from flight to editor.

Many things: the current is to set rescaleFactor and scaleFactor. These both work onLoad when reverting to the editor, but not when starting flight. If I force set them to some number in onAwake (before KSP has set the PartModule fields), it works in all scenarios, but this means I would have to find and load my persistent values myself because KSP hasn't set them yet.

During flight, onLoad fires AFTER the part has already been read-in and drawn (reading in mesh, model, rescaleFactor, scale, attach nodes, etc). I need to adjust things before it has been created and set. The reason is because modifying something after the fact by forcibly changing transform sizes, positions, or other things (like Tweakscale) is very prone to breaking between version when they change something and unexpected behavior. If you modify those things before it is loaded, then the game just sees it having been that way from the start and everything works normally no matter what was changed. onStart fires long after onLoad. Oddly enough, onInitialize also fire after onLoad. The only option I can think is to manually pull data out from the persistence file myself during onAwake: which is horribly nasty/ugly.

I'm writing a story. It has new resources, tech tree, contracts, parts, etc. It may end up needing some extra game mechanics too, but not yet. The story starts out with Kerbals having only a pedal seat, panels, wheels, wing, and propeller unlocked along with a thermometer: think Wright brothers. They use a new resource called Stamina to drive pedals that produce Torque, which in turn drives the wheels or propeller. They can replenish their Stamina by eating Snacks. The next chapter is about developing Steam engines, which leads into LiquidFuel engines, and so on.

I'm saying to use GIMP or PS or whatever you use and just replace your colors with the stock white color or stock gray color: the style of your textures already are pretty close to stock-a-like, just the colors are different. Here's what I've found so far: Stock White: 211, 211, 211 Stock Black: 57, 56, 57 Stock Orange: 244, 152, 65 Stock Green: 115, 123, 87 I don't currently have the numbers for the dark metal and light metal surfaces.

Looking at the details, I think you should be able to just do a desaturate, normalize and set to stock white/gray in most places and it will look fine. If you have some patience, you could actually probably just change the uvmap coordinates for quite a few things and directly use the stock textures. For metal stuff and solar panels, you could switch to the new stock PBR shader. ---- I'm no artist, but I can run batch GIMP scripts.

Greetings, I'm looking for someone to make an animated model for me; or perhaps just an animated texture? I need an axle that acts the same as the fuel line except that it is able to be animated depending on the throttle setting (rotating). The two ends should have an angle and also rotate looking like they go into the parts they are attached to. The concept is that I have Torque as a resource. Torque acts like fuel in that it only flows through parts specifically that allow it to or by a fuel-line/axle. When a propeller or wheel is attached directory to an engine or motor, the axle is not needed; but if you use a single engine/motor to drive several wheels, I need a visual way to present the transference of torque from the engine to the wheels (or wheel blocks). Instead of consuming ElectricCharge, wheels will consume Torque, and that torque can be generated through various means: turbine, engine, motor, etc.