Shadowmage

Updated release is available: https://github.com/shadowmage45/KerbalFoundries2/releases/tag/2.4.8.18 See the link for change-log and downloads. Note to users of the KSP 1.6.x versions of the mod (with legacy textures): Do not update to this version if you want to keep your existing game intact. Part names have changed, and will break nearly everything. If you still wish to proceed, delete the entire existing KerbalFoundries folder before installing the new update; many file-names were changed as well, and merging the installations will result in numerous problems. The legacy part-configs and textures will continue to work into the future. You can continue to use them if you don't like the new textures, or any other reason. The old releases will still be hosted and available for download. Keep the KSPWheel plugin up to date (for whatever KSP version you are using), and they should continue to work for the foreseeable future. The other side of this is that I will not be doing any balance changes or model fixes to the legacy parts/models/textures; they will be frozen in time, and more-or-less unsupported.

After replicating the craft more closely, with two sets of the wheel pairs on each side... it strangely seems to work fairly well with only a single tweak -- decrease the motor output to ~10% on each motor. For some reason the motor is extremely overpowered on those wheels, and is prone to simply spinning out/sliding. I probably need to re-balance them at some point... If that doesn't work out for you -- do you have a .craft file I could check out? Preferably a stock + KF only craft, if possible. I say 'strangely' above, because I'm pretty sure that some of the motors are fighting each other during steering operations, but it still steers acceptably. Going to have to do some 'suspended in air' testing to see exactly what is going on and which motors need to be reversed (if any), as when it is on the ground the tires might spin with craft movement even when the motor is pushing in the opposite direction. Hmm.... Edit: Everything spins in the right direction, visibly at least. No problems with motor fighting that I can see. Anyhow, I've got a release to work on

Two issues here that I can think of from the description and image: 1. SAS. Turn it off. Pushing 'W' with SAS (err.. reaction wheels at least) enabled will attempt to push the nose into the dirt, forcing more friction on the front tires, and thus you'll get oversteer. This is not really a problem if you use separate rover and rocket controls (e.g. remap the rover controls to use the numpad or arrow keys, etc), but with the default control scheme it can certainly cause issues. 2. Those wheels were not designed to be used in that configuration; they were designed and rigged to be used with one set of wheels per-side of the craft (total of two pairs; one left, one right). Essentially those wheels include some 'tank steering' mechanics and other special configuration that will cause problems if attempted to use as 'normal' wheels (you could actually think of them as a tiny set of tracks, as the rigging and mechanics are similar). Basically, due to the intended use compared to the use in the images, the steering on the wheels will be fighting each other in the default configuration. A few other things you can try would be to set the 'tank steering' to 'locked' (i.e. disabled), or play with the 'half-track' setting (half-track relies on tank steering, but changes the steering mechanics you press 'reverse'). There are also -two- motor controls visible in the right-click menu (one for the front wheel, one for the rear); you could try configuring it such that only the frontmost- and rear-most wheels in the craft are motorized, essentially fixing up the existing 'tank-steering' rigging. Or, invert the tank steering on some of the motors. Yes, the specific part that you picked for wheels is probably one of the most complex wheels in the mod to learn how to configure and use, and also one of the most specialized parts available. I would also try replicating the craft using more standard'ish wheels (not the prebuilt 'pairs'); if they are too large, use the built-in scaling functions to shrink them down. I would wager that the issues you are encountering are likely due to the specialized nature of the wheels, and how they are not being used in the fashion to which they were specialized. If you really wanted the multiple-wheels-per-side look, perhaps try out one of the track units (again, use the scaling feature if it is too large/small). For example, this little beast doesn't really exhibit any unexpected steering quirks (same as above, very roughly, but with only a single set of wheels per side, slightly scaled up).

What you show in the stock config should be all that is needed for recent TU versions (I think starting with KSP 1.7?). If using older versions (~KSP 1.6), TU had its own reflection handling system, but was enabled by default. Very strange.... That is usually the indicator that the stock reflections need to be enabled. Can you confirm that they show as enabled while in-flight?

Unfortunately 'life' got in the way of my plans yesterday re: the KF update. The good news is that I didn't encounter any new or unexpected issues during testing, and further good news is that I should have a few moments tonight to package up and publish the update. This is mostly just a repackage and recompile; there are not any fixes included for this current update. I do intend on investigating the reported 'GC stalls while wheels are in the air' issues, but as those are likely to take some time to work through (weeks), I would rather release the existing (fairly functional) codebase as-is.

Ahh, yeah. The import/export plugin was never fully finished; always has been some issues with it. But it is great for what I use it for, and is far better than the alternative (nothing). Good to know; might have to d/l some recent versions and give it a spin. Been working with 2.7.X so long... Would be really good to be able to set up and preview some PBR materials from within Blender, without having to resort to setting up the whole Substance pipeline.

That log file appears to be very old; KSP 1.3.1 and Unity 5.4-something. Try the KSP.log file that resides in the same folder as the executable; it should not only be more up-to-date, but is also in a much more usable format (less whitespace/garbage in the log). I can also tell from your screenshots that you have the stock reflections disabled (engines and other parts are black); if you change the stock reflection update option from 'none' to 'low', you'll get a much more pleasant look on all of SSTU's parts. Strange; wonder if that is somehow the version that I used for testing yesterday? Thought I grabbed the 'latest', but could have been a bit older. I'll do some further testing on this; I really only tested four engines yesterday -- the SRBs, the RS-25, RL-10-B2, and the SC-C-SM engine. None of those had issues, but I'm not seeing any of those in your testing screenshot either.

Oh, yeah. That is something you should be aware of when using the Blender Importer. Blender does not support duplicate transform names, period. So if a model has duplicate transform names, they will be renamed with the .00X suffix when imported into blender. You should always get the transform names from in-game, using a tool like DebugStuff -- that way you know you are getting the exact names as loaded by Unity (which are the same names that TU would see). Glad you got it sorted out though Is there a new in-KSP tool for exporting models for Blender, or were you referring to the blender import plugin? Is that the newer version of Blender that I see you using, with actual in-viewport PBR shading support? Been quite awhile since I've kept up with their updates, but I heard they were working on bringing it up-to-speed for use with modern rendering techniques. How is it working out for you?

Updated release is available; mostly a repack and recompile, but has a few fixes in some of the dependencies (TU/KSPWheel) https://github.com/shadowmage45/SSTULabs/releases/tag/0.12.50.162 See the link for change-log and downloads.

Made some headway on the icons Will likely have an official KF release for KSP 1.8 a bit later today (warning: it will be the version that uses the PBR textures; the old versions will continue to work if you manually update the KSPWheel plugin).

Managed to make some progress on the icons; put in some hacky guesses at where the light/color multiplication stuff is at, which now gives: (using albedo multiplication) Also managed to fix the clipping issues with the icons. Doing more testing on various aspects; if all goes well, should likely have a release in a few hours. I tested this a bit and didn't run into any issues; you need to be using both the latest RealPlume and Smokescreen though, as there were some 'recent' changes to both that are needed by SSTU.

Updated release is available for KSP 1.8 compatibility; also fixes a few icon-shader related issues. https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.5.9.24 See the link for full change-log and downloads.

excludeMesh = Base.001 //Model A I think that the inline comment might be effecting this? I personally haven't tried those. Other than that, it should be working like you have it configured; exclude the mesh from one config, and include it in another. If it isn't actually excluding it, then your list of suspects is pretty much it; typos, or bugs. As the command seems to work well most other places, it would have to be a weird/complex bug for that to be the cause.

Indeed, and about time, right? Thx for the report on the engine plumes/sounds. So far I'm testing with minimal deps, and sounds and plumes are working in stock; but I'll keep it in mind to check the RealPlume stuff before I publish an update.

Not on your end; it has to do with the 'icon shader' system in KSP, and lack of source to the stock versions of those shaders. So when I had to create my own versions for the PBR shaders, I cannot fully replicate some of the internals on the stock version. Notably, there is a parameter '_Multiplier' to the shader that is not documented anywhere. Pretty sure it is used to boost light/brightness, but not sure how/where it is used. Does it multiply the light input in the lighting functions? Does it multiply the sampled texture colors? Does it multiply the final computed pixel color at the end of all pipelines? Who knows (well, SQUAD knows, but they aren't talking). However I _may_ have a solution in the works that should be closer to the stock shaders. While I was fixing up some issues with screen-space clipping coordinates, I went ahead and added some albedo color multiplication to the icon shaders; should be _closer_ to whatever the stock shaders are doing. Hopefully should know more a bit later today.

Finally got a few moments today to work on modding affairs, and the good news is that generally most things seem to be still fully functional; no code changes needed so far. There was however an issue with the procedural fairing shading, which after a few hours mucking about with the generation code, turned out to be a simple issue of a missing normal map texture... a quick config tweak later, and it is back to working as intended Still investigating and cleaning up a few things with the part-icons in the pop-up tooltips, that are getting cropped incorrectly. I've verified that this is something in the shader itself and not in TUs replacement code, but I'm yet to track down the source for the stock icon shaders, so have no reference to how they are configured. The issue itself is odd, because it manifests differently depending on how you flip and scroll through the editor tabs; sometimes a part-icon will get cropped, sometimes not; leaving the editor and re-entering, and performing a different set of actions with the editor tabs and scrolling will manifest in a different set of parts being effected. Very strange to say the least.

Strange, if the issue was caused by TU or SSTU, removing them should rectify the problem. However, if the issue was being caused by Procedural Fairings/etc... then you will have to look there for the solutions. (and the specific error in the screenshot was caused by Procedural Fairings)

QFT. My vote is pretty much summed up in the above. But I would go a step further and say that part-count and craft size should have no noticeable impact on performance. 10 parts, or 1000 parts, should perform the same. That is what I want out of an updated engine. (Being a developer, and knowing a few things about physics sim coding, I fully realize that what I desire is technically impossible; any added complexity -will- impact performance; the KSP2 dev's duty, is to ensure that this impact threshold is below that which would be noticeable, by actually optimizing for that goal, rather then just using 'whatever Unity provides')

Been quiet for a bit, and about the only thing I can add at this point is 'Promotions Suck'. I mean, getting paid more is great and all, but... having a life would be good too once in awhile. I suppose that is the real trick, finding the balance between the three (work/life/fuel for barter). I do still intend to fix up an official 1.8 release, probably about the time 1.9 drops with how things are going, but it is still in the plans. Now that the holidays are done and all the obligations they bring, I'm truly hoping to have a day or two to spend on coding and cleanup; likely shouldn't take much longer than that, as most everything still works as-is, just needs recompiled/packaged/labeled as compatible. And then I found out yesterday I'm getting another promotion in the near future. Yay? At least this one might, perchance, lead to a bit more 'free' time on occasion; but I'm going to work on getting updates out before then, just in case.

Already looking pretty good. If interested, the TU dev version has an updated UV-exporter tool, that will generate the UV maps for you as .SVG files. Hit me up with a PM if you wanted more info.

^^ Pretty much that. To be clear -- SQUAD could implement their own custom wheel system (and I fully believe that they should have once they knew the extent of the breakage with the Unity wheel system), in the same manner that KSPWheel has been implemented. Likely they could even do it better, having tighter integration with the base KSP source code. Why they continue to invest man-hours in band-aid style hacks to try and clean up the issues with the Unity Wheel Collider also doesn't make sense to me. In likely a small portion of the time that they've invested in the fixes (and dealing with the deluge of bug reports concerning the problems), they could have implemented their own wheel system, had the entire thing directly under their control, and could have provided players with a working and non-frustrating option. Alternatively, depending on how invested SQUAD is in the Unity engine, I believe there is an option to allow source-access to the engine, at which point they could possibly have actually fixed the problem, properly, at its source. This is mostly speculation though, as the problems actually lie in the PhysX middleware package, which may or may not be editable with a Unity source license. Regardless, to implement their own or fix the Unity systems, they would have to have someone knowledgeable in wheel and vehicle physics (which I speculate is why they tried to just band-aid the existing stuff; lack of expertise to roll-their-own).

Ahh, yes. Certainly a viable effect, one that I've used on occasion (in Kerbal Foundries, on the track parts); though for my uses, I animate the properties directly through plugin rather than a pre-compiled animation. But a precompiled animation should also work. It sounds like the problem you are running into is in fact due to the animation itself, and not necessarily the shader. Likely that those properties are simply not supported by the PartTools system. What @xEvilReeperx proposed is indeed the solution -- import your entire model through an AssetBundle, where you can use any kind of animation that is supported in the Unity Editor. Of course, it is yet-more-steps in what should be a simple process, but such is the nature of workarounds. (TU can _also_ load asset-bundle based models if needed). So, in short: to accomplish UV animation on a non-KSP shader you will need custom loading from asset-bundles. First a custom loader for the shader itself, and then a custom loader for the models (that may or may not need to restore texture references depending on how everything else was structured/compiled). If the above is not enough information, please let me know and I can dig into more specifics. Sounds like what you are desiring to do should be entirely doable, might just be a bit of work getting there.

Assuming you are talking about the physics implementation -- it is quite impossible, given the changes to the underlying physics engine. This is entirely out of the control of SQUAD, and is a travesty that was pushed upon them by the Unity team (who themselves released a terrible Wheel Collider and vehicle system). SQUAD has done the best they can to polish and put glitter on the turd, but it will always be a pile of excrement; no amount of polish/glitter/band-aid patches will change that. The closest you will come under modern KSP versions is using KSPWheel for your wheel-related parts. ( https://github.com/shadowmage45/KSPWheel/releases/tag/0.16.14.33 ). This mod was written specifically to mimic the functions of the old (Unity4) wheel-colliders, and to no do any of the silly stuff the current stock wheels do. Not going to say that KSPWheel is perfect, because it is not, but it is far better than the stock wheel code for nearly every conceivable use. There is even a stock-part-patch to 'fix' the stock parts (untested/un-maintained in quite some time; use at your own risk) ( https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock ) TLDR: This is probably the single-most requested 'change' to KSP in regards to the wheels (i.e. make them not terrible); if it were possible, I'm sure SQUAD would have fixed them literally years ago. However it is not under their control to fix, and is a problem with Unity itself.

I'm not sure on that; good question. Good idea either way; you would always want your shader loaded before the parts are loaded. That is what TU does, and has no issues with applying shaders to parts/etc. And yes, you -will- need custom code to apply the shader to your parts; KSP's PartTools/PartLoader absolutely will not apply non-KSP shaders. In fact, if you are interested, TU can likely handle all of your shader loading and applying of shaders to models (it is what it is meant to do, after-all). If you would like more information/further instructions on that, please let me know and I'll work something up. Now, I'm not sure on animating of shader properties for non-KSP shaders; I've never tried it. It would depend on a lot of internals that I don't have access to -- does KSP PartTools export/encode the animation keyed on a property name, or some internal property id number? Does Unity itself use a property name (string), or an id number when manipulating the animation at runtime? If they both use property names, likely it will all work fine. If they utilize some other method... I'm not sure how it would be made to work. (I've seen issues with Unity ID numbers before, in regards to layer/tag numbers and how they are generated at compile time by the editor, not matching up with id #'s for items added at runtime)

Its 'whenever I get the time in my busy life to spend some time modding on a game that I haven't actually been able to play in ~9 months'. Could be this weekend, could be sometime next year. It'll be out when its out. Basically right now I'm working on tracking down some long standing mysteries with regards to external mod interaction, and cleaning up a few edge cases on material handling. This is slow work -- long cycles of adding some debug statements, relaunching KSP, and waiting ~5 minutes for it to boot up, just to read through a log file for another ~10 minutes to look of oddities. Worse yet is when I actually need to make changes to shaders -- those take about ~25 minutes to recompile in Unity, another few minutes to package up and update the in-use version, and then still longer for KSP to start up. The other side of all this is -- the current/previous/published versions appears to work in 1.8, so nothing is stopping you from using it (which is also why I'm not in any huge rush to do a release; if it isn't broke, no need to 'fix' it).