cakepie

Old thread, but leaving a note for future people searching for a solution. The fuzzy / blurry textures discussed here, are not caused by compression per se but by mipmapping. The problem can be avoided by understanding how KSP / Unity handles textures when loading them, and making textures encoded and saved in the right format to ensure you get the correct behavior. The workaround offered above is not needed -- in fact it incurs unnecessary file I/O costs and consumes extra RAM / graphics memory by making essentially a duplicate of the texture when one is already loaded in GameDatabase. Further details:

Here is a pre-release of the next version. This adds the Harmony patching library as a dependency (included in download). For a brief explanation of Harmony, please refer to this post. Using Harmony is a massive help for getting around the limitations of stock KSP API, which really doesn't support the features of this mod. Thanks to Harmony, many horrible, brittle workarounds which were previously necessary for function, but also caused their own minor bugs and weird unintended behaviors, have now been replaced by much more elegant patches that are expected to be safer and more stable. It has also helped enable the implementation of some previously incomplete features. Full changelog below. Only manual installation is available at this time. Feedback on whether this is working as intended on other installs/systems besides my own would be very helpful. v0.0.10.9 for KSP 1.7.x - 1.3.x Requires Harmony (v1.2.0.1 included) Requires Module Manager (please obtain separately.) Community Trait Icons is strongly recommended. Existing localization files for v0.0.10 can still be used, if desired. v 0.0.10.9 2019-05-10 experimental pre-release add Harmony dependency replace many horrible ugly brittle hacks with safer patch-based approaches spawning EVA now uses patches on FlightEVA to feed correct data to hatch obstruction tests instead of tampering with passed arguments fix spurious results from FlightEVA.hatchInsideFairing being fed wrong information due to stock limitations fix strange positioning/orientation behavior of spawned kerbal probably caused by tampered data in passed arguments patch KerbalEVA to disable stock command hints during manual boarding instead of brute force removal at every frame patch KerbalEVA to safely disable stock boarding when auto boarding encounters full vessel instead of outright disabling of KerbalEVA patch CrewHatchDialog postfix to provide notifications when the dialog is ready/terminated discard hacks for checking if CrewHatchDialog populated and ready for hijack/augment rework timeout logic for matching airlock mod+click input handling to stock CrewHatchDialog spawning better cleanup when hijacked CrewHatchDialog is closed instead of only when EVA button pressed add crew type icons to stock crew hatch dialog when spawned via crew transfer PAW action rather than clicking airlock

@St4rdust Easter egg with 8 mineral patches arranged in a C shape. Gas geysers at each end, if that's a thing. Please make it happen.

v0.0.2. There's actually a pane for the icon now and kerbal level has been added. v0.0.2 ~ 2019-05-07 ~ KSP 1.7.x Prototype

So I heard there's gonna be minerals...

v0.2.0 Functions can now be accessed via a console command.

So that's what you were being so cryptic about! I had my suspicions but couldn't be sure.

@linuxgurugamer since you're obviously here though not necessarily on GH: an ack on PR#8 would be nice.

Example config: This config will fix some of the blurry UI in CommNetConstellation (currently v1.3.2) using unBlur. Of course you can just rename the texture files yourself if you have the tech savvy, but this is an example (Also this will probably not be needed anymore once changes from this PR make it into the next released version) UNBLUR_BATCH:NEEDS[COMMNETCONSTELLATION]{ compress = true unBlurFolder = CommNetConstellation/Textures/ } Before, at quarter resolution textures: After, at quarter resolution textures:

So like there's Anim1, Anim2, Anim3, and they all have their own separate deploy/retract button, but individual animations may have prerequisites i.e can only be used if another animation is in a particular state? that would seem quite similar to inflatable/deployable centrifuge case, where: - spin animation cannot be turned on unless deploy/inflate is in fully open state - retract/deflate cannot be done while spinning is active, must stop the spinning first But I don't think ModuleAnimationGroup helps you here, though, because that is for (deploy-retract)<->(active looping) setup only. Sounds like bespoke PartModule probably needed.

v0.5.0 @ 2019-06-01 This is a utility mod that allows fixing of blurry UI elements such as buttons and icons, which occurs when KSP's graphics settings are set to anything less than full-res textures. This is a consequence of mipmapping, in conjunction with the way that Unity handles the texture quality setting, as explained here. unBlur provides configurable, targeted fix of this issue by taking input config files that list the problematic textures. During KSP loading screen, unBlur will remove mipmaps from the targeted textures and ensure that their full-res version is loaded to the GPU. These changes are then persisted in the GameDatabase for subsequent use. unBlur also provides other mods with a mechanism to programmatically fix blurry textures and fetch the resulting full-res version. ~ ~ ~ ~ ~ For Players unBlur as a dependency of other mods unBlur provides a way for other mods to use it to fix textures from another (third-party) mod that would cause blurry UI. For example, although Toolbar mod can ensure that its own textures are nice and sharp, it also needs to display icons that are provided to it from other mods that are putting buttons on the toolbar. If those mods did not set up their icon textures properly, they may end up being blurry when displayed. In that case, Toolbar can ask unBlur to fix the blurry icons, to make sure that all toolbar icons show up nicely. If you've not previously noticed any issues of blurry buttons or other UI -- this could simply be due to Toolbar having implemented a workaround for the problem. However, using unBlur as a dependency provides mods like Toolbar with a more efficient solution, with reduced I/O and memory overheads. Even if you have graphics settings at full texture resolution and are not affected by any blurry UI problems, you will reap the benefits from these improvements. If another mod asks you to install unBlur as a dependency, this is the reason why. If you have no need or desire to fix any blurry UI for any other mods, then there is nothing else you need to do. Explicit usage by end-users For end-users (that means you, the player!) unBlur gives you the ability to try to fix blurry images in other mods' UI without relying on a fix from the mod author/maintainer. (Note that if you play with graphics settings at full texture resolution, this isn't a problem you'd even need to worry about.) Do keep in mind that while unBlur gives you the power to fix things by yourself, if you encounter any mods with blurry UI, the best thing you could do is to politely point the mod author/maintainer at the information here so they can actually fix it for all users of the mod. It should also be pointed out that if you are comfortable with fiddling with files in GameData, there is another approach you can take to try fixing blurry UI, without having to configure unBlur to do it for you. Just identify the *.png files for the mod that are showing up blurry, and try renaming them to *.truecolor instead. This should fix the issue in most cases. (Warning: you should really only do this for small UI textures like buttons and icons. Do NOT go rename all *.png files that you find, especially the bigger ones.) However if you want to fix the problem but are not willing to mess around with the install and rename the files yourself, then unBlur is the right tool for the job. For example, for players who install mods via CKAN it is better not to mess with the files that CKAN installed, since doing so might cause problems with CKAN later e.g. when updating/uninstalling the mod. In that case, you can use this mod and fix the problem without actually changing any files of other mods. To use unBlur you will need to add config files to tell unBlur which files to fix. You can easily write this yourself, instructions and examples are below. If you need help with unBlur-ing any mod in particular, post in this thread and someone from the community may be able to assist. Things unBlur cannot help with If a mod has textures that are too small for their intended purpose, they will inevitably be blurry when upscaled to fit the required size, even after unBlur has forced them to be at full resolution. If a mod has code that manipulates textures programmatically rather than using them straight from the GameDatabase, then unBlur may not be able to help, in which case a fix from the mod author/maintainer is required. ~ ~ ~ ~ ~ Specifying problem textures to be fixed via config unBlur uses the same config file format as KSP. The basic node format is: UNBLUR_BATCH{ // stuff goes here } You can have as many nodes as you want, in as many *.cfg files as you want, anywhere in GameData directory. Each node can contain multiple targets for unBlur to fix. You can specify individual texture files by their relative location from GameData. Omit the filename extension. UNBLUR_BATCH{ unBlurTexture = modA/assets/toolbar/toolbar_on unBlurTexture = modA/assets/toolbar/toolbar_off unBlurTexture = modA/assets/icons/icon1 unBlurTexture = modA/assets/icons/icon2 unBlurTexture = modA/assets/icons/icon3 unBlurTexture = modB/applauncher // etc ... } You can also specify that all texture files in a single directory should be targeted for fixing. (Trailing slash is required.) UNBLUR_BATCH{ unBlurFolder = modA/assets/icons/ // etc ... } Or recursively include all texture files in a directory or its descendants. Be careful with this, do not accidentally include larger non-UI textures. UNBLUR_BATCH{ unBlurFolderRecursive = modA/assets/ // etc ... } You can mix and match all three types: UNBLUR_BATCH{ unBlurFolderRecursive = modA/assets/ unBlurTexture = modB/applauncher unBlurFolder = modC/buttons/ // etc ... } There is an option that you can set which will try to compress any textures within that UNBLUR_BATCH block that are not already compressed UNBLUR_BATCH{ compress = true // compression will be attempted for all targets listed inside this UNBLUR_BATCH node } You can use Module Manager syntax, if you have MM installed. UNBLUR_BATCH:NEEDS[modC]{ unBlurFolder = modC/buttons/ // stuff } A working example config for an actual existing mod is provided here. ~ ~ ~ ~ ~ Sharing unBlur configs Feel free to share unBlur configs for fixing various mods in this thread; if there is enough demand I can also host contributed configs on the GitHub repo. ~ ~ ~ ~ ~ For Modders For fixing blurry UI in your own mod, see information here. You can use unBlur to learn more about what KSP is doing when it loads your textures. If you install unBlur you can use it to dump the texture info from GameData as was shown in the above linked thread. Set the config for verbose debugging as shown below and the full list of textures will be dumped both before and after unBlur performs its fixes: UNBLUR_DEBUG{ verbose=true } unBlur also provides a command you can use within KSP's Alt-F12 console to access its functionality. For usage, type: /unBlur help If you have a mod that accepts and uses textures from other mods, and have no control over those texture files, you can include this mod as a dependency and then use it to "unBlur" those textures before using them. You can either: Call DisableMipmaps() on the textures before fetching them using GameDatabase.Instance.GetTexture(). This method is appropriate if you have multiple GetTexture() calls for the same texture in different places; adding a single DisableMipmaps() call in init code would suffice. Call GetTexture(), which combines both steps and returns the Texture2D directly. (The result is null if requested texture is not found in GameDatabase.) This provides computational savings by not needing to search GameDatabase again to fetch the texture, and works well when a texture is only fetched once. unBlur can also load DDS files, identified by either a UrlFile or the file path. DXT1, DXT3 and DXT5 formats are supported. The behavior is similar to stock KSP DDS loading, but unBlur also allows ignoring mipmaps that are present in the file, which gives a texture that is always used at full resolution. Note: any Texture2D that you obtain in this manner must be properly disposed (i.e. Destroy(tex);) when no longer needed, e.g. in OnDestroy(). ~ ~ ~ ~ ~ License MIT ~ ~ ~ ~ ~ Download unBlur v0.5.0 for KSP 1.7.x Should be backward compatible to at least 1.3.x if not older. Compatible with Module Manager for patching configs. (Any fairly recent version should work properly) Installation: Delete older version, if any. Put unBlur.x.x.x.dll into your installation's GameData folder. Write or obtain config files specifying the UI textures that are blurry and need fixing. Source: GitHub Changelog: v0.5.0 ~ 2019-06-01 ~ KSP 1.7.x - 1.3.x Added input validation Suppress repetitive logging for GetTexture() calls v0.4.0 ~ 2019-05-17 ~ KSP 1.7.x - 1.3.x Fix unreadable textures still being blurry Implement DDS file reader with DXT1, DXT3 & DXT5 support v0.3.0 ~ 2019-05-13 ~ KSP 1.7.x - 1.3.x Add GetTexture() for convenience Minor optimizations and improvements v0.2.0 ~ 2019-05-06 ~ KSP 1.7.x - 1.3.x Add console command Minor improvements and bugfixes v0.1.0 ~ 2019-05-05 ~ KSP 1.7.x - 1.3.x Initial version

Ah, as in using too high res texture actually ends up sampling pixels that are quite far apart on the texture and rendering them adjacent to one another?

Disclaimer: I am not an expert on this, the following is just what I have discovered. Some of this information is deduced based on empirical observation of KSP / Unity behavior. There's only fragmented info out there re: how to set up UI textures. Hopefully by organizing this information together will help put an end to blurry fuzzy UI woes and nasty hacky workarounds. Plugin authors: This will hopefully explain why your buttons/icons/etc are a horrible mess and what you should do to avoid it. Part modders: This does not really affect textures you use in models, but may be informative. (Side note: if you aren't already using DDS with mipmaps, you should be doing so.) Players: This is probably too technical. If you want to fix blurry UI in mods that you are using, see instructions here. So I finally needed to make a mod with toolbar button and ran into the issue where the icon gets all blurry when graphics settings are at less than full resolution textures. Within the modding community I found that: - some modders not aware or haven't address the issue (e.g. low priority, haven't figured out what to do) - blame placed on Unity and it's texture compression (loosely true but not strictly correct) - some workarounds involving DIY reading texture directly from file, ignoring the version in GameDatabase --- file i/o overhead, yucks - some workarounds using textures that are larger than they need to be The crux of the problem isn't actually compression per se, it's mipmaps. If you don't know what they are, you might want to google and read up more, but the short explanation is: mipmaps are just a bunch of smaller copies of the texture which can be used on-the-fly depending on the size required, rather than having to do expensive calculations to get a scaled version from the original at runtime. This is great for model textures, so if you're looking at a capsule in game at close range it would be textured using a high res (or fullres) version of the texture but if it is zoomed out and far away then a lower res mipmap can be used. (See explanation by HebaruSan below.) Depending on what format texture files you're using and how they get loaded, they may already contain mipmaps in the file, or mipmaps may be generated for them during loading. And the problem is, if you have small textures for UI purposes e.g. icons, buttons, you've probably already made it at appropriate size and want it to be used at crisp full res all the time. You do not want any of that fancy mipmap stuff. When a texture has mipmaps, and the Texture Resolution option KSP's graphics settings are set to anything less than full resolution, then the following happens: - At half res, only mipmap level 1 (halved width and height) and smaller is uploaded to GPU <-- "factory default" - At quarter res, only mipmap level 2 onwards is uploaded - At eighth res, only level 3 onwards is available This means that your appropriately-sized, original full res version of the texture (mipmap level 0) simply gets thrown away, so when your UI element is displayed it is forced to use a too-small version of the texture and scale it up. What KSP / Unity does when loading textures Textures are loaded from file into Unity Texture2D object. All of the textures are kept in the GameDatabase along with some metadata in the form of GameDatabase.TextureInfo object. TextureInfo attributes: name: This is the "url" used to lookup a texture when you call GameDatabase.Instance.GetTexture() basically the path of the file relative to GameData folder, minus file extension file: Internal UrlDir.UrlFile format for storing path information texture: The Texture2D object with the texture in it isNormal: whether the texture is a normal map. Note that this can change at runtime. So if you have a texture that isn't a normal map, and then call GetTexture() with asNormalMap true it will (try to) convert the existing texture to normal map, and isNormal flag will be changed to reflect this isReadable: a Texture2D can be set to be "no longer readable" which according to Unity documentation means "memory will be freed after uploading to GPU" and texture cannot be manipulated (e.g. edit the pixels) from CPU side. this flag is supposed to reflect that. isCompressed: whether the texture has been compressed during the loading process. Unity documentation: "Compressed textures use less graphics memory and are faster to render. After compression, texture will be in DXT1 format if the original texture had no alpha channel, and in DXT5 format if it had alpha channel." This flag may be incorrect, it appears to be set as long as there was an attempt to compress the texture with Texture2D.Compress(). But that process can fail, and is usually seen in KSP.log when it complains such as "Texture resolution is not valid for compression: <filename> - consider changing the image's width and height to enable compression" This gives us some insights into the texture loading process. What KSP does when loading each texture depends on the file format, but the general steps include: - read the texture data from file - convert image format (if needed) - (optional) try to compress to DXT - (optional) generate mipmaps - upload to GPU -- behavior depends on Texture Resolution setting, more on this later - (optional) make texture no longer readable (discard from RAM) We can learn more about how different texture file types are handled by observing what happens to them. Below is a partial list of textures info dumped from a stock 1.7.0 install just after GameDatabase finished loading in LOADING scene. I've trimmed it down from the full set. First three letters NRC reflect the three boolean flags. The fourth C shows whether the texture itself is actually DXT format. This is followed by image dimensions, mipmapCount (1 if none) and TextureFormat, then the name of the texture. The source code that dumped this info can be found here, it is part of the unBlur mod. If you install unBlur you can use it replicate the above as well as investigate what KSP is doing to your textures. It provides access to its functionality via a console command in the Alt+F12 debug console so you can inspect individual texture info, disable mipmaps for textures, and dump the full list of textures from GameDatabase. It is also possible to have unBlur dump the state of textures from GameDatabase immediately after loading, while in the loading screen, by turning on verbose debug mode. For details, consult the unBlur forum thread. How the texture resolution setting affects texture loading The texture resolution option in KSP's graphics settings actually control a Unity setting called QualitySettings.masterTextureLimit. The setting is stored in settings.cfg as TEXTURE_QUALITY with 0 = full res, 1 = half res, ... 3 = eighth res. As described earlier, masterTextureLimit prevents the n highest resolution mipmap(s) from being uploaded to the GPU. Per Unity docs, "This can be used to decrease video memory requirements on low-end computers." However, if a texture does not have mipmaps, then the full texture must of course be used. Once the texture has been upload to the GPU, that's the copy we have to work with. If the texture resolution setting was at eighth res when starting the game, that's the quality that you are stuck with -- changing the setting at run time does not appear to have any effect -- because only a lower res version is available in the GPU, and in general because the texture was made no longer readable by CPU side after loading, even if you turn the quality back up to full res, the full res texture data is not available anymore without actually reloading from file again. In cases where the texture is still readable and in RAM, plugins can access the full res version of the texture from there. (This is how unBlur fixes blurry png textures.) How various file formats are handled Based on observations from GameDatabase TextureInfo dumps, including both stock and modded. *.dds These files are already in the compressed format preferred internally. Loading them is fast, because the data is loaded as-is and no conversion is needed. Being compressed, they use less graphics memory and are faster to render. - Loaded format: as per file, i.e. DXT1 (no alpha) or DXT5 (with alpha) - already compressed - mipmaps: as per file - not kept readable *.mbm Old KSP propietary format, very few instances left. - Loaded format: DXT - compressed - mipmaps: yes - kept readable *.png Loading them is slow, because they have to be converted from RGBA32 and additional processing is done. They usually get compressed to DXT5 for upload to GPU, but are kept CPU-readable so also consume RAM. - Loaded format: usually DXT5 - will usually be compressed - mipmaps: may be generated <-- blame your blurry UI on this - kept readable Notes Some stock pngs avoid having mipmaps generated (e.g. Squad/Flags/*, Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) but others do (e.g. Squad/Props/IVANavBallNoBase/*) mechanism not well understood, perhaps hardcoded to identify certain directories (*/Flags/* maybe?) but not sure we can rely on this behavior A very small number of new normal maps (_NRM) for redesigned parts are *.png that store in GameDatabase as RGBA32, unreadable, uncompressed (despite isCompressed true), with mipmaps generated. Squad/Tutorials/YPRDiagram fails to compress, which reveals that pngs are loaded as ARGB32 before getting compressed to DXT mipmaps may still be generated even if compression fails, I have positively observed this (38x38 ARGB32 CommNetConstellation/Textures/cnclauncherbutton.png with mipmapCount of 6) *.truecolor Notably used for small (_scaled) versions of agency logos. Explanation here. Actually renamed *.png files, so loading needs to convert format from RGBA32. - Loaded format: ARGB32 - will not be compressed - mipmaps: will not be generated - not kept readable *.jpg Like png, these are comparatively slower to load. They are compressed to DXT1 since they don't have transparency, and kept CPU-readable after loading to GPU - Loaded format: DXT1 - compressed - mipmaps: will be generated - kept readable Why does it behave like that? If you provide a texture in DDS format, it is already in the format that is used by the GPU, so KSP/Unity takes the file as-is and treats it as what you intended -- so you can provide exactly what you want. If you are using a texture for models, you'd include mipmaps, and things would work great (because that's exactly the use-case they were designed for.) If you are using a texture for UI, you wouldn't generate mipmaps when saving the file, and KSP/Unity will just always use it at full-res (exactly as intended) The texture file is already in the correct format, already compressed, and has mipmaps if you want them. KSP/Unity presumes that everything is as you want it to be, and the texture will no longer be modified by code once loaded, and so discards its data from main memory after it has been loaded into graphics memory. For other formats, however, they need to be converted for use. Because the API doesn't provide a mechanism for us to attach any metadata to png/jpg/etc files to indicate to KSP/Unity what our intentions are and what the texture is for, I think the texture loader simply makes the assumption that whatever textures it loads are for models. So, in general, it will generate mipmaps from the full-res image, and after that it will attempt to compress the texture to DXT for better performance. But it keeps the texture's pixel-by-pixel data available in RAM, in case you might want to write some code that accesses/manipulates that. This is actually a reasonable default assumption, after all, most textures are going to be model textures. As for UI textures, pretty much most if not all of the UI in the stock game are built in Unity, prefabbed, and saved into assets, so that takes care of loading UI textures for the stock game. (Mods could do the same thing, but most of the time it's far too much trouble if all we need is some simple UI.) Anyway, this is the behavior in general for formats like png and jpg. It seems like KSP might have some code that handles special cases in the stock game's data like flag textures (Squad/Flags/*) and icons (Squad/PartList/SimpleIcons/*, Squad/Strategies/Icons/*) so that they don't get treated like model textures. Those cases can be hardcoded because they know about it in advance, but for modders I don't recommend we rely on that behavior. *.truecolor files are the special case, which seems to be added to handle agency logos. Agency logos in general are stored as DDS and are displayed in game at various medium-ish sizes, e.g. contracts window. However, for the part-picker in editor when sorted by manufacturer, it needs to be a small icon. Scaling down from the fullsize logo at runtime didn't work well visually, so smaller "*_scaled" version of the logos were specifically made. These were png files, but as above the texture loader would have generated mipmaps for them and cause blurriness. To deal with that, the files were named as *.truecolor instead and the texture loader instructed specifically to treat them differently, i.e don't generate mipmaps. How to proceed from here UI textures in your own mod Including toolbar button icons for stock AppLauncher or blizzy toolbar. If you are currently using *.png for icon/button graphics, the quick hotfix is to simply rename to *.truecolor. Besides not having mipmaps generated, the other benefit is that it will not be kept in RAM after uploading to GPU. The one downside compared to png is that it will no longer be compressed. Also, like png, it is still slower to load. For long term, if you can convert your files to *.dds without mipmaps would be most ideal: fast to load, compressed, not kept in RAM. If you are using the workaround of reading textures directly from file yourself Specifically the workaround offered here. Stop doing this if it is for textures in your own mod that you have control over. Rename/convert them instead, see above. By reading the file yourself and creating another texture, you incur file IO overheads and consume additional resources for the texture that you create, while the copy in GameDatabase continues to occupy both RAM and GPU. And if not implemented properly, you may be leaking memory. If you have to use the workaround because you have no control over the textures, i.e. they are passed to you by other mods. You can use unBlur, call unBlur to tell it to strip mipmaps from the texture in GameDatabase before you fetch and use it. If you are using the workaround of making textures larger than they need to be This workaround costs a disproportionate amount of disk space and loading time, don't use it. The way that this worked is as follows: Suppose you make a 64x64 image when you actually only need 32x32, this will work at half res settings because the 64x64 copy is thrown away but mipmap level 1 at 32x32 is still available. But at eighth res setting, only mipmap level 3 at 8x8 is available so it doesn't fully solve to problem. You would need to make full res at 256x256 in order for eighth res setting to still have a 32x32 copy. If you have programmatically created Texture2Ds in UI for other reasons Here are tips for best performance and results Make sure you use the constructor that lets you specify mimmap false. Use Compress() if possible. Works more consistently if you do this before making unreadable using Apply(). (ref) Once finished making modifications to the pixel data, call Apply(false, true) to upload to GPU and discard from RAM Make sure you dispose of the texture when done with it. For most monobehaviors (i.e. destroyed/recreated when changing scenes) you should do it in OnDestroy even if it is something you "hang on to", otherwise the texture will not be GC'd and you end up making another copy. Other ideas: you can have a singleton monobehavior with DontDestroyOnLoad that is responsible for hanging on to one copy of textures only. Or init once into a static field. UI textures that require mipmapping If you have UI textures that are larger, such as banners or backgrounds that need to be displayed at different sizes, then you might actually want mipmapping. But then, you'll need some way of getting around the texture quality settings causing the n highest-res mipmaps being discarded. If you find yourself in this situation, my suggestion is to use png format so that mipmaps will be automatically generated for you, but the texture is also kept readable in RAM. After the texture has been loaded into GameDatabase, you will need to fetch the texture -- which is missing first few mipmaps on GPU, but still has full-res data preserved in RAM -- and upload to GPU again, forcing it to include all mipmaps this time. This should be achievable by temporarily forcing QualitySettings.masterTextureLimit to 0, calling Apply(false, false) on the texture, and then restoring the masterTextureLimit when done. (unBlur will also provide such functionality in the future.) Non-UI, i.e. model textures You've probably heard this before, but for fastest loading and best performance you should really encode in dds with appropriate mipmap level.

Elaborate use case please. For what reason? Generally the modeling/animation should go hand-in-hand with anything you might want to do via PartModule or other plugin code. So if you have something that should be a two-part animation, e.g. a centrifuge, that has a deploy animation, and then a spinning animation, that sort of situation is usually handled by having two separate animations. ModuleAnimateGeneric is obviously written with only certain use cases in mind. Some of which is a bit hacked on tbh. If it is not suitable for purpose then you may need to extend it or brew your own. Or maybe one of the existing alternative animation PartModules that are out there in various mods might fit the bill.

Background The full animation in the model file plays in one direction and has a defined start (0.0f) and end (normalized to 1.0f) which is tracked by float value Progress while the part is animating. ModuleAnimateGeneric plays the animation in one direction (positive playback speed) to "deploy" or "open", and in reverse (negative playback speed) to "retract" / "close" (I might have gotten the two directions mixed up, but you get the idea) allowDeployLimit normally, deploy/retract actions in Part Action Window (PAW) correspond to "play the animation fully" E.g. service bays do not have the option true and will only open/close fully Their animation state is either LOCKED when at fully open/closed state and MOVING when animating between the two allowDeployLimit adds a control on the PAW so that the animation is clamped, i.e. "does not play fully" clear example of this is cargo bays. e.g. for Mk3 cargo ramp: If Deploy Limit set to 100% it will animate the full possible range when opening/closing If Deploy Limit set to around 55% the ramp will only open as far as approximately "horizontal" When the ramp has stopped moving while "half open" because of the deploy limit, the animation state is CLAMPED instead of LOCKED revClampDirection reverse the clamp direction of the animation changes whether animation is clamped from start or clamped from end. - one way is you can play from start of the animation clip to the clamp / deploy limit i.e. progress can range between 0.0 ~ X - the other way applies the clamp from the other direction i.e. progress must be between X ~ 1.0 revClampPercent the number displayed for the Deploy Limit control in PAW is reversed. If you clamp a cargo bay door open with deploy limit 10% and it is "only slightly ajar" i.e. the meaning is "10% open" Then close KSP and change the value of this field to the opposite, it will now be 90% to be "only slightly ajar" i.e. it is "90% closed" revClampSpeed If the clamping condition occurs while animation is forward playback (speed > 0) then revClampSpeed = false which will stop playback when deploy limit is reached/exceeded while in forward playback but if the part is somehow already beyond the limit it is allowed to animate in the other direction (and go back within the defined limit) It is coded like this for safety/robustness -- consider if you just force stop animation when progress > clamplimit then could be stuck forever if beyond the limit and not allowed to move back in range. If the clamping condition is while animation is reverse playback (speed < 0) then you need revClampSpeed = true I'm not sure I explained this one well but basically you can just fiddle with this last one until the behavior is correct.

If you do PSA's lower deck lounge I might be tempted to make airstairs for that. The full-height R3 airstairs on the L-1011-1 looks much too intimidating to attempt, though.

Poor choice of wording. What I meant is there is proof I have not only already thought of it but am way ahead in terms of considering how it needs to be architected and implemented and deployed. It is messy scrawlings on note paper I did over lunch. I can't be bothered to turn that into something presentable/legible, would rather use my time actually making the mod.

I welcome interest / support, but seriously: There are a variety of reasons why that is specifically highlighted. Rant: That is totally a feature request. Which is already on my design doc, and being carefully planned for in terms of API etc. And has actually been mentioned elsewhere so I can prove it. Not that that's any promise of if/when the feature would actually arrive. I'd like to keep the thread open so people can subscribe and be notified when I post updates or release newer prototypes. Please don't make me lock the thread.

@linuxgurugamer Where do you need this?

Community Trait Icons users may be interested in this WIP mod. It's a thing that I had planned for a long time but just started to get to work on it. >> EVA Info Pane <<

EVA Info Pane v0.0.2 @ 2019-05-07 This mod is in a prototype stage. It currently only has very barebones functionality and may be somewhat buggy. It is nonetheless being offered for download as a pre-release as it may be of use even in its current embryonic state. The final product will obviously be much more polished and configurable. Please do not bother me with feature requests at this time. I have already planned this out mod thoroughly and have 3 pages of design notes to work through and implement. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Acknowledgements Thanks to @xEvilReeperx for assistance with a crucial technical gotcha. ~ ~ ~ ~ ~ License All rights reserved ~ ~ ~ ~ ~ Download EVA Info Pane v0.0.2 for KSP 1.7.x (probably backward compatible, I haven't checked) Dependencies: Community Trait Icons is required and must be obtained separately. Installation: Delete older version, if any. Place contents of GameData into your installation's GameData folder. Source: GitHub Changelog: v0.0.2 ~ 2019-05-07 ~ KSP 1.7.x Prototype v0.0.1 ~ 2019-05-01 ~ KSP 1.7.x Prototype

Ah, this is what caught me out, so stuff didn't show up even when I did it with layer = 0. Thanks!

Do you absolutely need to run your "more complicated algorithms" at runtime within KSP? If the modifications that you want to make to the engine stats can be effected purely by changing the configs (directly or via MM) and don't need to override any of the methods in ModuleEngines, then one option is to write your algols in a separate program that will generate the required MM patch!

Been having difficulty trying to get programmatically generated UI canvas to work in ScreenSpaceCamera mode with the flight mode camera ( FlightCamera.fetch.mainCamera ). I wrote some PartModule code that MM attaches to each kerbal, it generates a canvas for UI elements in OnStart and tracks kerbal's position on screen in LateUpdate. Shows up properly if canvas is in ScreenSpaceOverlay mode. Silly prototype putting censor bars over kerbals: However I don't want my UI elements overlaid on objects that are closer, e.g.: the censor bars should be occluded behind the capsule in this shot Therefore I should be using ScreenSpaceCamera mode rather than ScreenSpaceOverlay. But when the canvas mode is ScreenSpaceCamera and set to use the flight camera (FlightCamera.fetch.mainCamera) my stuff doesn't show up. If the canvas mode is set to ScreenSpaceCamera and set to use the UI camera ( UIMasterController.Instance.uiCamera ) stuff shows up but it isn't the behavior I want because of how KSP uses its multiple cameras to render separately then combine. It is pretty much same outcome as using ScreenSpaceOverlay. Code snippets for both render modes here. I have considered WorldSpace canvas and am sure I would prefer not to use that. I want to control pixel size of the UI elements, not have it sized by the camera's perspective depending on how far away it is. Also with a world space canvas, would need to do billboarding and repositioning of the canvas, messy stuff. Wrote a bit of code that pulled info about the FightCameras, code snippet and output here. Pretty sure I've got the right camera, it works great for tracking the kerbal positions and based on the clipping distances is indeed the one responsible for the nearer portion of local space. Although its cullingMask excludes the UI layer 5, according to Unity documentation it should not matter: Things I have tried to no avail: remove the positioning code in LateUpdate and just plonk the image in the middle of the canvas based on half of screen width/height. put the canvas and image GameObjects in Default layer 0 instead of UI layer 5 modify the camera cullingMask to include UI layer What might I have missed? Any insight appreciated.

Edit: added supported for WheelCollider, PR submitted ----- Original post ----- Somewhat late but @wile1411 looks like you are referring to config fields such as these from RoveMax Model M1 (roverWheel1) MODULE { name = ModuleWheelBase wheelColliderTransformName = WheelCollider wheelTransformName = WheelPivot wheelType = MOTORIZED // setting this to true will override the radius and center parameters FitWheelColliderToMesh = False radius = 0.378 center = 0,0,0 mass = 0.040 groundHeightOffset = 0 // .. } Those values for radius, center, etc are for vehicle physics, e.g. position the part accordingly with wheel center at radius above terrain mesh. It doesn't involve any visual part of the model (i.e. meshes) nor use any "traditional" collider (e.g. one of the primitive colliders or a MeshCollider -- though a collider is still needed in your model if you don't want kerbals walking right through the wheel, just won't be used for vehicle physics.) I believe this is using a WheelCollider. The flag FitWheelColliderToMesh looks like it provides a mechanism to derive the radius/center values automatically from the model mesh (and thus, as the comment suggests, will override values in the cfg.) However it is not strictly correct to say that the WheelCollider is not an object -- it is in fact part of the GameObject hierarchy that DebugStuff pulls out and dumps, second from bottom for roverWheel1: [DebugStuff] +roverWheel1 T:Untagged L:0 (Default) | Transform - roverWheel1 | Part - roverWheel1 | Highlighter - roverWheel1 | // blah blah blah | AudioSource - roverWheel1 | Rigidbody - roverWheel1 | --+model T:Untagged L:0 (Default) | Transform - model | |--+roverWheel1 T:Untagged L:0 (Default) | | Transform - roverWheel1 | | | ( // a whole lot of stuff ) | |---WheelCollider T:Untagged L:0 (Default) | Transform - WheelCollider | WheelCollider - WheelCollider | ---Surface Attach Collider T:Untagged L:0 (Default) Transform - Surface Attach Collider SphereCollider - Surface Attach Collider But it isn't one of those that DebugStuff shows when drawing colliders.