zengei

Yes, and as mentioned in the README that's the black body color scheme that KSP defaults to... which is not very intuitive. This isn't a representation of black body radiation, it's a informational overlay designed to provide information to the user at a glance; when you see something red, you don't think "cool". Instead I've used a color scheme inspired by weather maps that's significantly more intuitive: red is hot; blue is cold.

v0.2.0 is out now for KSP 1.0.3 and has been renamed to "Hot Spot". Big features in this release are support for thermal rate metrics and configuration settings from a GUI accessible from the AppLauncher (settings will be made persistent in a future version).

I've implemented support for all 5 kinds of thermal rate¹ in both the context menu and overlay, but I'm waiting on 1.0.3 and it's potentially breaking changes to the thermal system to release it. See this README for info. I've also renamed the mod to Hot Spot, and it'll be fairly easy to add support for other metrics (not just thermal data) in the future. ¹To my understanding, the way KSP uses "flux" is this context is a misnomer. A flux is a change in some quantity per unit area. From what I can see all of KSP's "flux" measurements are simply changes in energy per unit time (i.e. a power), so I've chosen to avoid using the word "flux". - - - Updated - - - BTW, if you want to give the new version a try you can download a nightly build from here; remove the EhancedThermalData folder of course. This is not an official release of course and will very likely break with 1.0.3.

Thanks, it's a known issue. - - - Updated - - - Looks like it's a pre-existing bug not related to the new export stuff (good, because that means it's not my fault). Should be easy enough to fix though.

CaptRobau, Heads up, I've submitted this pull request (and it's been merged) that allows Kopernicus Body nodes to specify a cacheFile property, which is a GameData relative path to the PQS cache file. So you should be able to do... Body { name = Sarnus cacheFile = OPM/KopernicusCache/Sarnus.bin } ...and distribute the cache files inside the OPM folder. This should be in the next version (after 0.0.7) of Kopernicus. This should make the entire OPM installation a single folder.

It's already on Kerbal Stuff. As for CKAN, questions like that should go to the CKAN thread as most mod authors don't maintain their own CKAN metadata. In this case Streetwind has volunteered to assume maintainership of all of the CKAN metadata for Nertea's mods. We're waiting for his pull requests to make any updates.

Note, when parts are around room temperature it's perfectly normal not to have any color. If you want to see some color even then, you can create a MM patch and stick it somewhere in GameData like: @ENHANCED_THERMAL_DATA:NEEDS[EnhancedThermalData] { @THERMAL_OVERLAY { @GRADIENT { @STOP[Standard] { @color = #888888 @alpha = 1.0 } } } } This edits the gradient stop at room temperature to be fully opaque (@alpha = 1.0) and makes it grayish (@color = #888888) (pure white doesn't look very good).

Well the good news is that unless there's a bug in the temperature display (highly unlikely, it just reads the temperature right off the part) the overlay is accurate. By default anything below 273.2K (freezing point of water) will be blue transitioning to purple the colder it is. The unhighlighted parts are ~287-289K, basically room temperature, where the color gradient transitions to fully transparent so there's effectively no color. Why those parts are so much colder than the others I couldn't begin to say, I just show the data. I would guess maybe because those parts were in space much longer so they had time to cool down radiatively, but if I read your initial post correctly the cooler parts were the more recently launched ones? /me shrugs

What are the temps of the highlighted and non-highlighted parts respectively?

Hot Spot Hot Spot is a MIT-licensed mod that displays better thermal data to the user. Download CKAN as HotSpot GitHub Information For more information and installation instructions please see the README. For changes please see CHANGELOG. For future enhancements please see GitHub issues. Source: GitHub License: MIT

I've written many metadata files for CKAN, if a file exists in a folder you don't want installed it can be filtered out; it doesn't have to be put into its own folder. See for example the entry for KW Rocketry's Legacy Fairings, which I wrote. CKAN goes to extraordinary lengths to make sure it can work with any sort of complex structure a mod may be distributed in. If problems exist with how the current NF mods are packaged, can you raise the specific issues on GitHub and we can sort it out there? Advocating structural changes to how a mod is distributed is rarely done unless totally necessary and is generally done to make the mods better in general, not just for CKAN.

It does.

It's source control, all the code is in the history. v1.3.1 isn't specifically tagged, but revision c6951303 seems about right.

No folder structure changes are required to support CKAN. What issues do you see with the current metadata?

This looks more like a .ckan file than a .netkan, a .netkan is a skeleton that is consumed by NetKAN to generate a .ckan. Few things: name, author, abstract, download will all be filled in by NetKAN. x_generated_by is only used by NetKAN itself when it actually generates a .ckan. The KineTechAnimation dependency is still listed as being only compatible with KSP 0.90 in CKAN, is it actually compatible with 1.0? Unless that's updated, CKAN won't list your mod to 1.0.x clients anyway. A few trailing commas in the arrays, the bots will barf at that. File paths have to be against the root of the archive which contains a Mk2Expansion-1.1.2 directory. Since that will presumably change with each release, we can use a find clause instead (which requires bumping the spec_version to v1.4). optional and description aren't valid clauses in an install stanza according to the spec. Optional parts of a mod are implemented using another identifier. Updated examples: { "spec_version": "v1.4", "identifier": "Mk2Expansion", "$kref": "#/ckan/kerbalstuff/790", "license": "CC-BY-4.0", "depends": [ { "name": "KineTechAnimation" }, { "name": "KlockheedMartian-Gimbal" }, { "name": "ModuleManager", "min_version": "2.5.1" } ], "suggests": [ { "name": "InterstellarFuelSwitch" } ], "install": [ { "find": "Mk2Expansion", "install_to": "GameData" } ] } { "spec_version": "v1.4", "identifier": "Mk2Expansion-Ships", "$kref": "#/ckan/kerbalstuff/790", "license": "CC-BY-4.0", "depends": [ { "name": "Mk2Expansion" } ], "install": [ { "find": "Ships", "install_to": "Ships" } ] } { "spec_version": "v1.4", "identifier": "Mk2Expansion-TankSwitch", "$kref": "#/ckan/kerbalstuff/790", "license": "CC-BY-4.0", "depends": [ { "name": "Mk2Expansion" }, { "name": "InterstellarFuelSwitch" } ], "install": [ { "find": "Patches", "install_to": "GameData/Mk2Expansion/Patches" } ] } NOTE: I haven't actually tested that these install correctly, but they give you an idea.

Post your .netkan file?

Oops, that should read they do now have plans Quote from Josh Peterson in the comments of this blog post:

I don't think it's particularly customized, but it is an ancient version that they haven't upgraded due to a licensing disagreement with Xamarin. But last I heard, they do not now have plans to upgrade to a version of Mono from this decade (which sadly isn't an exaggeration, Unity uses Mono 2.6 which was released in December 2009).

It's already in CKAN as SpaceShuttleEngines.

What about it? It's on CKAN.

You can, but you have to uninstall KopernicusTech. There's a legitimate conflict there, which is why CKAN balks.

Note, Unity doesn't use .NET, it uses Mono, which is a reimplementation of .NET for Unix-like systems. Any work Microsoft does would have to be incorporated into Mono first, although that's a lot easier now that a good chunk of .NET is open source and under permissive licensing.

This is correct, OuterPlanetsMod provides its own version of Kopernicus, which is used by CKAN. CKAN will continue to use the Kopernicus provided with OuterPlanetsMod until such time as there's a standalone release of Kopernicus compatible with it. Remove KopernicusTech if you want to install OuterPlanetsMod.

CKAN has been updated.

One heuristic would be to check if the altitude of the terrain below the spacecraft is, let's say between -10m and 0m. Problems with that include: 1) That would be true for lakes and rivers where you don't necessarily want the sound to play. 2) Ideally you would also want the sound to play while near the coastline but on land. What you really want is the distance between the active vessel and the nearest Water Biome/Shore Biome border. One option to get that would be to: 1) Get the current biome of the active vessel 2) Sample X number of points in a fixed radius around the vessel 3) If the biome of the vessel is Water and the biome of one of those points is !Water or vice versa, you're on the shore. Again, that has problem #1, but not #2