Poodmund

To save myself the rigmarole of doing it all again in the future, you can extract the in-game assets using something like https://github.com/Perfare/AssetStudio or https://github.com/DerPopo/UABE and then open the asset bundles in KSP/KSP_x64_Data folder. Export all 17 of the asset bundles and then you should be able to find all the textures and filenames you need. Pro-tip, use the AssetStudio software, then load the whole KSP_x64_Data folder and then go Filter > Texture2D then Export > Filtered Assets, this should export all the textures from the whole game. Then sort the extracted files by filesize descending and the large textures should be near the top.

Could you please elaborate as to what mod this was so that it can be looked into please?

I think Mircea has been misunderstood in that I think the statement of intent was more one of "if the current dev team do not have the time or wish to put an incredible amount of spare time into the mod, is it time to look for new dev blood?"... which is not a bad sentiment... however, I think the current dev team have always been open to new blood to help with Kopernicus to a competent level but volunteers are hard to find. In short, everyone can wish the best for the dev team but if no one steps forward with the capability and enthusiasm to help Thomas, Sigma et al, then it makes no difference either way. We can wish the mod gets updated when a new KSP version comes out but that's all you can do as a consumer, wish.

@Danilo Coelho these are the parts that I whitelisted when using MKS, FTT and Karbonite: Squad/Parts/Resources/RadialDrill/ Squad/Parts/Command/advancedSasModuleLarge/ Squad/Parts/Utility/dockingPortSr/ These were the only stock parts that were referenced in RoverDude's mods as far as I am aware. Please let me know if you are aware of any more parts not working correctly.

That's a fair assessment, much like how Kerbalism used to be with stock EC mechanics etc. Anyway, glad it's sorted for the future.

No worries, always happy to help with interoperability between mods. Pedantic semantics but it only affects vanilla assets and not modded assets. At least it's not affecting parts that are created by mods... catch all solutions are a fallacy but they can be good with a little bit of elbow grease work. If you come across any more issues between the mods please let me (us... ReStock team) know and we can hash out PRs if necessary.

I already did do so a few weeks ago so you should be good to go.

I submitted Pull Requests to add whitelists to RoverDude's USI mods a while back but as if this time he has not accepted them into the mods. You can go grab them from the open Pull Requests, I think, off the top of my head, they were for MKS, FTT and Karbonite. EDIT: RoverDude has just been made aware of this and I expect will accept the PRs in due course.

Simply put, yes. Only vessels that already exist in the SOI of Eeloo are affected by installing this mod and if you just happen to have any vessels really far out from the Sun that by the tiniest chance exist within the SOI space of any of the new bodies that are added, then they will be too... although rediculously unlikely. OPM 2.2.5 should still work fine with the updated Kopernicus in 1.8.1 and it's probably time I get to work on something akin to an OPM 3.0 update or something. ----------------------------------- Anyhow, v2.2.6 has just been released. Hardly anything changed, just a version bump to show as compatible with 1.8.* and deprecated support for Antenna Range and ClassicStockResources as their is no longer uptake.

Yes, the ability for the mod devs is there to utilize but the existing planet mods will have to updated to use this feature.

Its an honor that you've graced this thread, I think on behalf of everyone in the KSP community that has used Gaseous Giganticus its a big THANK YOU! With regards to the projection change it is hard to tell from an equirectangular projection what the distortion is going to look like but it depends quite considerably on the program used to do the projection change. Here is a small collage of 8192x4096 equirectangular textures made from generated 2048x2048 cube faces mapped onto a spherical mesh and rendered out in Photoshop as a preview, they aren't the best generated textures but they get the point across I think: You still retain a fair amount of detail at the more extreme latitudes surprisingly. In Kerbal Space Program, with the use of other mods we can also apply more detailed, seamless alpha-mapped textures that take can reduce the apperance of a pixellated surface when the space vessel (camera) is close to the body which can help avoid this issue somewhat.

- How to generate procedural gas giants using Gaseous Giganticus on Windows 10 Gaseous Giganticus is a utility program created by Stephen M. Cameron for the usage in his game Space-Nerds-In-Space that uses Curl Noise to simulate Procedural Fluid Flow by simulating the curl of the gradient of a noise field to produce a chaotic but divergence free velocity field, dumping a bunch of particles initially colored according to input image and then moving those particles around according to velocity field and rendering the output image... then iterate over and over. By doing this on a spherical noise field representations of gas giants can be created with great success. Please see the tutorial below in the spoiler box for more information: You can find examples of gas giants utilizing Gaseous Giganticus to render their maps in mods such as Beyond Home, Galaxies Unbound, JNSQ and my OPM-VO mod. I hope that this will help you create awesome gas giant textures for your planet modding needs!

Disabling the stock contracts using MM is unnecessary as Contact Configurator allows you to do so in the in-game settings menu. You can enable/disable all contract types and mods through that GUI.

- How to generate realistic(ish) below Sea Level terrain Please open the Spoiler Box below to view the tutorial (lots of images so it's better stored in a spoiler tag). I hope that all of this helped, please let me know if you have any further queries.

Thanks, ManeTI, you da' hero.

Yikes, thanks for the confirmation. (Damn WYSIWYG editor won't let me delete quote/code/spoiler boxes on my Android text editor... stupid forum software!)

How are tags set against our mods?

I say this in the most genuine way possible, but it seems a bit of a shame that TR does not allow for interaction with loaded assets via Module Manager whereas similar mods such as Sigma Replacements, DiRT and even TRR when it was around all required folder paths/file URLs to be specified within their config nodes to load the textures in question i.e. SigmaReplacements { Texture { Folders { path = asset/path } } } DiRT_Config { TextureFolder = asset/path } TextureReplacerReplaced { Folders { Default = asset/path } } This allows modders and users to then interact with config nodes that can resolve compatibility and interopability issues between mods. For example, if a user installed a visual pack that uses TR to override the stock planetary body texture assets but then also wanted to install a mod that uses TR to override Jool's texture with a very specific texture, the end user is at the whim of the naming of the folders as to which texture would be used from the two options. The desired result would be that the user ends up with the specific Jool texture. This could be achieved by having the mod devs specifying the asset URLs/asset folders in a config for TR to pick up on game load and utilize, then the mod dev of the specific Jool texture could include a config in their mod to say something like: @TextureReplacer:FINAL { @Textures { !path:HAS[*stockJoolAssetName] {} path = newAsset/path } } This patch would delete any preexisting entries for that specific texture and then add in the patch to insert the inclusion for their Jool texture only. ---------------- On a personal note, the trigger for raising this is due to a handful of planet packs including their own skybox with their mod but a decent number of users want to use a different skybox. When they use SR:Skybox/Textures or DiRT you can make allowances for this and patch accordingly with a "catch-all" patch to ensure that the "after-maket" skybox they download is the one that is used but if they currently use TR, then as previously said, they are at the which of the mod folder alphabet order as to what they end up with. I hope that you can appreciate the concern... I also appreciate that it would be a lot of work.

I'll keep this in mind for a future update.

YES, WE GET IT... its the 27th of Jan and this pop up is still persisting. There is no way to remove it without it reappearing all the time. Do I have to pay someone in Kerbal blood to get them to stop it from hanging around all the time?

That's due to Duna's ScaledSpace map now being named "Duna [Albedo]" in the game assets.

@shaw if two Skyboxes are installed in directories outside of the TR folder, how does TR intelligently handle the loading of a specific skybox? Is there a way that we can specify to TR which to use?

Oh, yeah, that skipped my mind. Very true... well, if that is the case then hopefully something IS changing to allow for that easily as its a really desired feature I guess.

Oh, I was asking if you were aware of any API changes being made as I am not currently aware of any information to that regard. If there are no API changes, then that would indicate that Dragon01's assumption would be more towards correct than false... but as always, we will have to wait and see.

Are you aware that they are changing the API specifically due to the new changes being made to Kerbin, rather than just using the exisiting implementation of the shaders to improve Kerbin as per the rest of the revamped bodies?