Search the Community

(nvm i'm big dumb)

TU / SSTU Color Presets The following config file is intended to replace the stock SSTU list of colors for the recoloring option that can be used on any SSTU part to give it custom colors. This is a list of colors I use in my game-play and should give a large variety of gloss, metallic and matte color options. You can always add your own colors ofcourse by editting the cfg file for colors. Notice I mention colors a lot? Colors... SSTU Color Presets Spacedock [v1.11 11-04-2021] Works for SSTU/TU release for KSP 1.9.1 running on KSP 1.11.x To install: Unzip the archive and move the contents in the /GameData folder to your ../KSP/GameData directory. * note: upon installation this may effect some of the stock colors. REQUIREMENTS You need the following items installed to get these colors to look like they should. - SSTU 0.10.46.158 or later download link - KSP 1.6.1 or later, running in 64-bit mode and forced to DirectX11 TIPS TIP: Change the length of the recoloring GUI in the in-game Textures Unlimited settings menu. TIP: Specular and Metallic sliders It may sometimes not be evident which slider to use for what effect when changing existing, or making you own colors: - Specular: The amount of shiny. Setting to 0 will make the color matte, setting to 255 will make it a mirror gloss. - Metallic: This is basically a contrast slider, raising or lowring contrast from reflections. Set to 0 and it will be flat, set to 255 and you will get light to dark bands that exagerate the lighting. Specular 0 and Metallic 0 will give a matt paint effect, while specular 255 and metallic 255 will give a super metallic mirror effect. Warning: The higher the specular and metallic values, the darker it will look in space as there is no light source to reflect like with the omni-directional lighting in the VAB. Keep this in mind when using colors that look like mirrors in the VAB. Enjoy!

My kerbals don't wear their helmets in IVA, and I wonder if there is a way to fix that.

I'm playing KSP 2 years already and I always thought that only stock KSP can load faster then 5 minutes. My modpack was loading 15 minutes until yesterday. Now it loads in 5 minutes. The same modpack. What changed? I shrinked almost all addon textures in half! I had some issues and need to take a look at addon resourses and I was shocked. People, are you serious? 2k textures??? I mean, it's not Star Sitizen! 2k textures even for a tiny parts!!! That's beyond good and evil. I'm in 3D modelling for games since 2001 and I'm always asking myself "how large will be an object on the screen in the game?" And playing KSP, 90% of time my screen looks like this: Now think about this: every part has a texture of 2048x2048 pixels. Every ~40 pixels wide part has 4000000 pixels texure!!! What a RAM waste. Thus I spent 2 hours shrinking textures and I don't regret this. I got tripple performance gain with no visual difference. So thi is my public appeal to all mod developers. I beg you, review all your textures or release optional low-res packs. 2048 only for huge >5m parts,1024 is more then enough for 2,5-5m parts, 512 for smaller parts and 256 for various bells and whistles. Remember: it's Kerbal Space Program, it's vulnerable to RAM wasting, so pay attention to it. P.S. Near Future Tech mods don't need any optimization. Respect, guys!

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.

Procedural Parts and its supporting texture packs include a number of interesting textures that are unique in color or styling, or are simply different enough from the others that it can be difficult to use them seamlessly on your craft designs. This texture pack attempts to build sets of related textures around the unique ones, or fill in some gaps in the existing sets. Have you ever wished for more dark red textures to go with the default Mu texture? Or how about the set of assorted black & white blocks and stripes, except in navy blue and white, or soyuz green and white instead? Well, here they are. All textures are derived and edited from default Procedural Parts textures or other texture packages with permissive licenses. Credits for original artwork are as follows: Corestar - MainSailor Skylab - MainSailor Vanguard - MainSailor Charcoal - MainSailor Delphi - MainSailor SoyuzGreen - Chestburster GreySide - Chestburster RedstoneStripes - Chestburster TitanStripes - Chestburster PlainWhite - Chestburster Mu - Dante80 CryogenicOrange - blackheart612 StockEnd - Ancient Gammoner This texture pack is compatible with all versions of KSP that are supported by the Procedural Parts mod. Download from SpaceDock Installation: Merge the included GameData folder with the GameData folder in your KSP folder. These textures require Procedural Parts to function. MainSailor and blackheart612 texture packs are recommended. License: Creative Commons -- Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)

So I´ve downloaded this material here: https://www.blendswap.com/blends/view/68707 and I tried to apply it to a project I’m making, I am a beginner on blender, and the material is not even close to what it is supposed to look like. at first, everytimei rendered it just showed up brown with no texture on, then i read on a forum to activate UV maping, and so i did, there wasn’t anything there so i clicked the plus button to create one and now it stays like this: http://prntscr.com/n2b90h I dont know what to dooo ;-; Help!

So, I've been playing ksp for some time and one day most of the textures decided to glitch and stretch out for miles and I wanted to know if this was a fixable problem or common and if it might be my graphics card thats too old to run ksp properly.

Dear Reader, Please could you advise me how or where to change the settings for kerbal helmets. It is just that I want to make them wear their IVA helmets during launch or decent. Kind Regards, Rover 6428

For example, I set orange-grey textures for 1.8 tanks in in the VAB-list, and I want them to stay that way after reloading the game

Hello, how to create textures like stock ones? Textures that match the style and brightness. Stock textures have some alpha channel or sth in it that makes them less shiny and bright. Is there some way to recreate this?

Hello everyone. Some days ago i reinstalled mods and find out some problem with parts miniatures. Steam consistensy check was failed, one file (26kb) was re-downloaded. It didn't resolved this issue. I performed a clear install, but got the same. Check always fails on this 26kb file, if i launched the game after previous check. Installation to another hdd does not help too. I'm not alone in this situation, one man in steam community replied in my topic about same issue.

I'd like to gauge if there is interest in creating a community curated list of VARIANTTHEMEs, which would serve a function similar to Community Tech Tree, Comm. Resource Pack, Comm. Category Kit. The aims would be to prevent redundancy, avoid name collisions, ensure that different mods play well together, and present an overall consistent, well-organized categorization of modded variant themes to players, to achieve a better user experience. What are variant themes? With 1.4+ KSP has gained texture switching as part of the stock game, and the new VARIANTTHEME config node to go with that. Variant themes serve to group together the part variants of different parts, that have the same design theme (i.e. "look-and-feel"). This makes it convenient and user friendly for players to switch multiple parts at the same time, to achieve a particular look-and-feel for the craft they are building. With one click in the "Variant Themes" tab in advanced mode in the editor, the player can apply a theme to all applicable parts on the craft currently being edited, or to set that theme as the default for applicable parts when picked out from in the part palette -- rather than have to adjust each part one by one. These are variant themes. They can be accessed in advanced mode in the editor. The variant themes that are built-into stock KSP are defined in GameData/Squad/Parts/VariantThemes.cfg As an example: these panel parts from the Making History expansion each have three part variants. The part variants are defined in ModulePartVariants of the respective part's cfg files. Using the part action window in the editor, you can switch a part between its variants, but doing it this way only works for one individual part at a time. But each of the available part variants are also associated with a variant theme -- this is themeName or baseThemeName value in ModulePartVariants in the part cfg. Being associated with variant themes allows you to click on these icons: And it will "apply" the selected theme -- all the parts on the craft that have such a variant will be switched to that variant. It is optional to associate a part variant with a variant theme. But doing so is useful and user friendly when multiple parts have variants of the same "theme" (hence the name). Why should I care? If you reskin existing parts from stock or other mods. e.g. Back In Black You would obviously like to have a VARIANTTHEME that corresponds to the look-and-feel that you are creating in your mod. So, you set that up. Great! But wait, you're not done yet! What about the original look of the parts that you have modified? When you added your version, a "base" part variant was also automatically created for the original version of the part. You could just leave that as-is , but then the player won't have an easy way to revert multiple parts en masse to their original design. Okay, so let's create a VARIANTTHEME for that... what should it be called? Reasonable choices might include: "stock", "default", "original", etc. If different mods use different names/themes for the same purpose, it could result in a clutter of redundant themes in the UI, messy and potentially confusing. We should standardize. Furthermore, due to a technical limitation of Module Manager we cannot use a clever MM patch that will "add the 'default' VARIANTTHEME if it doesn't already exist". So, for multiple mods to be able to use the same "default" VARIANTTHEME for resetting parts to the original version, we need that to be defined in a community standardized config that gets included by the various mods as a dependency. Additionally, from a technical standpoint, how to ensure that your mod plays well with other mods? In particular, what if someone else also makes a reskin mod that touches the same parts? How can we prevent "Back In Black" and "Racy Red" from stomping on one another's MM patches? We should explore and develop best practices for how to do this. Electrocutor's guide is a good starting point. If you make (a) part(s) that have different textures to choose from. e.g. Hawkspeed Airstairs You might have different textures that are designed to fit in with stock parts, or various other mods. What should you name the different variants? For starters, do we say "stockalike", "stock-alike", or "stock-like"? Standardizing on a common set of VARIANTTHEMEs would avoid redundancy and confusion. Even if your mod has just one part -- since you don't have a natural "collection" of multiple parts to group together, it might seem pointless to set up your part config to use themes. But that's not true -- it is useful to be part of a standard set of themes, that groups different parts from different mods together if they offer the same "look" -- it enables easy texture switching by the player. And when it comes to textures for matching with other mods, there are further considerations. Consider my airstair part -- in addition to stockalike option, it comes with an alternate texture that matches the unique look of Firespitter bomber parts. Those parts aren't shipped with any variants, so okay, I go ahead and label my texture "Firespitter". ... but what if a reskin mod comes along and adds a new variant on top of the original Firespitter parts? They can call their new variant whatever they want, but if they file the original Firespitter look under "default", then we have one theme (the "look") split into two different themes (VARIANTTHEME) -- a player would have to pick "default" to reset the Firespitter parts back from the reskinned version, whereas for the airstair it is the "Firespitter" option. Not very intuitive. If you make parts that don't have alternative textures, but come "in a set" -- stockalike, or your own unique design. You might think this is none of your business, but hang on. If other modders create additional textures to reskin your parts, wouldn't you like to have a say over what the original look of your parts should be filed under? For instance, stockalike mods (e.g. Airplane Plus) may prefer to be grouped with other mods' parts under "stockalike" rather than a meaningless, generic "default". Whereas in the case of a mod whose parts have a unique aesthetic (e.g. keptin's original KAX textures) it may be appropriate to specify its own VARIANTTHEME. Although the mod itself doesn't ship with any variants, and thus doesn't initially have any use for the theme, it provides: a) a target theme for other mods to group their "compatible" variants under, and b) if someone else makes a reskin, then the original look can be placed under this theme, along with those from (a). - * - * - * - To kick things off, pinging a few people that this might be relevant or interesting to (based on threads/conversations I've seen elsewhere in the forum) @Electrocutor @XLjedi @Rodger Please discuss, etc etc.

As you can see, the part texture on left column is missing, how to fix it?

It seems KSP 1.4 is not prepared to use the ForceDx11 or D12 options. I have been using the force dx11 on previous versions of KSP without issues. DX11 helps a lot with memory consumption

In the last days I have been running around the forums searching for a way to add textures to the module TextureSwitch2 (Firespitter) to the fairings from Procedural Fairings parts.I found a very old mod from 1.1.x called Procedural Fairings for Everything, which main objective was to collect and merge different texture mods for fairings into one.I gave a look inside of the folder and it was quite a mess.I am trying to make a more polished version of it for myself but I can't get around a thing that is quite anoying: Some fairings have the "Payload Fairings - [...] [Procedural]" and some don't.Anyone has any idea where I can find the file that adds this thing?(So I can remove it and rebuild it to be more specific). On another side I would like this to become a thread on where to discuss the problem of textures for Procedural Fairings and to make a standard guide on how to make and plug them into KSP.

I'm trying to make a mod pack but surprise i suck at making textures so I'm looking for some stock or stock alike textures i can use as references. Does any one have any stock alike textures they are willing to allow me to use as REFERENCES on how to make stock alike textures?

Hammer Tech's Skybox v1.1 Bring Kerbin to the Andromeda galaxy! Original work by @Hammer Tech. v1.1 Updated for Texture Replacer Replaced 0.5.1. This breaks compatibility with Texture Replacer 2.4.13. Dependencies Texture Replacer Replaced Downloads SpaceDock License Considering legalities. So, it's finished, but I want to be sure I have the right to do this under licensing and such. Seeing as many textures were just posted with a link to a download, I'm not sure if a license is automatically assumed, or applied at all.

Is it possible to use animated textures for the planets? I'm sorry for my English!

How do people generally make dds textures? I use the GIMP-dds plugin, but my dds textures never work. I would like to know if I'm doing something wrong, or am I just using the wrong thing. Just to clarify, this is about planet textures so I'm tagging @Thomas P., @Sigma88, and @Gameslinx. Also tagging @The White Guardian, because he uses GIMP for his textures.

Hi! I'm not quite sure if this is the right place to ask this questions but anyway (: I'm writing a random planetary system generator for KSP. It is an app written in C++ and designed to randomly generate a whole solar system with all necessary configuration and textures. For importing everything into a game, it uses Copernicus. The whole idea is to make it as simple as writing configuration for a generator, launching an app and copying results into gameData. So obviously I can't use any external editor to generate textures for the system. So far I've managed to generate random properties and terrain without major problems. But I've encountered two major issues with : 1. Normal map generation. 2. Creating simple Copernicus configuration that just adds planets with all necessary properties and PQS mods. Problem with normalmap is quite weird : My generator uses LibNoise library to create random terrain and then lodePNG library to convert results (BMP file) into PNG. Example generator output : Heightmap : Colormap : Normalmap : Unfortunately, the map view is broken (Planet looks like ideal sphere without any mesh) : Also, something is not right with the planet shadow : It is probably caused by a wrong normal map. But I have no idea how to fix that. The second problem is connected with Copernicus configuration . Generated copernicus cfg looks like this: @Kopernicus:AFTER[KOPERNICUS] { Body { name = Cyran Template { name = Moho removeAllPQSMods = true } Properties { description = This planet was randomly generated radius = 370000 geeASL = 0.6 rotationPeriod = 525178.380846 rotates = true tidallyLocked = true initialRotation = 0 isHomeWorld = false timewarpAltitudeLimits = 0 30000 30000 60000 300000 300000 400000 700000 ScienceValues { landedDataValue = 2.484671 splashedDataValue = 2.757956 flyingLowDataValue = 2.402657 flyingHighDataValue = 2.481151 inSpaceLowDataValue = 2.797260 inSpaceHighDataValue = 2.140740 recoveryValue = 2.842828 flyingAltitudeThreshold = 12000 spaceAltitudeThreshold = 2.289556 } } Orbit { referenceBody = Sun color = 0.415686,0.352941,0.803922,1 inclination = 1.27 eccentricity = 0.0127567 semiMajorAxis = 409355191706 longitudeOfAscendingNode = 259 argumentOfPeriapsis = 0 meanAnomalyAtEpoch = 2.27167344093323 epoch = 99.6799999999973 } ScaledVersion { Material { texture = randomSystem/Cyran/Cyran_color.png normals = randomSystem/Cyran/Cyran_normal.png } } PQS { Mods { VertexHeightMap { map = randomSystem/Cyran/Cyran_height.png offset = 0 deformity = 12000 scaleDeformityByRadius = false order = 20 enabled = true } VertexColorMap { map = randomSystem/Cyran/Cyran_color.png order = 20 enabled = true } } } } } Configuration structure is defined in generator source code. Only parameters are changing (they are randomly generated). Problem is that heightmap looks quite nice but resulting terrain does not. It is surprisingly boring and flat. My question is: What kind of Copernicus configuration structure I should use to get nice terrain out of heightmap? Please excuse bad english (:

Hello, Could someone please help me create planet textures?

Taking a step back from the "Basic Parts" tutorial which makes the assumption that I wish to add new parts... Is anyone else doing anything with just painting the existing parts by modifying the .dde texture files? It seems apparent to me that I'm coloring something (a texture file) maybe not meant to be colored? ...and wondering if I'm taking the wrong approach or if this is frowned upon as infringing on other people's work? I like to work with the stock parts... but had this idea for a cute Green Cherubs flight team and just had to paint them accordingly. I would like to release a mod for my Green Cherubs flight team which is basically just repainting the stock parts, but I also don't want to offend the Squad devs and/or original authors (PorkJet, NovaSilisko) by releasing a mod that is just their parts with a painted .dde file. Any thoughts? I have not tried to reverse-engineer my way back thru Unity by attempting to reload a .mu file, not even sure if that's possible? Anyone know if the underlying parts already allow for a base color layer? ...if I could get the mesh outline of the part file that would be wonderful. My preference would be to have a clean color map layer for livery and leave the texture file either untouched or maybe polished up a bit for a glossier airshow finish. This is basically what I'm doing:

Dear people, The tutorial @Poodmund suggest me to watch really helped but now I got another problem. I made a texture for the gas giant but there is something I'm missing. It's hard to explain so I'll just show you: https://postimg.org/image/p9kulykod/ The texture has this line. I mean, it doesn't blend well. I don't know how to explain it but I'm guessing you can see it for yourself. Hopefully somebody can help me with this! Thanks for taking a look

Created a new mod to save graphics memory! Without sacrificing parts or texture quality, this mod unloads and loads textures on the fly! Increase texture resolution to max again! Now with updating loading while textures/parts load, IVA texture handling, and caching the full-sized textures! No duplicate textures are loaded into memory! Fixed certain parts, now unloads only once new textures are loaded. DTL disables ATM now, as there are conflicts. On DirectX 9 with tons of parts, the system memory went from 3205MB down to 2520MB! DX11 and OpenGL use graphics memory first, and system memory for spillover, so if you use these graphics platforms, this will not likely show anything on system memory unless you use LOTS of part mods with big textures, or have small available graphics memory. Side effects include: increased loading times at start Slight lag when adding new parts when building craft Increased loading times when launching new crafts VAB/SPH low res "icons". Adding many more mods and/or maxing texture resolution Download Here: https://github.com/rbray89/DynamicTextureLoader/releases/tag/DTL-1.1-1 Currently broken due to unity bug. Working on fix/workaround. This is done in my spare time, and any contribution helps! Source: https://github.com/rbray89/DynamicTextureLoader License (MIT): https://github.com/rbray89/DynamicTextureLoader/blob/master/README.md