Shadowmage

Just going to leave these here for the evening... (its nearly ready...)

I should add that I've also given this some thought in the past, as in some way to specify a second mask texture, a second set of user input values, and a second set of normalization parameters. The problem is that at some point, the shader becomes so complex, that you run out of registers (hardware) to store parameters, and end up absolutely killing performance (it will still work, but ends up using shared memory for registers, which is slow-as-dirt comparatively).

No. That is how it is accomplished. Oh, well, there is the problem... (have I ever mentioned my loathing for the PartVariant system? well...) The stock PartVariant system is really not modular, nor is it intended for mods to interact with it from the code-side, so my ability to fix issues with it is extremely minimal. Might be able to use multiple TUPartVariant modules? Can't guarantee it would work right now, but I might be able to make some changes to allow it to function... (you would specify the same texture-sets in each, with different root transforms); would have to examine the data and how to make it all work on the back side of things. I would say to open an issue ticket for the feature request, and I will examine it for my next round of TU updates (might be a few weeks, need to get my other mods updated to 1.9 and fix a few issues in some of them).

I know this is in the 'stock suggestions' thread, but if mods are an option, the Adjustable Landing Gear in the Kerbal Foundries mod include exactly this feature (adjustable static height, + adjustable sprung height)....

Yes, you are free to fork and do whatever you want with the source, as long as you keep your changes under GPL. That's what those licenses are for, and why they exist. I always wanted to have map-mode open on my second screen, full-time. Possibly a third screen filled with all of the orbital parameters and state data. In all of my time gaming though, I think I've come across a total of maybe one game that supported true multi-monitor setups, don't even remember what that was... (supreme commander maybe?).

Seems to me that if you have a known target on the surface, and a known orbit that will cross above that target, that you could work backwards from the ground, integrating backwards until you find yourself in orbit at the desired height. Whatever location that is, is where you should start your suicide burn (I know, easy to say, but I'm not so great at calculus to simply whip it up...)

I understand and appreciate the implications of stock texture use; likely wouldn't be directly compatible with the PBR shaders, and might need additional texture work, certainly not a simple/fast project. Well, if you decide this is a route you would like to go down or look into, and you would like assistance with the setup, just ping me or send me a PM/etc; will be glad to offer whatever help or guidance that I can.

If the models for the buildings are loaded as .mu's, TU can patch them right in the game-database to use whatever shaders and textures are desired.

Glad that worked out for you Yeah, I'd definitely fiddle with the parameters a bit, notably the 'float = _SubSurfScale,3.0' and 'float = _SubSurfPower,6.0' parameters, as they have a massive influence on the final lighting rendering. Take pleasure in knowing that whatever you create that uses this effect, will be quite unique in the realm of KSP mods. Aside from SSTU, this is the first and only other use of the subsurface scattering effect that I've seen, and I'm not aware of any other mods that add subsurface scattering to KSP. 100% correct. That patch is no longer needed; instead you should enable the stock reflection settings in the stock game options menu.

Yes. That is exactly what SSTU uses for its solar panels, a full RBG thickness texture (aka colored lighting transmission map) (here is the actual image used by the SSTU solar panels, extracted and decompressed from the link above): You should also play with the subsurface scattering parameters, as they can have a major impact on the final effect. Best way to set these up is to play around with them in the Unity Editor, where you can use the TU shaders directly, and play with the settings in real-time; its not the most straightforward process to setup, but is great for testing of setting such as these (and is the exact process I used to configure those parts). If this is something you might be interested in, let me know and I can guide you through the setup process (currently not documented anywhere, as so far, no actual mod authors have expressed any interest in TU, and as this setup requires access to the original models and textures, it is not something that stock-patch-authors generally have access to....).

Probably not an issue; most windows have been excluded from recoloring, and use whatever values are provided by the stock textures (or any possible replacement specular textures that were provided). The only way to know would be to look at the mask texture, compare that to the diffuse/specular textures to find where the windows are, and see what the color of the mask is in those portions....

Magic More seriously, you have to provide a thickness texture that denotes the 'thickness' and light-transmission color of the geometry, enable the keyword in the texture-set config for SubSurfaceScattering, add values for the subsurface scattering properties, and enjoy the glowy effects... Here is the texture set config for that part: https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Data/TextureSets/updated/DefaultShaderAssignments-SolarPanels.cfg#L1-L34 KSP_MODEL_SHADER { name = SSTU/Assets/ST-GEN-DSP-ISS model = SSTU/Assets/ST-GEN-DSP-ISS MATERIAL { shader = TU/Metallic texture = _MainTex, SSTU/Assets/ST-GEN-DSP-ISS-DIFF texture = _BumpMap, SSTU/Assets/ST-GEN-DSP-ISS-NRM texture = _MetallicGlossMap, SSTU/Assets/ST-GEN-DSP-ISS-MET texture = _Thickness, SSTU/Assets/ST-GEN-DSP-ISS-GLOW texture = _AOMap, SSTU/Assets/ST-GEN-DSP-ISS-AO excludeMesh = ST-GEN-DSP-ISS excludeMesh = ST-DSP-ISS-Base excludeMesh = ST-DSP-ISS-TopCap keyword = TU_SUBSURF float = _SubSurfAmbient,0.2 float = _SubSurfScale,3.0 float = _SubSurfPower,6.0 float = _SubSurfDistort,0.0 float = _SubSurfAtten,1.0 } MATERIAL { shader = TU/Metallic texture = _MainTex, SSTU/Assets/ST-GEN-DSP-ISS-DIFF texture = _BumpMap, SSTU/Assets/ST-GEN-DSP-ISS-NRM texture = _MetallicGlossMap, SSTU/Assets/ST-GEN-DSP-ISS-MET texture = _AOMap, SSTU/Assets/ST-GEN-DSP-ISS-AO mesh = ST-GEN-DSP-ISS mesh = ST-DSP-ISS-Base mesh = ST-DSP-ISS-TopCap } } Thickness texture: https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/ST-GEN-DSP-ISS-GLOW.dds In short, you are not going to just 'get it to work' on any stock or other mods' parts; it requires considerable effort to set it up properly for already-existing parts (e.g. stock/other mods), mostly involved in the creation of the thickness texture(s). This again goes back to the fact that TU was intended for mod authors to use in their workflow, where they have access to all of the assets needed to create the extra textures and configs, and it isn't nearly as much work (e.g. they already have UV maps and diffuse/specular textures to base the thickness texture on). The SubSurfaceScattering included in TU is based on the work presented here: https://www.alanzucconi.com/2017/08/30/fast-subsurface-scattering-1/ which is further based on the GDC 2011 presentation, as implemented in the FrostBite engine, available here: https://colinbarrebrisebois.com/2011/03/07/gdc-2011-approximating-translucency-for-a-fast-cheap-and-convincing-subsurface-scattering-look/ If you wanted to fully understand the effect and its implementation/use/configuration, I would highly suggest giving both of those links a good read-through.

Which is fine, but to find where the problem is, you will have to get rid of it, at least momentarily. That is the whole point of this -- not to have you permanently remove mods, but to temporarily remove them so that we can also remove them from being a possible conflict.

Texture Replacer works fine I believe. It is 'Texture Replacer Replaced' that breaks stock reflections. Personally don't know why anyone is still using either of those mods, but w/e. (Yes, TU can do Kerbal suit textures; or could before stock added suit texture switching; untested since then...). I think you are on the right track on the investigation -- eliminate ALL possible conflicts, start with ONLY the required mods (ModuleManager, TU, TURD configs), and test with that simplified setup. I'll bet the problem disappears with that setup...

If you want the texture sets to be recolorable, you first need to set the 'recolorable' flag to 'true': You must also then provide a mask texture, such as can be seen below ('texture = _MaskTex,Texture/Path/And/Name'), add the 'keyword = TU_RECOLOR property to material blocks, and add the COLORS block to specify the default colors for the part: KSP_TEXTURE_SET { name = SSTU-SC-C-BPC-A title = Standard recolorable = true MATERIAL { shader = TU/Metallic excludeMesh = SC-B-BPC-FlagTransform texture = _MainTex, SSTU/Assets/SC-C-BPC-DIFF-A texture = _BumpMap, SSTU/Assets/SC-C-BPC-NRM texture = _MetallicGlossMap, SSTU/Assets/SC-C-BPC-MET texture = _AOMap, SSTU/Assets/SC-C-BPC-MET texture = _MaskTex, SSTU/Assets/SC-C-BPC-MASK-A keyword = TU_RECOLOR vector = _DiffuseNorm,0.5,0.5,0.5 vector = _MetalNorm,0.5,0.5,0.5 vector = _SmoothnessNorm,0.5,0.5,0.5 } COLORS { mainColor = white secondColor = black detailColor = silver } } Looks like you have 'recolorable = true', so the GUI will show up. You have the COLORS block, so your default colors are specified. You've even specified the normalization parameters (which may not be correct, if you don't have a mask to use to calculate them). What is missing? The _MaskTex (mask texture) -- this is a texture that tells the recoloring system what portions of the original texture are effected by the 'main' 'second' and 'detail' selections in the recoloring GUI. This mask texture should be RED in portions that will be recolored by the 'main' section, GREEN for 'second', and BLUE for 'detail', and BLACK in portions that are not recolorable. As you have not provided a mask texture, the default is 'FULL BLACK' which means that you have specified that nothing is recolorable by leaving out that texture. An example of a mask texture can be seen here: (on the part) And here is a mask texture (viewed as a texture), this one is for the MK2 cockpit: Yes, in order to make things recolorable you need to get your hands dirty and author textures; at least one per part. The entire system was intended to be used by mod authors, for their own mods' parts, and as such they would already have access to their UV maps and existing textures, so mask creation would be simple. Trying to do the same for stock parts though is... a bit of a pain. Thankfully, @Manwith Noname has already done 99.9% of this work (creating masks and configs for stock parts; the SRB mask example above is from his work), which is available through the TURD thread (and likely has a config and mask for the exact part you are working on, could at least be used for examples for further learning): Please let me know if you needed any additional information on this;

Yes, absolutely, that will bork the stock reflection system (which is what TU uses, and thus TURD). Remove texture replacer, or disable its realtime reflection stuff.

A picture tells a thousand words here. Thank you very much for posting those images. Those parts should be reflecting the shiny blue sky and/or the green grass and buildings of the KSC depending on camera angle. Your issue very strongly appears to be with the stock reflection system, given the stock parts don't have reflections either; could be hardware related, driver related, or could be settings/configuration related. If the tests with minimal mods don't work (as @Manwith Noname is guiding you through), I would suggest un-installing all mods / testing the above parts on a clean and fully stock KSP installation. If the problem exists on a clean stock installation, please seek assistance in the stock KSP support threads. If the issue does not exist on the clean installation, add mods in one at a time or in small batches, testing after each batch, until the problem shows back up; whatever you most recently added is likely the cause of the problem (and information that you could report here, as that might be useful/something we can act on).

TUFX is nearing a releasable state. The in-game config editing UI is cleaned up and very usable; everything except for Color Grading can be configured through the UI (and even it can partially). Profile exporting is in place (it dumps to log file, you have to manually update the physical file(s)). Left to do is figure out why if I even -touch- the Editor camera things go wonky (things start sliding all over, etc); currently I've simply disabled effects in the editors. I also need to create some sort of float-curve (spline) based editing window/system, as well as some sort of ability to specify texture parameters to those effects that allow texture inputs (vignette mask, dirt texture for blur, LUTs for color-grading and a few other effects, etc). Profile selection: Profile editing mode in the UI -- takes a moment to get used to, but it all flows and works quite well, especially considering the sheer number of config values being exposed. Yes, all of these effects work... (not that I'll personally use even half of them, but they were part of the package, so might as well include them as long as they were functional) Will likely clean up the existing stuff and look for some initial 'beta' releases this weekend. Might take me a few weeks to figure out how to deal with the spline parameters and texture parameters from the UI perspective, but both can be manually specified in the profiles if needed (though there won't be any examples of the syntax available outside of the source-code).

Do stock parts that have reflections appear black? Check (and post screenshots of) one of the stock 'shiny' parts in the same scenes and lighting as the tests you posted above, please; like the stock hex probe, or one of the other stock shiny/reflective parts. I've seen another mention of this issue somewhere, but never got much investigation done on it. Basically we need to check if the reflections are totally broken on your system (which would point to a stock/Unity problem, out of our control), or if it something specific to the TU shaders (something that might be fixed).

Let me know when you get to this point / if you need any pointers or assistance. When last I looked at the pack, the recoloring normalization params (and out-of-range color values) looked to be the only 'big' bits needing to be fixed.

I should also add that @zer0Kerbal'z method does work, and actually works GREAT for parts that don't have any special functions or modules; e.g. simple fuel tanks or structural parts. As long as there are no PartModules in it, you can combine as many MODEL nodes in a part as you want, and add as many attach-nodes as you want. Just don't try and weld (manually or otherwise) any parts that use PartModules that require a reference to a transform, animation, or material (90% of the PartModules), as those will fail to work properly due to stock PartModules not supporting multiple transforms/animations/materials and/or not providing any way to specify an 'index within array of duplicates' to work with a single transform when multiple are present. So no landing legs, no RCS thrusters, no engines, no solar panels, no wheels, no robotics, no docking ports, nothing with light/emissive animations, nothing with deployment animations, nothing with PartVariants, etc. The list of limitations is far longer than the list of stuff that will actually work....

The quick answer is: It is not possible without custom scripting. You can't simply rename a file extension, nor is there any direct route to edit the subassembly to make it usable; entirely different file formats and layouts. This was the whole reason that Ubiozor existed. It is also why it never functioned as well as it needed to -- the different formats are simply not compatible, and more importantly, the stock PartModules are not designed to be used in anything but the most basic of configurations. I could write pages on the technical difficulties of the implementation. Heck, if you read through my post history, I have written pages on the subject. Its a mess, mostly due to the stock PartModules, their lack of support for complex part setups, and how 'unreplaceable' most of the modules are (e.g. they are hard-coded into various parts of the simulation and cannot be replaced by mod-added classes).

Yes, having restock installed will either disable or trample over the configs, as they were written for the stock parts and not the restock parts; different models, different textures, entirely different config setups needed. Also note, the 'open recolor gui' button will only be available on specific parts (the ones that have configs written, and mask textures created), and will only be visible in the editor. Please let me know if you find out more. Might also be worth posting up your KSP.log file (to some file-sharing/hosting site), as that might contain additional information on what is/is not working/why.

So, you right-click on the part, press the 'Open Recolor GUI' button, and nothing happens? Or is the problem that there is no 'Open Recolor GUI' button on the part-right click menu? (the first would be a bug with the mod, the second is likely configuration/patch related for whatever set of configs you are using; you are using a config set?)

Looking good; gotta love how the updated shaders actually show some environment light effects on the parts. Something I sorely miss whenever I have to use parts that still use the stock shaders... Excellent work on these conversions. If/when you do start your own thread, you'll have at least one instant subscriber