Poodmund

Okay, no worries, that's quite disappointing to hear as I was looking to be able to make my mods compatible with Texture Replacer, Texture Replacer Replaced and Sigma Replacements being able to swap each dependency out for another whilst still functioning without a hitch. Without the ability to path to textures in a custom folder it becomes hard for other mods to target my mod if necessary through a Module Manager patch. In light of this, unfortunately I don't think I can support TR anymore as a dependency which is a big shame but it is your mod and I respect your decision to take it in this direction; if this does change in the future I would jump at the chance to add TR back as a dependency.

I would also tend to agree with the above posts regarding the helmet as the white helmet is kind of iconic throughout the Apollo era and in KSP. Also, the noise texture on the Helmet normal map seems kind of weird. Wouldn't the helmet be of a smooth, polished material? Nonetheless, the suit textures seem very nice and show a good improvement in fidelity and character.

It's not really a solution though as that feature is like 50% of what Scatterer is as a mod.

If I have a mod that requires a dependency, but there are more than one mod that can fulfill this dependency, but they conflict with each other, how is it best to set up the relationship for this in the NetKAN file? To be more specific, my Skyboxes require either Sigma Replacements Skybox, Texture Replacer Replaced or Texture Replacer but TRR and TR pose a conflict situation. SR:S doesn't conflict with TRR or TR but the user doesn't necessarily need to install both... but can do. I haven't publically updated my mods yet to have this dependency interopability but do have it working locally and am musing as to how to approach this on the NetKAN side of things.

This proposed change would be a lot more end user parse-able when considering scanner readouts in my opinion. To see a scanner readout say "Ore Abundance: 15%" is a lot more intuitive than to represent it just as an integer with no reference frame. Just my 2 cents.

@shaw would you possibly consider adding in the ability to locate texture files elsewhere within the GameData directory and point them towards TR using Module Manager configs? Something along the lines of: @TextureReplacer { Directories { Default = GameData/Custom EnvMap = GameData/Custom/CustomSubFolder } } And possibly even the ability to point to different file names for the textures, ala: @TextureReplacer { TextureRename { GalaxyTex_PositiveX = SkyboxXP GalaxyTex_NegativeX = SkyboxXN } } This would greatly increase the amount of interoperability/compatibility between mods that use TR without having to overwrite each other and causing issues down the like, especially in situations like installing through CKAN.

That quip doesn't really hold true as its a question directly pertaining to the media released to the general public in this case. I know it was a joke, but I want to make sure people realize that it was as such.

It looks at though the HECS part either lacks a Bump Map or it is very weak. This kind of skews our perception of the visual representation of this part. Could anyone from SQUAD, please, either confirm or deny whether the above screen preview showing the part has a normal map applied to the object or not?

CKAN should automatically update its listings with the latest Kopernicus releases, however, the process it uses to do this operates around timely intervals so it does not occur immediately.

Always nice to see community driven, collaborative frameworks put into place. Good luck with you efforts, Niako.

This looks super cool, Niako. Good to see you taking advantage of new features and being a pioneer of Kopernicus as a developing platform!

I'm not sure how it gives you more work but the benefits of using a Git repository properly, as a non exhaustive list, are: It makes it easy for others to contribute to your projects at source. Documentation! Allows others to raise issues and code changes directly against files that may be causing bugs etc. The repository archives all changes make to all files so it's a great way of storing old versions of files included in the repository. It makes it super easy for multiple people to work on the same project whilst making sure everyone is using the latest versions of the mod files. P.S. I'm sure a good advert of using a Git in the intended way is to look at nearly all the good, highly endorsed mods for KSP featured on this forum. Nearly all the complex, invested mods have a Git platform ingrained into their development scheme.

I just visited your GitHub repository for the 1st time but it seems the mod source is not synched remotely compared to your local source... i.e. your repository is completely blank. Are you intending to use GitHub as the open platform it is intended to be so that issues, pull request and feature requests can get posted against the mod?

Don't invert on your X-axis. You want the light to be coming from the right hand side of the image on your horizontal map.

TL;DR - "We released 1.4.5: Link"