Shadowmage

Changing gears works with the wheel-group functions as well. Set the wheel groups, and then change the gear on a single wheel will see it propagate to the rest of the wheels in the group. This is all done through the part right-click menu; I don't remember if action-groups are supported in that functionality, or what specific functions have action groups that trigger them.

As in, adjusting the ride-height / spring values for multiple wheels at the same time? For most wheel functions, if you set each part the same 'Wheel Group', any actions triggered on one wheel in the group will propagate to the rest of the group; adjust spring on -one- wheel, and it gets set for all of them. (might not be exactly what you are looking for; if not, let me know with perhaps a bit more detail, and I'll see what I can put together)

Nope, when in the water, the wheels always sit fully drooped (nothing for the spring to press against). You can get more force by mounting the wheels higher, so that when in the water only ~50% of the wheel is submerged (the point of greatest force output). Yeah, the scaling balance is a bit... strange... in places. As long as the power draw (and mass) of the part make sense for their new scale, I wouldn't worry too much about cross-part-(im)balancing, esp comparing parts at different scales.

Not by default. You can try the unsupported stock-parts patches, which can be found here (download the .cfg files, put them in a folder in your GameData) -- https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock But please keep in mind they are currently unsupported for a reason -- I haven't had time to review or fix issues with them in quite some time. As far as I know they work, but I could not tell the extent of any issues that might be present.

Most of the KF wheels (and tracks) have water propulsion. As long as some of the wheel is visibly above the water surface, but still in contact, you'll get some movement ability. One of those neat little hidden features that almost nobody finds or uses

TU does not already have such functionality, though what you are looking for has been brought up a few other times in regards to custom texture packs / recoloring, and it is a feature I would like to have. The problems arise in that it is such a huge difference from the existing methods that neither the existing UI nor the plugin code could properly accomodate it (with the UI being perhaps the more difficult of the problems to solve). With that said -- I will certainly give it some consideration during the upcoming UI redesign (whenever that actually happens...). There are a few other features and changes coming regarding the recoloring and customization end of the mod, and I think the end result will be... well.. something different at least. If you were up for some custom plugin coding... it might be possible to do what you are looking for by leveraging some of the existing TU infrastructure... but I make no guarantees. I've been out of the loop for a bit, and would have to re familiarize myself with the code base before I could say for certain, or give any more pointed tips on where to start. At the end of the day though, the shaders and reflection updates are the important parts provided by TU -- all else is provided only for convenience for the most common use-cases (or what was seen as the most common at the original time of development); it is fully possible to leverage the shaders with fully custom plugin code that doesn't touch any of the other TU TextureSet stuff.

Judging by the slight environment reflections in this picture -- at least some of the new assets appear as if they are using PBR shaders of one sort or another? (is this the stock Specular Mapped shader in use here?) Work looks awesome (and very much of the quality that I'd expect given the source ), just curious on some of the technical bits, for personal reasons (I have long dreamed of a day when all of the stock parts were using modern shading techniques). Looking forward to seeing this develop into maturity; I could likely actually use these stock parts without cringing

Nope, TU doesn't care about texture resolutions at all. It will simply take the texture you specify and put it into the shader slot for the material; it won't even check formats/etc.

Indeed. Sadly, any 'easy way out' would have to come from the PP end of things, in the fashion of something in the configs that would turn off their texture-assignments entirely. ^^ Pretty much this exactly. As a bonus, such a solution coming from PP itself would allow for turning off/disabling of any PP texture-switch UI widgets, and result in less part-action-window clutter. The other alternative would be a custom PartModule that interfaced with the existing TU part-module, but re-applied the textures at a later point in the loading sequence. Could probably end up being quite simple, something like 5-10 lines of functional code. Hmm... thinking on it a bit (but not being familiar with the PP code), this might be solvable with an order-of-patching thing. What does the final config for the PP parts look like, post-MM patches? If the TU texture-switch part-module is the last module on the part, it should run its updates after all of the others (assuming that the updates are being done in the same lifecycle calls between the two mods; e.g. both are using OnStart).

Do you have a Smoothness / Gloss texture? Seems to be the only one missing. (or is it already in the alpha channel of the MET?) Should have five(six?) source textures, which are then compressed into four binary assets to be referenced in the configuration file DIFF (its own RGB) SMOOTH (A channel in MET) MET (R channel in MET) AO (G channel in MET) NRM (RGB) MASK (RGB) The textures that I've looked at appear to be correct for the grayscale based setup. As soon as the smoothness/channel stuff is figured out, you should be able to simply write a config to reference them all and apply them to parts. No. If you need to interact with other plugins, you will have to write your own custom plugin in order to do so (or have that plugins authors make the required changes). E.G. TU -> PP -> Your Custom Stuff In short -- TU is not intended to be able to change procedural parts, nor is it intended to work alongside any other texture-switches. If you need such functionality, you will have to write your own custom plugin code to do it.

Noted -- I'll see if I can come up with some more pointed instructions and/or perhaps a walkthrough video or something. Its certainly not the easiest or most obvious concept to grasp from an external perspective. Essentially though it is as how Electrocutor stated it -- you want the average luminance value of the area covered by each of the mask channels. If you wanted some 'precise' help, feel free to PM me your diffuse/specular/metallic/mask textures and I can run them through my calculation tool (eventually I want to release this tool publicly, but it is not quite ready for general consumption yet). It is also possible to do it manually by using GIMP or PS and a bit of interpolation.

Unknown -- feel free to give it a try, watching your log for exceptions/errors. If no exceptions pop up, then likely it will work fine. As far as I remember there weren't any breaking changes between the 1.4.5 and 1.5.x stock API, so you may be in luck.

Finally got a chance to investigate KSP 1.6 and its 'in-flight environment reflection updates'. It appears that they have chosen to utilize the Unity Reflection Probe for updates, which is logical as there really isn't any other way to do it. The good news is that the stock system is inherently compatible with TU shaders, and that it can be disabled entirely through the in-game stock Settings menu. The bad news is that the stock system is not entirely compatible with Scatterer (untested, but likely EVE as well). Or rather, Scatterer is incompatible with Unity Reflection Probes. At this point there is potentially a choice to make: Disable/remove TU's reflection system in favor of the stock system (problems included) Keep TU's reflection system in-place, allow player to choose stock or TU reflection systems Hack around with the stock reflection system to utilize its reflection probe, but with the TU 'fixes' in place ??? (open to suggestions) For the time being I'll likely be leaving the TU system in place, but add some quick checks to disable it if the stock reflection updates are enabled (no reason to have both going). I'll give some time to see how Scatterer and EVE respond to the stock reflection system. Would really rather love to not have to do the hacky (and bad for performance) fixes that are in place, all of which exist because Scatterer and EVE have issues when the Unity Reflection Probes are used.

Cold and snowy here as well. ~12 inches of fresh snow over the weekend (in the valley, likely was likely many ft in the mountains), with daily high temps of <10f. Only getting started here though, still have another 2-3 months of cold and snow yet to go. Yep, right in the middle of the Rockies, a stones-throw away from Yellowstone.

As @0111narwhalz points out, the best way to make the wheels support larger loads is to make the wheels larger. Kerbal Foundries includes built-in part scaling, so feel free to make the wheels as big as needed. Also as pointed out, there are other options in the mod specifically intended to support large loads -- Large wheels and large tracks. Sounds like you might already be using the larger wheels, but you might try the large MOLE tracks, or simply scale the existing wheels up a notch or two. Finally -- if breaking from 'overloading' is your only issue, you can disable the wheel-break-from-overload functionality in the KSPWheel settings in the in-game mod settings. To provide more pointed information, I would need more information to work from -- screenshots of the craft, and more specifics on the mass.