Electrocutor

@Waz I had a dream once... I saw Kopernicus, Eve, Scatterer, KS3P, and a basic texture replacer all packaged and optimized into a single mod and maintained as a group effort. Contents: Simple texture replacement Scrawk's Stuff (EVE and Scatterer) https://github.com/Scrawk?tab=repositories PQS Kopernicus PlanetShine Built-In Unity Post Processing (KS3P) https://assetstore.unity.com/packages/essentials/post-processing-stack-83912 PBR Part Shaders Textures Unlimited Any chance of that dream ever becoming reality? The goal would be a single cohesive graphical framework without implementation.

Updated guide to include cost and mass modifiers

Having metal on red, smotthness on alpha, and ao on green is pretty standard for PBR textures though: I think his goal is to standardize the shader with how most PBR works. For example, with this setup, I can now directly make a PBR version of Porkjet's PartOverhaul because he already had all of this made.

Have you figured out how to use recoloring on all the different stock variant patterns? If not, I can help you out: I'm good with .cfg, but terrible with texture painting.

You know how long that has been there and I never noticed! I'll need to redo the cfg's for @Shadowmage new shader; plus it will be much easier to fully support recoloring now. I can also target any of the stock parts that now have a 'White' variant for the same.

Alright, thanks. I'll see if I can find a decent python to c# converter.

DebugStuff runs inside Unity after KSP has already read in the .mu data; this needs to be programmatic and is done outside the game.

Is there any chance you could offload the byte format stuff for .mu files into a compiled .dll so as to allow .mu files to be read? Namely, I am looking to read a .mu and get a list of mesh names, material names, and texture paths from those materials. I am working on a WPF app to create/edit parts via GUI, and the mesh and material names are needed to pre-fill drop-downs for some values in PartModule config sections. It also has a sub-feature for scanning the mod folder for orphaned files, such as unused textures.

It adds a button, but an icon prefixed with cs_ under the PartList/SimpleIcons does not get mapped to it, and I cannot find anything in the Localization file or KSPedia where it gets the text/name for the mouse-over. I'm pretty sure I can get it to work using the code from RoverDude's Community Category Kit, but was hoping stock had a way to put things in.

I've added an UnofficialPatch to the OP. I have a lot more it is doing locally, but will only include the things that are mostly bug-free for releases. If someone wants to take some time to check the attachment nodes and rotations for all the stock parts and note any that are wrong, let me know and I will include those fixes into an optional add-on. I don't want them forced because it would break a lot of the stock craft files.

As the title suggests: Is there any way to add additional cross-section profiles into the game that can then be specified via bulkheadProfiles and filtered in the editor?

I just meant that processing these using the default flat map would be fine instead of turning the feature on and off. If they don't even have a bump map, why would they bother with metal/gloss, and if they don't use metal/gloss, why would they even be using this shader in the first place? Even stock uses metal/gloss with metal at a fixed multiplier and gloss at diff.a.

I was tinkering with the new KSP shader and finally figured out why the parts didn't look right even after adding a reflection probe... ambient light. The ambient light slider needs to be off for the PBR to look right, otherwise the whole surface is mostly getting the same amount of light, which makes it look strange. After turning ambient light off, you can now get parts to look as good as TU in terms of lighting, minus the fact of having a flat smoothness. I think that in the VAB/SPH, the point light is insanely bright compared to Flight, so you don't notice it there. Turning off ambient light has it's own issues though: namely the old KSP shaders don't have the same indirect light calculation in them as the new one does: they just look black if not in direct light. ---- As for the size of the new shader, you may consider removing the keywords for things like bump, emissive, etc to reduce the permutations. I think diff+bump+metal/gloss can be assumed to always be present, AO shouldn't take much juice to just be static if not present. Is there ever a case when you would use standard vs tinting mode? as I understand it, the standard will always have a grayscale map for diff while tinting will convert diff to grayscale, or is the difference between base 127 and base 0? Honestly, spec.r for smoothness could go away, but you'd need to batch process the old maps, that could be considered a bug of the old shader because all maps that I know of for pbr have metal on R and smooth on A: perhaps leave it for with the intent to remove it after maps get converted.

err no... it's what Unity uses to choose what things to render. For example, this is my reflection probe code: ReflectionProbe oProbe = oVessel.gameObject.AddComponent<ReflectionProbe>(); List<KSPLayer> oLayers = new List<KSPLayer>() { KSPLayer.Atmosphere, KSPLayer.LocalScenery, KSPLayer.ScaledScenery, KSPLayer.ScaledSpaceSun, KSPLayer.SkySphere, KSPLayer.Water }; oProbe.mode = UnityEngine.Rendering.ReflectionProbeMode.Realtime; oProbe.refreshMode = UnityEngine.Rendering.ReflectionProbeRefreshMode.EveryFrame; oProbe.timeSlicingMode = UnityEngine.Rendering.ReflectionProbeTimeSlicingMode.IndividualFaces; oProbe.cullingMask = GetCullingMask(oLayers);

This mod seems to really be going places... now you have me dreaming of an additional KSC building called 'Construction' where it puts you into a build editor GUI and build/upgrade roads, runways, etc with funds.

Thanks; I'm surprised you don't use them to make a cull mask.

@Shadowmage I get the feeling that the KSP render wiki is a long way out of date, could you see if my list needs updated compared to what you know? public enum KSPLayer { Default = 0, TransparentFX = 1, IgnoreRaycast = 2, Water = 4, UI = 5, PartsList_Icons = 8, Atmosphere = 9, ScaledScenery = 10, UI_Culled = 11, UI_Main = 12, UI_Mask = 13, Screens = 14, LocalScenery = 15, kerbals = 16, Editor_UI = 17, SkySphere = 18, DisconnectedParts = 19, InternalSpace = 20, PartTriggers = 21, KerbalInstructors = 22, ScaledSpaceSun = 23, MapFX = 24, EzGUI_UI = 25, WheelCollidersIgnore = 26, WheelColliders = 27, TerrainColliders = 28, Vectors = 31 }

Okay, I updated the dx11 fix to also include a reflection probe for now. It's very bare-bones and only includes: List<KSPLayer> oLayers = new List<KSPLayer>() { KSPLayer.Atmosphere, KSPLayer.LocalScenery, KSPLayer.ScaledScenery, KSPLayer.ScaledSpaceSun, KSPLayer.SkySphere, KSPLayer.Water };

Please let them know how much this is appreciated; I'm very glad to see the older parts getting some attention such that all the parts are now moving toward a common color and design theme.

Well, 1.5 was only released yesterday and TakeTwo doesn't usually say what they are working on especially. They have http://bugs.kerbalspaceprogram.com , but I've not logged into it for a while. I should certainly hope it is something they will fix because they are using that shader for things like the rover, foil plates, and stay-put-nik.

It would be a quick fix, mostly to help get the light levels and specular working: the accuracy of the reflections would not be a priority.

I've updated my PartVariant Guide. I'm curious for some feedback: would you guys like me to fix the new shiny parts in stock? There is a bug where they forgot to hook up the reflections during flight, so anything that uses the new shader only looks right in the VAB/SPH. I would hope/imagine this will be fixed in a hotfix or something, but if people are impatient I can toss a reflection probe into the dx11 fix so that those parts will at least work for now (only takes about 5 lines of code).

Here is an example to create a new variant based on the new shiny shader: (please note that the shiny shader has a bug in 1.5.0 that only lets it work inside the VAB/SPH and not while in flight) @PART[mk1pod_v2] { @MODULE[ModulePartVariants] { +VARIANT[White] { @name = Shiny @displayName = Shiny @themeName = Shiny @TEXTURE { %materialName = Mk1_Dark %shader = KSP/Bumped Specular (Mapped) %_SpecMap = Squad/Parts/Command/mk1pod_v2/Mk1_v2_W } } } }

Updated working example to reflect 1.5.0 changes.

Here is the new 1.5 syntax for adding Ven's Mk1 Pod as a variant: @PART[mk1pod_v2]:NEEDS[UnofficialPatch] { MODEL { model = VenStockRevamp/Squad/Parts/Command/CommandPods/MK1 } %MODULE[ModulePartVariants] { %name = ModulePartVariants %baseVariant = Dark %VARIANT[Dark] { %name = Dark %displayName = #autoLOC_8007117 %themeName = Dark %primaryColor = #4c4f47 %secondaryColor = #4c4f47 } @VARIANT[*]:HAS[!GAMEOBJECTS] { GAMEOBJECTS { Squad/Parts/Command/mk1pod_v2/Mk1Pod_v2(Clone) = true VenStockRevamp/Squad/Parts/Command/CommandPods/MK1(Clone) = false } } @VARIANT[*]:HAS[@GAMEOBJECTS] { @GAMEOBJECTS { %VenStockRevamp/Squad/Parts/Command/CommandPods/MK1(Clone) = false } } +VARIANT[White] { %name = Ven %displayName = Ven %themeName = Ven %primaryColor = #000000 %secondaryColor = #000000 %GAMEOBJECTS { %Squad/Parts/Command/mk1pod_v2/Mk1Pod_v2(Clone) = false %VenStockRevamp/Squad/Parts/Command/CommandPods/MK1(Clone) = true } -TEXTURE {} NODES { node_stack_top = 0.0, 0.67, 0.0, 0.0, 1.0, 0.0, 0 node_stack_bottom = 0.0, -0.33, 0.0, 0.0, -1.0, 0.0, 1 } } } } There seems to be something in the stock model that allows the flags to show up on variants, but not on Ven's? Here is the UnofficialPatch for 1.5.0: