Shadowmage

Undoubtedly, there will be some performance impact. I haven't noticed anything notable on my PC, but its not exactly a potato. I'll likely do some frame-rate studies and comparisons vs KS3P before I do any releases (which will be done under a separate mod; not as part of TU). So far I would say it has lower impact than KS3P (which uses post-process stack v1), but I don't have any proof at this time. TU does not have any keybinds, in the editor or otherwise. Curious what you are thinking would need one? All of TU's texture-switching is done through the right-click menu on the parts, using the standard part action window with sliders/selection widgets. The recoloring features are also launched from the part-right-click menu ('Open Recolor GUI'). Currently, no; I never finished it / never got it fully usable. Got stuck on the 'volumetric clouds' feature, which didn't seem to be going the direction that I wanted (looked great; ran terribly). Might be something I look into again in the future, but I might also just leave the volumetric environment stuff to the current experts; I don't think there is much to be gained by my creation of a new system (contrast to KS3P, which is no longer maintained, and using old/unsupported Unity packages).

Been working through the post-process stack (v2) setup a bit, and it seems like most of the effects work in KSP fairly well, if used and configured properly. Definitely ran into a few big '?' inducing moments though... Motion-blur in map-scene is a no-go: Auto-exposure can do fun(ny) things if you play with the settings: But when used in moderation, the effects can be fairly pleasant and not distracting: Before: After: At this point I'm only partway done with the in-game config editing UI, but full text-file (standard KSP .cfg file) based profile creation and in-game per-scene profile selection is in place and working. Will likely have more news to share on this later...

That report belongs in the thread of whatever configuration (patch) set you are using; whomever it was that provided the configs that are adjusting the tanks. As I am not the author of those configs, I cannot say how those configs are set up, or if that message is intended with those configs, or an actual error.

Thanks for the report. Should be fixed up for the next release. Looks like the code that should be spawning (or removing) the 'TU Debug' app-launcher button was not properly checking its references. Shouldn't have had any impact unless you had debug features enabled, and the only impact in that situation was the loss of ability to open the debug GUI. Yep, I'm in pretty much the same boat. Really want to go code-only, but I've got a bit to learn yet before I can implement it myself. Getting there, slowly. I can reason through the 'decompression' algorithms well enough, but writing the compression end of things is still a bit beyond my understanding. Thankfully, at this point, I think I'm okay with the compression being done by an external tool. As long as I can load the textures into memory (uncompressed and compressed sources), and manipulate the data there, I'm less concerned with the final compression process itself (which is usually the last step in the process, to be used for finished textures). Sure, would be nice to be able to do it all in-memory, but as long as the external tools are reliable, no reason not to use them. My issues with C++ stem from.. well, yeah, how ugly it is, and how painful it is to set up projects. References (&), pointers (*), and standard variable types (they each have their uses, but are often abused poorly). Manual memory management can be a complete PITA. I probably would be much better with it now than I was last I tried it, but I still think I would prefer the 'quicker to use' scripting languages. No doubt C++ is better suited for the implementation of specific functions, or for use in specific performance-critical places; but a general purpose scripting language, it is not.

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.5.10.25 See the link for change-log and downloads. Notably it fixes some issues with stock normal maps (for reuse of those textures by config/patch authors), and adds optional support for the BC5 normal map format. Should be backwards compatible with existing configs. Should also continue to work fine with KSP 1.8.

Took a bit of time this week (beyond updating things) to play around with getting an updated post-process stack functional in KSP, using the updated Post Processing Stack v2 that is supported by the new Unity versions. This will be released as a stand-alone mod at some point in the future, and is intended as a spiritual successor to KS3P as it is no longer being maintained. So far I've gotten the code imported to KSP, the shaders compiled in Unity and loading into KSP, and can enable some basic effects and play with settings. Yet to-do is to investigate each built-in effect to see which work/don't work, what the settings do, and what the default values are/should be. Further, I will need to build a profile parsing and loading system, in-game config editing UI (wip, above), and some method to save the edited configs. Likely will be packing up a TU release a bit later this afternoon; was waiting to see if it would require any changes/fixes to support the post-process stuff. So far everything looks to be working...

I think I actually made such a mod, long ago... https://github.com/shadowmage45/DockingPortToggle Never officially released, but it exists

You need to wait for the next TU update for it to actually fix anything, which likely won't be until sometime over the weekend. Once that is available, then yes, the updated TU should fix many of the issues with the stock textures (and possibly some modded ones?).

@blackrack Snuck in some time today to do further testing regarding HDR in KSP 1.9, and I'm happy to report that I'm no longer experiencing the issues that were encountered under previous KSP versions simply by enabling HDR on the cameras. I can now turn it on without negative impact, and it seems to be functional when used alongside a 'bloom' post-process effect. Not sure what impact this may have on Scatterer, its implementation, or features, but thought I would share the (good?) news (All of this research is going towards a possible update/replacement for KS3P that uses the Unity Post Process Stack v2... assuming I don't run into any more oddities, and can wrap my head around how to get it all working in KSP)

That is actually a normal effect on a helicopter. In a 'hover' the forces of the rotors are roughly balanced out; neither side is generating more lift than the other. But when you start moving forward... think about it... the blades are spinning, and the helicopter is moving forward. The blade that is advancing into the airstream (direction of travel) generates more lift than the one that is retreating. Thus you get more lift on one side (the advancing blade), and a roll is induced about the longitudinal axis towards the side of the retreating blade. The pilot must correct for this by including additional cyclic controls to counter the roll.

Ahh, yeah, that nasty messy output was what I was seeing out of GIMP (but didn't see out of the other tools I was using at the time), which is why I simply wrote-off the GIMP plugin and never looked back. Good to know that it has some settings to clean up those issues. Huh.. looking at it more, it claims to be able to do BC5 exports as well... interesting...

I also just ran into: https://github.com/GPUOpen-Tools/Compressonator Which is AMD's open-source asset compression (textures and models) pipeline. Seems like it has both GUI and command-line utilities available, for BC1-7, and a few more I'm unfamiliar with. Likely will be playing around with it in the near future, will let you know what I find out There are some settings you have to use for NVDXT.EXE to get good results, at least for DXT5. I don't use DXT1 as much myself, but I use the same settings for those.. ( https://github.com/shadowmage45/TexturesUnlimited/blob/master/Plugin/TexturesUnlimitedTools/TextureConvertWindow.xaml.cs#L66-L84 ). IIRC it amounts to: nvdxt.exe -file "InputFileName.png" -output "OutputFileName.dds" -Triangle -flip -quality_highest -dxt[1/5/5nm] The important bits are the '-Triangle' filter mode, and '-quality_highest' flags, which seem to do some magic to smooth out many of the artifacts that I would see from the GIMP plugin. Honestly haven't compared the DXT1 outputs though (or done much comparison at all in recent years), so could be that GIMP does those just as well or better. Mostly I've been concerned with normal maps and what where diffuse/specular maps (yep, haven't even re-checked since I started using the metallic/gloss setup). Is this an export setting in GIMP somewhere? Not familiar with that term in reference to the GIMP/DDS plugin. Perhaps my plugin is out of date...

A collection of custom C#-WPF designed tools to handle texture conversion, texture merging (putting specular values in alpha channels), and general... fun. https://github.com/shadowmage45/TexturesUnlimited/tree/master/Plugin/TexturesUnlimitedTools They currently use a collection of NVDXT.exe for texture compression/exporting(DXT1/DXT5), XNA-DXUtils source code for DXT1/5 for texture reading/decompression, and an assortment of custom code for doing the in-memory data manipulation (once it is in a byte array of RGBA pixels...simple enough to deal with). Yeah, I gave up using the GIMP plugin for DDS conversion long ago. It works well enough for -reading- the textures to look at them in GIMP, but for exporting... yeah, it was terrible. Hence the use of the NVDXT.exe for compression (Nvidia DXT Utilities; a legacy application from Nvidia). I internally store all of my (exported) art assets as PNG -- compressed, lossless, supports full alpha, relatively simple to decode and encode with built-in system libraries (well, built-in to C#/.NET anyway). The original art assets are of course buried inside of GIMP or Substance Painter projects, but I still use PNG for exporting from those tools and as the base for conversion to DDS. I'm not concerned about the time-to-export, and would far rather have the wider support that PNG offers compared to TGA (everything I know can handle PNG (even Windows Paint...), very few things do TGA (properly) that I'm familiar with). Possibly this one: ( https://github.com/Microsoft/DirectXTex/wiki/Texconv )? Indeed, I started down that road at one point, but as I was trying to do it all 'in-application', I opted to not use their command-line utility. Technically they are supposed to have libraries as well so that I could link to them and use them all from within my own code, but I could never figure out how to get the references sorted out (always missing some random DirectX library, that apparently doesn't exist in the wild anymore). Edit: Hmm... this might fit the bill ( https://github.com/deng0/DirectXTexNet ) Still looking for code-only solutions if possible -- some sort of a C# library that I can reference to use the functions from within my own code. Sadly I have not been able to locate anything that meets the requirements of: a.) 'free' (libre) - such that I can include the library or source in my tools and redistribute it; e.g. open-source compatible licensing b.) modern enough to support the recent formats (BC3/BC3n/BC5) c.) modern enough to actually be usable as a library and not require some deprecated windows-only DirectX dependencies that no longer exist, and preferably not windows-only at all. d.) supports both decompression (reading into memory) and compression (writing to disk). I've found some that can do one or the other (for a limited number of formats), but none that can do both for all of the required formats. e.) supports managed C#/.NET. Quite a few C++ libraries available, but I hate C++ about as much as I hate python (and only slightly more than I despise Java) (all for different reasons ) Yeah, its a pretty tall order (compared to what is available...), which is why I have been slowly writing my own stuff. But its... slow and tedious work, at best. Anyhow, thanks for the suggestions, and I'll certainly give them a look over before I decide on what direction to go for these features.

Hopefully I'll be releasing a 1.9 update over the weekend. Have been spending the past ~two weeks working on tracking down some odd normal-map related bugs in regards to the use of the stock textures, and finally made some headway the past few evenings. Hint: The stock textures are wrong (encoded incorrectly). For this, I must say 'Thank You' to @Manwith Noname for his initial report of the issue, and his patience while helping work through what has been, to date, one of the strangest problems I've investigated. Its been... fun (well, as fun as bug-hunting can be). In the next release(s) the shader packs are likely to ~double in size due to the additional variants needed to support the incorrectly encoded stock normal maps while still allowing for use of correctly encoded textures everywhere else and adding support for BC5 encoded normal maps (something new!). The alternate solution would have been to do run-time correction of the stock textures directly in the GameDatabase, but the startup impact for that solution turned out to be quite high, and could have easily added minutes to the startup time (worse on slower CPUs). This method will still be available (already wrote the code, no reason to remove it), but it will be up to patch authors if they want to fix the textures (though they shouldn't need to). The shader based solution should have no runtime/performance impact whatsoever, and should be fully compatible with all existing stock + other correctly BC3/DXT5nm encoded normal maps (as long as there is Y axis data in the G channel and X axis data in the A channel). Use of BC5 encoded normal maps will require activation of a keyword in each of the MATERIAL blocks ('keyword = TU_BC5_NRM'), and when activated will only decode BC5 (not BC3/DXT5nm). (now I just need to update all of my tools to support BC5 as an export format...)

That is actually an issue with RealPlume as far as I know -- some of their effects need to be rebuilt/recompiled/etc, as I see some failure-to-load messages in the logs in relation to some of the Hypergolic plumes....

I'd say it is looking pretty darn spot on compared to the 'real' thing...

Yes, you can. The coax (RC helo) that I've dealt with induce yaw by speeding up one set of blades while slowing the other (this could also be done with pitch/collective adjustments). Basically, use your rotor disc to induce torque around the rotor axis, by unbalancing the torque between the two sets of rotors. Quad-copters do something even cooler, speeding/slowing alternating sets of blades to induce yaw. Now, tandems are a bit more difficult, but you can also do yaw on them (around one of three vertical axes) by adjusting the cyclic on their front and rear sets of blades in opposite directions to spin about the shared axis (or adjust only one, to spin about the axis of the opposite blade). There was a Chinook operators manual link floating around on a similar forum post that explained how this is done on the big birds...(sadly, can't find the link now...) Short answer: you can, it just isn't calculated (properly) by KSPs control modules.

RealismOverhaul is the only source that I'm aware of RealFuels configs for the SSTU engines. However I do not provide any support for either RealFuels or RealismOverhal; the folks in the RO thread might have more information to offer on how to use that config without the full RO install.

Pretty sure that KSP 1.9 includes its own cinematic-camera mode? Something about hitting esc. to pause the game, and then using some setting int he menu? Keeps the game paused but lets you move the camera/etc so you can get cinematic screenshots. Or are you specifically looking for external viewpoint mods / docking-camera mods? (likely most of those were broken by the 1.9 update, so may be a few weeks before anything is usable again)

Probably a reason its called Infernal Robotics. Indeed. Unfortunately, the 'replacement' method doesn't work in the same fashion, and there is no documentation stating how the new method works or how to convert between the two. Last time I tried to fix that, it completely broke... everything So be aware, just because you made the compiler happy -- doesn't mean it will actually work in KSP. (Yeah, I tried the same basic 'replace the method with the new one, and cast back and forth from float to double' conversion, that for some reason didn't work) Heh, yep, same as the above. They implement some new system that is supposed to be an 'upgrade', but don't bother to make it possible to do direct translations to the new system -- you have to restructure your entire program around their new methodology and whatever hoops they want you to jump through. I'm all for progress, and I fully understand the need to break old functionality in order to make new and better things, but for all that is good -- at least tell someone how to convert from the old system to the new system. I'm sure both of those points can be addressed. Just need a good solid couple of days that I can devote to modding time, where I also feel like being frustrated the entire time (dealing with undocumented APIs always gets to me..). Gotta get into a special headspace for that kind of work and form of punishment. Yeah, that's mostly how my GUI's in KSP have gone as well. The new 'Unity GUI' system is actually very workable. But only if you can build the game from the editor; it is painful for use by mods. The issue being that all the GUI elements require scripts to function, you can't pack scripts into AssetBundles, and AssetBundles are the only way to get the GUI's out of the UnityEditor and into KSP. So, you pack up all your carefully laid out GUI into an asset-bundle, and then in KSP you need to extract them, and spend a few thousand lines of code to hook up all the scripts and fix all the binding info that was lost during the AssetBundle export/import process.

This mod by itself does not change any part textures or enable PBR for anything. All that Textures Unlimited does is provide the shaders for others to use, and provide a framework for runtime material adjustment. To actually change parts, you need a mod that either uses the features of TU for its textures -- you can see some of those in the OP, or check out SSTU or KerbalFoundries from my signature. The other recommended option is @Manwith Noname's TexturesUnlimitedRecoloringDepot, which does add PBR support for stock parts (and some mods!). Please see the answer above. You'll need to find a mod that has configs for whatever parts you want updated. TexturesUnlimited is a framework, an API for use by other modders. TexturesUnlimited has absolutely nothing to do with shadow-strength or lighting settings. You are barking up the wrong tree on that one... maybe try the built-in stock settings?

I never got into it, but I'm pretty sure that Scatterer will let you replace the sunflare entirely (with something custom?)? https://github.com/LGhassen/Scatterer/tree/master/scatterer/Effects/SunFlare At least that is what the source code makes me believe (though I haven't dug into it much)...

Had a quick chance to check on this, and from my initial brief investigations -- I'm no longer seeing the errors when HDR is enabled. The only change I'm seeing at all is a very slight darkening of the rendering to things that are in shadow (barely perceptible); everything else seems to render acceptably. As I deleted my custom bloom implementation during my recent project cleanup, I'm going to recover those files, and redo the full series of testing that I was previously encountering problems with. Will let you know of any further information I turn up.

Yes, a vessel module would be the root handler for interaction/spawning the UI, and persistent storage of grouping data. The individual settings would still reside in the existing sub-modules, simply to keep things 'modular'. Would use a custom attribute system (similar to [KSPField]) or other tagging system to have the vessel module grab references to the fields to be controlled right out of the sub-modules, and then dynamically construct the UI based on the available fields and any persistent data that was available regarding grouping. The technical aspects of the back-end were never too much of an issue for me, I think I already have a basic controller class in the repository that does most of this; my problem has always been designing a UI that made sense, in KSP. More so the difficulty of creating GUI's in KSP rather than creating a functional design; I could easily create something usable in WPF, Unity-GUI, or any other number of UI systems, none of which are available to KSP. I've never figured out how to import Unity-GUI's through AssetBundles, or if it is even possible, nor had the time to learn how to construct them through code -- but that is what would really need to happen next. The IMGUI system that I use elsewhere is good for simple debug displays, or a few buttons to click... but if you want tabs, tree-menus, or anything more complicated than a scroll-panel, you need to use the Unity-GUI system (or something entirely custom). Possibly, just a bit Whenever I create systems like this, it usually is on the 'insanely-crazy-configurable' level. Perhaps a few steps overboard (Just look at all the features in SSTU's and TU's systems; 50% of which I use rarely, if at all)

Just wanted to pop in and say: Yes, this is a real thing. This has been experimented and measured multiple times, by different people and groups. The finding is always: More 'open' docking ports = higher CPU usage during their internal updates. Pretty much exactly as explained by @Padishar in the quote above. Him, myself, and @riocrokite all spent considerable time trying to find the source of stock 'part-count' induced performance degredation, and the exposed docking ports was one of the worst offenders by a large margin.