Shadowmage

At one point, yes, but the USI-LS patches have not been updated in ages, so really no clue at this point.

Ahh, that is a PhysX quirk that I haven't been able to work around yet (or likely, ever). Basically it gives some sort of a bias to torque output based on direction / order-of-updating, which then gets compounded because the 'faster' wheel starts to slip, then spin faster, slip more, spin faster, slip more, etc. ( https://github.com/shadowmage45/KSPWheel/issues/9 ) Thinking on it -- kind of realistic given the insane power output of the wheels in the mod. Like stomping the gas pedal in an old RWD muscle car -- the rear end just wants to go first If you reduce/lower the motor output such that your slip ratio is minimized during accelaration the effect should go away (or become much less noticeable).

Did you place the wheels using the mirror-symmetry tool in the editor? If not, you will need to right click on the wheels on one side of the vehicle and reverse their motor. Either way -- that is the solution -- reverse the motors on the wheels on one side. Which side will depend on craft orientation/control transform orientation.

Possible -- most likely. Was not the intended use for those parts, so was not included in their functionality; and as they are 100% custom code for just those parts, there is no transference of functions from the standard KSPWheelDeployment module. I'll have to give it some thought and make sure it could be implemented in an optional/non-invasive manner. If you open up an issue ticket on the KSPWheel repository, it'll ensure I don't forget about investigating it for the next round of updates.

Have been a bit quiet of late, because, surprise... life (meaning work) decided to get a bit crazy again. Still in the process of reworking the part balance, not really much done since the last update. Once I can get back on track, should hopefully only take a few hours to update the part configs, and will likely take longer to do the testing and refinement after the initial changes are put in place. Really hoping to be able to take a few hours this weekend to finish this stage up, but can't promise anything. Will try at least to get the configs updated and a new testing release packaged so that some external testing might be done on the updated config balance. The next step after the rebalance pass will be baking and conversion of the legacy texture sets, and determining the final packaging configuration. I currently intend on offering three different texture packs -- 'standard PBR', 'high-res PBR', and 'legacy', but am unsure on how to publish these in a manner that will be easy to install for users, easy to update for users, and not a complete pain to package on the development side. The real question in this comes down to -- should the 'standard' and 'legacy' packs be treated as entirely separate packages, or should the 'legacy' pack require that the 'standard' pack be first installed? Whatever is decided upon, it must also accommodate the potential for additional texture sets to be added in the future in an 'expansion pack' sort of format. I'm leaning towards the following folder format, but may still change it up a bit before finished -- KerbalFoundries/Parts //all part config files KerbalFoundries/Models //part model (.mu) fies KerbalFoundries/XXXXX //other existing subfolders for effects/etc KerbalFoundries/LegacyTextures // when installed, legacy textures and their texture-set config files would reside here KerbalFoundries/StandardTextures // when installed, standard res PBR textures and configs would reside here; the high-res pack will overwrite these file-names; or could optionally be its own folder KerbalFoundries/ExtraTextureSet1 // additional texture sets would be subfolders, and would each contain their texture files and config files This will allow for each 'texture set' pack to be installed separately. Specific packages could be made for each of the 'standard' and 'legacy' packs that contain only those textures, so the user can choose to install either PBR or legacy textures. Any additional texture sets could then be easily added/merged into the existing KerbalFoundries root folder, allowing for expansion texture sets to be self contained in their own folder, easing the installation and maintenance of those packs.

I'm totally fine discussing shader related topics here. Can't really think of any 'better' place on the forums, esp. if the conversation has some relevance to the functions of this mod. Thankfully, not much TU's customizations only really extend as far as some texture sampling and color blending to adjust the output color (the whole 'recoloring' feature), with the rest of the shader being a slightly trimmed-down version of the Unity Standard shaders. I only touch lighting calculations in my SubSurface shader implementation, and even there I don't change anything (just use the provided values differently). So whatever you dig up on the Unity Standard shader is most likely exactly what is going on with the TU derivatives as well regarding lighting and shadows. Seems like you've dug into the code side of it a bit further than I have. I started trying to trace it through the code, and got slapped by the lack of a proper IDE for reference following across their tangled mess of .cginc files and #IFDEF preprocessor macros. (Is there an IDE for shader code? I've never ran across any decently functional implementations) You might not be too far off on your proposed solution, though I'm personally unsure as to how to test it. Fairly certain there is a way to 'modify' the built-in Unity shaders, but don't off the top of my head remember the process -- need to find where the source files are stored in a default Unity Editor installation, and likely edit those files directly. I might investigate what the 'FragmentGI' function call is doing though -- that is where the per-fragment (pixel) output values would be calculated, and might be a more proper place to apply the specular effect modifications. One thought stems to mind though -- the modification to a specular value for a fragment should only be done to the portion of the specular value that is attributed to the specific light source casting the shadow, and as specular reflections are very view-dependent, this adjustment factor would need to be calculated for each light source and be able to be applied to just that lights portion of the specular value. So, at the time of specular light calculation, one would need to feed in the shadow attenuation for the light source being dealt with in order to properly modify just that light-sources specular contribution. If it could be made to work though -- I think it would be a very worthwhile modification. Has always bugged me to see reflections on geometry that is occluded from the light source....

Thanks for the report and confirmation. I've opened an issue ticket on the subject, and will investigate / fix up for the next release. https://github.com/shadowmage45/SSTULabs/issues/772

One would think so... But shadows and specular highlights in Unity are calculated at different points in the render pipeline, where specular highlights are based on the angle of the surface, light angle, and view angle relative to the two (diffuse lighting also works similarly, but the shadows are often enough to make the diffuse-lit area seem shaded properly). Shadows are calculated in a different pass (from the perspective of the light), and then 'overlaid' on top of the data from surface calculations where the shadow cast by the light overlaps geometry. So rather than the specular highlight being blocked by shadows... they just become dimmer as the shadows are overlaid on top of the precalculated surface lighting info. (the above is a gross simplification of the render pipeline used by Unity in Forward Rendering mode, and as such may not be entirely accurate from a low-level technical perspective; if my understanding is 'completely wrong' feel free to correct me w/links to source/reference material)

I haven't personally noticed any issues, but could be that I simply haven't tested it. You are referring to the interstage node that is present when adapters are in use, correct?

What problem? Link to the bug report/issue ticket? (images != link) And, if you bothered to read the ticket, I _did_ fix one of them, and then noticed that the other two needed fixing after I had published the release. Which is why the ticket is still open. If you care that much, put together a PR to fix it and I'll merge it in for the next release. But bugging me in such a fashion about absolutely trivial stuff like this is only going to accomplish one thing. Welcome to my ignore list. Thanks for playing. Nope, mod is still in active development. I will not provide craft files until mod is 'finished'... and likely not even then as I don't believe in using others craft designs. Please report the issue on the bug tracker.

Not really, at least not in KSP -- its a base part of the rendering engine and how lighting is calculated in Unity, esp. when reflection probes are used. AmbientOcclusion textures provide 'baked in' information regarding specular reflections, but stock parts don't provide that texture. Basically what would be needed to really fix the issue in a geometry-agnostic way is real-time raytracing... which is just barely starting to be a thing.

No worries from me -- the samples/data should still be there whenever you can get to it. Might even be more functional/complete by that time

Understood. Any information you can provide is appreciated -- really would like to get this issue fixed up, if I can ever figure out what is causing it (and why I'm so far unable to replicate it). Most likely it is some difference in what is being tested (craft design or use-cases), or a hardware related difference. My dev computer is decently powerful, so it might be that I'm just not seeing the stalls that impact others, or if I am encountering them that they are simply below threshold of perception.

LoL; stock code sometimes .... One might wonder why toggling a bay door would do anything with or to cameras. Unfortunately, I know the answer to this one all to well.

Well, you are not the first to report such an issue. But neither has anyone else who reported been able to provide means of replication. I've done lots of testing on various pieces and have never hit any out-of-the-normal stuttering when using them. Likely a difference in hardware/configuration that is causing the problem to be more apparent to some people. I'm normally very cautious regarding potential stuttering issues; GC lag has caused me to do some crazy things to fix it in the past. Do you have a stock + KF only craft file that causes the issue? Does the problem exist in a stock game with only KF and dependencies installed? Be glad to fix up any problems, but first I have to know what those problems are. Which means being able to duplicate the issue, reliably. So... more info please?

Pretty much. The max traction for a wheel is determined in majority by the downforce, which on an airless body comes entirely from gravity (or downward momentum... from gravity). Low gravity = low downforce = low traction. In a static setup (e.g. not landing after a jump, just sitting still or driving normally), MaxFrictionForce = Downforce * CoefficientOfFriction where CoefficientOfFriction depends on the tire material and surface qualities, but in the best cases generally peaks at around a ~1.2 muliplier for the stickiest of tires on the roughest of surfaces. I took that 1.2x scalar and made it the default for all wheel simulations, so in theory, the friction output is already at peak without any further adjustments (assuming the simulation does everything else without error). I should also mention that decreasing the torque output can result in higher apparent traction. Less slippage due to wheels breaking loose / less spinning of wheels = lower slip ratio = more force transfer between surface and vehicle.

The blue icons is a stock KSP issue when running DX11. TU does its best to fix this problem even though it shouldn't have to get involved. However, if you find that there are some parts that are not being 'fixed', you can add the current shader of the part and its 'fixed replacement' shader to the following list (by patch or manual edit): https://github.com/shadowmage45/TexturesUnlimited/blob/master/GameData/000_TexturesUnlimited/Shaders/TUShaders.cfg#L66-L143 Darker icons are being caused in part by a change to lighting model. It is to be expected with a more realistic lighting setup. Might be fixable, if I cared... which I don't. I thought the stock icons looked terribly washed out and overbright to begin with.

Because traction isn't really something you can just 'adjust'; much more of a physically derived parameter than say, spring stiffness. The values stock uses are ranging in on the 'absurd' end of things; like rolling balls of glue. But, you can adjust them in at least three different methods. First, in the in-game settings for KSPWheel there is an option to allow for applying a multiplier to the friction for all wheels. Second, you can patch specific parts to have different friction curves. Third, in each part config file, there are some friction multipliers you can adjust (pop open one of the track files and take a look). If you need specific examples of each, I might be able to dig them up, but it won't be fast.

Thanks, and glad to hear you are enjoying the mod and its intended purpose Has been (and continues to be) one of my longest running modding projects; hope to continue offering a unique experience for some years in the future.

Just changes to KF stuff; basically just refreshing models and textures and a few other minor cleanup bits. Other mods using KSPWheel should be unaffected unless they were using the specialized KF-specific modules (APU/Repulsor). They are otherwise free to make use of the new features, but those features are optional where implemented. Its about 90% there right now -- but I have no intention of supporting multiple releases (no time, nor desire). I think there are only 1-2 part names that overlap, so if someone _really_ wants to use the old version alongside the new one, they should also be motivated enough to figure it out and get it working. The old release will continue to work as long as its plugin is kept up to date, so its not like there is any forced breakage here; one could choose to simply continue to use the old version until ready to start a new game, then switch to the new one at that time.

In development news: APU got a new smoke particle effect, as I've implemented an asset-bundle loading system to allow for creation of particles in the Unity Editor and loading into game fully configured. I'm a complete newbie when it comes to particles... but I think it looks sufficiently smoke-like for its intended use. Repulsor effects are now loaded through AssetBundle, so could technically be replaced/swapped out. Also using a new particle texture for better visibility. Repulsors not turning on properly has been fixed. Apparently the new stock function call for getting resources from a part differs in functionality from the old deprecated function, and was failing out when trying to pull EC. My bad for trying to clean up the use of the deprecated function... (at some point I should find out how the new function works and use it.. but for now... back to using the old stuff). Initial (re)balance pass is underway, with everything being re-balanced relative to stock parts. Mass, cost, motor torque, and max speed should all be comparable to stock parts. I've realized that stock doesn't seem to actually implement any sort of 'max load' function (or does it?)... at least not that I can infer from the part stats, so I may well set the 'overload damage' function to be disabled by default. Shouldn't these legs instantly buckle under this sort of a load? (max length 5m fuel tank...full of fuel) (the ones in the image will eventually break; but only when the unstable stock legs pogo themselves into oblivion, gaining energy the whole time...) So, aside from the 'max load' stat which is yet undetermined, here is a bit of the data that I've put together for the re-balance so far. Haven't touched the part configs yet, figuring it all out as data first. Sorry, its an image... no clue how to paste tabular data into these forums (if its even possible). Motor torque also not included in chart as I haven't gotten that far yet... Few more stats to fill in, and then transfer it all to configs and do some tests to see how it all feels with some simple craft. Lots of parts to test, so that part of things might be an ongoing process. Then to address balance for scaling... Is exactly why that release is a 'testing release'; so many changes to code/models/configs and only limited testing time... bound to have some bugs and issues to be ironed out . Have found and solved that problem in dev branch, and fix for it will be available with the next testing release which should be available likely over the weekend.

Apologies for not getting to this yesterday... Here is a compiled asset bundle containing a single GameObject prefab with a ParticleSystem component on it. It should also include the material and texture in the bundle: https://github.com/shadowmage45/KerbalFoundries2/blob/dev/GameData/KerbalFoundries/Effects/KF-APUSmoke.kfx Here is the code that I'm using to load and instantiate the particles. Its still what I would call a prototype; functional but unrefined. Notably it reloads the bundle from disk for every particle with no attempt to cache the prefabs, nor is there any sort of handling for emitter destruction or floating origin shifts. https://github.com/shadowmage45/KSPWheel/blob/dev/VSProject/KSPWheel/Effects/KSPWheelParticleEffect.cs Finally it is used in this config through the EFFECTS system (note textureName is defined in the config... but not used by the plugin code; only transform and model need to be specified for this barebones implementation) https://github.com/shadowmage45/KerbalFoundries2/blob/dev/GameData/KerbalFoundries/Parts/KF-APU.cfg#L54-L59

I'll put together something simple for you to use for testing based on one of my working examples. Will be an asset bundle with a single model (+material + texture); should be able to load the bundle, instantiate a copy of the prefab, and put the copy into use. Will also provide a link to my rough-draft 'working' code in case that is of any use. Should be able to have something for you here in a few hours as soon as I get home from work... From my testing it seems to 'just work'. The instantiated effects can be placed into the part-model hierarchy, and the effects started/stopped as needed through the ParticleSystem component. The effects look exactly as they did when I was playing with them in the Unity Editor and seem to export/import without issues. I have not yet investigated dynamic runtime adjustment of emitter properties to correspond with the 'effect power' used by the stock EFFECTS system, but it looks like you already have that part sorted out in SmokeScreen.

Already in discussions to clean these up -- there will be a solution in place before too much longer.

Ahh, not familiar with that one personally. Have a link to it you would mind sharing? You may be correct -- it could have been tied to the module at some point. If you are up for custom plugin work... KSPWheel is fully extendable, and 100% certain that it could be made to fill your needs if you can't find other options. I've done pretty much exactly that for the ALG and repulsors -- they both use custom modules for part-specific functions that interact with the rest of the KSPWheel system.