Electrocutor

I'd say you're very near to having this release-worthy. Do you have a to-do list for what needs finished before it moves over? I might suggest you change your deployment method over to github though; this way you can use the issue tracker (which is great for sanity).

To mimic old behavior: MATERIAL { shader = TU/Metallic mode = update keyword = TU_STOCK_SPEC }

In the OP, you'll notice a link to Recolor Depot by @Manwith Noname. That's your best bet for shiny right now because very few part authors want to make masks/maps for their parts. He has more-or-less set up the patches to work with restock, but doesn't have cfgs/maps to support restock itself (not sure if that is on his plate or not because he does have some packs for other part mods).

There is no BDB config. BDB will require that you create a metal map at the very least for nearly every part; and there are a LOT of parts.

One thing to note that may be affecting this is that in 1.8 many of the 'bumped' shaders that used to be fine if you did not specify a bump map, now require that you provide one. If it's blank, it does not render properly.

I've spoken with some authors who have wanted to use custom shaders for things, but couldn't figure out how to get shaders into KSP. When I mentioned that shader import was the whole original purpose of TU, they were surprised it could even be used for that and had thought that by even just installing TU, your whole install would be infected with shiny parts (it seems someone had uploaded a 'TU config' for stock to CKAN a long time ago that is similar to one of my old example patches that just does a mesh blanket for shiny; and this is what everyone knows TU by). I think KSP attracts a lot of new artists to try their hand at modeling, and don't understand that PBR does not mean shiny metal unless you make it so. You may also want a concise summary of what TU does and doesn't do on the Wiki Home. It's an incredibly useful tool that seems to be misunderstood frequently.

@Shadowmage Could you also please add documentation for the uvunwrap and shader loader features to the wiki?

The guides I have on my thread are for variants; there is some forum discussion about TU configs though. The best resource for configs is the wiki section of the github for Textures Unlimited. If you have something specific, just ask in this thread and you'll get help. For the best stock implementation, look at: https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

You'll probably want to just use RoverDude's examples in the actual mod to see how to use it. https://github.com/snjo/Firespitter/blob/master/For release/Firespitter/Parts/Engine/FS_copterRotorMain/part.cfg There are also a couple links on the wiki page there with documentation, but no idea how valid they are.

The reason ModulePartVariants defaults to run-time drag cubes is in case you specify different models within your variants, so each one would have different drag. Obviously, if you just have color changes, this is unnecessary, and setting it static is fine.

You don't need to create a mod, just learn how to make configs for Kopernicus, Scatterer, and EVE.

A lot of people who make wheels for KSP use KSPWheel as a dependency.

@Shadowmage When you get a moment, would you mind adding the cfg syntax to the github wiki for specifying a custom color group for the recolor GUI? I think I garnered what was needed by looking at the code for definition, but didn't see anywhere to specify the group name to use (like in the GUI PartModule). KSP_COLOR_PRESET { name = A title = color = specular = metallic = } KSP_COLOR_PRESET { name = B title = color = specular = metallic = } KSP_COLOR_PRESET { name = C title = color = specular = metallic = } PRESET_COLOR_GROUP { name = MyColorPresets color = A color = B color = C } You can re-use a textureset on as many things as you want, but not parts of it. If you want everything the same, but have different mesh= or something, then utilize ModuleManager's syntax to copy/edit a generic textureset and then add the needed mesh names to it. +KSP_TEXTURE_SET[templateName] { %name = newName }

https://docs.unity3d.com/Manual/class-TextureImporterOverride.html

The 1.8.1 hotfix is out now too, so in theory the major issues with 1.8 should have been addressed now.

I found your issue: The MiniISRU model has textures attached to some the colliders, but they are blank... you could submit this as a bug, but I don't know if they'll bother to fix it.

Try searching for UnityEngine (no extension) within the ksp folder?

KSP_x64_Data is still being used for the managed dlls. The references you need have changed slightly with 1.8 and can be found in the sticky of this same forum.

mesh= does work, but is legacy and mutually exclusive with MODEL{}.

The texture replacement is extremely picky; it does work, but you have to get everything right and won't get any useful error to tell you what you did wrong. Plus, the original texture has to present as it is used to load the model in first. To be honest, I haven't used this since PartVariants came out since I just use that now. A quick search yields: https://forum.kerbalspaceprogram.com/index.php?/topic/157846-solved-texture-tag-not-working-in-model-section/ It seems that if a model has any mesh that doesn't have a maintexture in the mu mapped (like most flag meshes), it will fail with a null ref. Also, make sure that your texture is dxt1 or dxt5. [Edit] A quick look at the miniISRU in Blender shows it only has one texture, and it is mapped; so as long as your replacement dds is properly formatted, it really should work. You can check the log to make sure your dds is being loaded in.

Scatterer's framerate just depends on what configs you're using for it. They usually go together because people who are making planet packs want them to have atmospheric effects (same with EVE). If nothing's changed, the biggest framerate guzzler is usually scatterer's water shader. I've always thought it'd be nice if KS3P, Scatterer, and EVE would get combined into a joint mod. KS3P adds in the stock Unity post-process shaders that SQUAD pulled out, and Scatterer is the KSP version of a Unity port of Proland. @blackrack This reminds me: have you checked out Scrawk's new/old/revised ocean shader to see if it performs better? https://github.com/Scrawk/Ceto

https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/frameworks https://docs.unity3d.com/2019.2/Documentation/Manual/dotnetProfileSupport.html https://www.mono-project.com/docs/about-mono/compatibility/ Unless you have a specific reason to use .NET Framework 4.x, Unity recommends using .NET Standard 2.0; the reason being that Mono supports everything in .NET Standard, but only a sub-set of .NET Framework (and Unity's version of Mono is more unclear because it is an in-house compile). As for which _can_ you use: .NET Standard is fully version-additive, so any of the Framework versions from 4.5 on is fine: newer versions will give you more features that were added later if you need them. There is a sub-note on the net-standard link above: "While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher." I'm unsure if this would also affect mono or not. As a note, Microsoft has discontinued all support for 4, 4.5, and 4.5.1 (including no security updates); so I'd recommend not targeting them for any project you do out of habit; though from KSP's perspective, it doesn't matter. As another note, .NET Framework has been feature end-of-life since April this year with the release of 4.8, which is the last version. From this point on, it will just receive security updates and such. I saw that the compatibility list for Mono does not yet list 4.8, so I would probably avoid targeting it until it does, just in case you use something new. [Edit] In layman's terms: - Unity 2019.2 supports everything in .NET Standard 2.0 (and earlier). - Unity 2019.2 supports some of .NET Framework 4.x, but not everything. - As long as you don't use things in .NET 4.x that Unity doesn't support, there is no issue.

Unity's website says to target .NET Standard 2.0. https://docs.unity3d.com/2019.2/Documentation/Manual/dotnetProfileSupport.html As an note, .NET Framework is now end-of-life after the release of 4.8 earlier this year.

This isn't entirely true. You can use KSP_MODEL_SHADER to simply set the meshes to use the TU shader, then use ModulePartVariants to set all the textures, floats, etc on the TU shader per variant. Variants cannot change the shader and keywords is all; and if you use recoloring, you need a TU-centric PartModule to store your preferences.