Shadowmage

Update your KSPWheel to the latest version, that bug is already fixed. https://github.com/shadowmage45/KSPWheel/releases/download/15.13.32/KSPWheel-0.15.13.32.zip

If you are below the static friction point there should be very little sliding. E.G. If the lateral (sliding) force is less than the sticking (vertical) force, then there should be no sliding (that is not the actual math that is used, but a gross simplification). Nothing will stop sliding on extreme slopes though, at least nothing 'wheel' based -- what you need at that point are spikes or active attachment mechanisms (ground anchors), which this mod does not provide. So, the answer should be 'KSPWheel doesn't do any of that silly stuff that stock wheels do'.

Essentially the process should go: Determine which mesh(es) in the pod correspond to the windows. Patch those meshes to use a PBR shader -- the specific parameters will depend on the shader chosen, and the desired look (metal or non-metal reflections) In cases where the window mesh is not separate from the rest of the pod, a custom specular/gloss and or metallic mask will be needed (depending on what shader you are using) Really, that should be it. I think the problem that you are hitting is in point #3 -- many stock parts are not intended for this sort of patching, so will have to make custom masks, which takes time and effort. Which particular parts are you having issues with? Pics/screenshots? This isn't something that I'm familiar with seeing, or have heard any previous reports regarding.

https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock The above patches apply the KSPWheel modules to the stock wheels. Download them and place them somewhere in your GameData/ folder. Note: They haven't been tested or updated in quite some time, so I cannot guarantee how well they work. At the very least, it is a good place to start though

Yes, it was added in the ~KSP1.5 era I believe. Not likely. There were breaking changes in the KSP API between 1.3 and 1.4 that will prevent many mods from being backwards compatible. You can always give it a try, but there are no guarantees that it will work (it shouldn't break anything else, would likely just fail to load).

Not that easy. In order to 'remove' the PBR -- I have to completely redo all the textures to use the legacy shaders first. Basically I redid _all_ of the models; fixed geometry errors, optimized meshes, re-rigged them, UV maps updated for better efficiency, and I then made PBR textures for the new models and UV maps. People then say 'I don't like shiny new things', so I'm stuck with having done ~100 hours worth of work, that apparently nobody wants. And needing another ~100 hours of work in order to get the old textures back (which I don't want). ^^^ Is why the mod hasn't been moving much lately. I really don't feel like spending time working on things that others don't want, and I _really_ don't feel like spending my time working on things that _I_ don't want. Had I known in advance there was such widespread hate for PBR textures and modern shaders... I never would have started the model rework project. At this point it would actually be faster to just revert the entire mod to the pre-PBR updates, and deal with the existing model issues -- which is likely what is going to happen for future updates.

No worries; its a recent addition for the KSP 1.6+ 'testing' versions of Kerbal Foundries. Actually still undecided if it will be a permanent dependency -- the reception of the PBR textures has generally been 'disliked', so it might be removed in the near future.

For the most recent releases, TexturesUnlimited is a requirement; it _should_ be included in the downloads.

I think you might be correct. Unfortunately I do not offer any such options. PBR is now the 'standard' for SSTU, and how I intend the mod to be used. I cannot offer support for any alternate setups or configurations, nor could I even say if its possible to disable reflections entirely without running into the exact issues you currently are seeing (any time you disable reflections... things will go black; that is how the new shaders work).

Apologies on #1 -- Apparently there are/were still some patches using that name, which I interpreted to be the folder name. Further investigations show that this isn't being caused by a folder. #2 should really only impact those three engines, and shouldn't have the effect you are seeing elsewhere. I'll go over the log again and see if I can spot any other errors. As I'm not seeing any other major exceptions/errors in the log, about the only other thing that I can think of is that your GFX might not be capable of the features that are being used (cubemaps/reflections), though normally there are errors posted in the log when trying to use those features.

Yes, it should.

Thanks, that worked Few things from the log file that might be causing issues. 1.) You have 'SSTU-PBR' installed. Remove it. It was a texture-expansion used by previous versions of SSTU, and is no longer needed (and will cause issues). This is likely the cause of your messed up textures. 2.) You are missing some stock part models which are causing loading errors (using Restock?). Notably the stock NERVA engine is missing. This issue likely only impacts those specific SSTU engines that use the stock model.

Thanks -- looks like you've set that file to not be shared though (private only?). I get a 'forbidden' error when I attempt to download it.

I hate to jump on the bandwagon for this one, but indeed, this is a case of the issue laying entirely at the fault of the Unity game engine (or rather, PhysX, the physics library used by Unity). No matter how hard the KSP devs try and solve the problem, the best they can ever hope for is going to be 'less buggy than the default'; polishing a turd as it were. Basically Unity released an engine with 'wheels' that were only intended for very basic vehicle use, in the complete absence of joints, with all transforms being rigidbody alligned, and with a very narrow range of stability for a specific preconfigured purpose; and never at all intended for the widely varied uses that they are put to in KSP or other lego-like games (pick any Unity game that lets the user create randomly wheeled bodies, and they all suffer from the same/similar issues). PhysX (the physics system used by Unity) wheels are intended for vehicle use in games like Gran Turismo, or GTA -- a single rigidbody with 2/3/4/6/8/12/18 wheels. That is it. Anything outside of that use-case is not intended, not supported, and likely to be a bug-ridden mess. KSP wheels happen to fall into the latter category (the buggy mess end of the spectrum).

Please provide a link to an uploaded KSP.log file -- there is definitely something not loading properly in your install, though I couldn't say what just from screenshots. You may upload this log file to various file-sharing sites (pastebin, dropbox, etc), and then post the link here.

Updated release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.11.47.159 Mostly just a recompile for 1.7. See link for downloads and changelog.

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.4.7.21 Simple recompile for KSP 1.7, no other changes. Honestly, I'm not sure; I don't keep track of previous KSP version compatibility. However, each of the releases contains a .version file so that might be your best option. Likely the 1.0.x releases would be in that time range.

Updated release is available: https://github.com/shadowmage45/KSPRescuePodFix/releases/tag/1.6.4.14 Recompiled for KSP 1.7; no other changes.

Updated release is available: https://github.com/shadowmage45/KSPWheel/releases/tag/15.13.32 Basic recompile for KSP 1.7 + add optional resource use to ALG parts. Should be fully compatible with existing saves.

Just a heads up that I'll be putting out an official 1.7 recompile/release over the weekend. Aside from the recompile it will likely contain a handful more fixes for recently reported issues, but won't have anything more substantial. Should be a direct update and should not be game/save/craft breaking in any way.

Really this brings to light the major issues with the drag cube system regarding engines, and the discrepancies between them (or rather, the issue with basing drag on attach nodes at all; it should be entirely geometry based, nodes shouldn't figure into it). Sadly, it really just makes me want to start putting nosecones on the back end of my rockets' engines as well....

So, basically, you are asking me to do all of the work for you on re-texturing hundreds of parts across multiple different massive modpacks (none of which I made, or even use, half of which I don't even know what they are)? Umm.. No. Just no. How about -- if it is truly that big of a deal for you -- put forth the effort and do it yourself?. Should only take a few hundred hours worth of work. Or alternatively, you can hire me to do the texturing work, but as I actively hate doing it, you probably won't like the cost (esp. not for hundreds of hours of work)....

Actually, if the features of TU are used properly, then yes, this mod allows for full recoloring of parts. Complete and full user control over the base color of a part, with support for up to three different 'sections' per part (actually, it is unlimited on a part, but only three per each mesh/material). For examples of this see SSTU -- the parts in that mod are fully re-colorable, not just tinted. Nobody else has tried to use it properly though, which is why you end up with the 'tinting' setup used by other mods. Mostly because to 'use it properly' requires actual work be put into creation of the masks and color normalization parameters, work that nobody wants to put forth. So, does this mod provide 'plug-and-play' recoloring of stock/other mods parts without any additional work? No. Can it, provided proper textures and configs, allow for recoloring of any part? Yes.

Blending effect is looking nice, though I might perhaps blend it in a bit slower / over a longer duration so the fade-in isn't as visible. Tricky finding the best setup for determining that factor though, a lot of variables at play to pick from / play with.

The steps are basically: 1.) Install Unity Editor 2.) Use your favorite text-editor to create .shader files. Unity compiles these .shader files into usable shaders. The shader files that you downloaded and are reviewing are probably the best example of these. You might also examine the .shader files that are included in the KSPPartTools asset-pack, as these give a bit more information on what special functions are implemented and used by KSP shaders (all shaders for KSP need special handling for 'edge highlighting' and KSPs' 'fog setup'). 3.) Play around in Unity Editor until your shaders work. If they work in the Editor they should work in KSP. The important part is to do your development work in the Editor, as it is not feasible to do the 10 minute asset bundle->launch KSP cycle just for testing. 4.) Pack your final .shader files into an AssetBundle. Unity will compile binary versions of the shaders and include them in the bundle depending upon your current graphics API settings in your editor. 5.) In a KSP mod plugin, use some code to load the asset bundle, extract the compiled shaders, and then us them for creation of materials. This is one part where KSP is not really compatible with external shaders -- any use of them has to be done through plugin code, as internally KSP only uses Shader.Find() for lookups, and that function will never find and return shaders loaded from asset bundles. Basic details on surface shaders can be found here : https://docs.unity3d.com/Manual/SL-SurfaceShaders.html Which is about the extent of the reliable references I was able to find when I was learning this stuff. You can try googling for 'Unity Customized Standard Shader' and that might return more info about specifically editing the standard shader internals. Yeah, I've never found one. Currently I use Notepad++ with a customized/modified C++ language spec to support some shader-specific syntax and keywords. Its brutal trying to trace things through the Unity shaders without 'find reference' support... I've no experience with the SRP myself, but you may be correct -- if this is adjusting low level functions of the rendering, it may well need to be inserted into the Unity rendering stack somehow. If I'm understanding things correctly -- this might even allow it to be a 'generic' solution that worked for all shaders instead of just specific ones with the 'fixed' code.