Nertea

It's dooooone.... https://imgur.com/CbPAl42 https://imgur.com/a/Uk5HIIU

As the HeatControl thread is a little obscure, please contribute to my radiator market research!

All. Also, please contribute to my market research! (Please also feel free to leave your thoughts on the future of Heat Control, I'm working on roadmapping this to feature complete right now)

Uh, you may be disappointed but I will be removing/ replacing those in some future release. That's why they haven't been patched, I don't actually *want* people using them ;).

Pretty sure it already has one!

Well... no need to get stressed. If things go in the wrong place I will 100% forget and miss them. I was just letting you and coyotesfrontier where comments should go on that content!

Those mechanics are not part of Kerbal Atomics, they are part of system heat, you have to install both SH and an optional patch for it. I really have to enforce things being in the correct thread because otherwise content will be lost and users will be confused.

This is not the right thread to discuss System Heat. Let's just understand I am aware of the whole garbage nature of the system now and 'll figure it out eventually.

Your concerns have been noted.

Version bumped for 1.12.

DBS 2.2.3 Marked for KSP 1.12 Added support for SCANSat

I haven't found any issues with 1.12 so have marked this as compatible. WaterfallRestock will not be updated to 1.12 until restock gets there.

Marked as updated for KSP 1.12.

Yeah i've confirmed it's just a UI bug, will be fixed in 0.5.0.

Yes, there are some changes but I'd ask you to please bring these to the SH thread instead of here to limit confusion.

Could just be a sign file in that UI bit.

I took the screenshot before the temperature had stabilized, that will have to be corrected. There's nothing in SH about temperatures being too low - that is too much complexity. Yes there will be no effect there. In fact, unless you install the compatibility patches SH won't even touch core heat parts. Yes, the 'internal' and 'skin' cooling systems from stock are untouched. It's currently linear (which is wrong, should be quartic), for easier player understanding. They just operate at their maximum rate - anything else would be really player-annoying. It is very small, it may actually be faster than core heat. Yes if you install the compatibility extra. I will increment the NFE version to 2.x when I do this. All 1.x releases will use core heat, 2.x will use SH.

I dislike video things, they take a lot of time to make. Did you go through the tutorial? https://github.com/post-kerbin-mining-corporation/SystemHeat/wiki Only those Old craft won't work well. So there will be one 1.12 update to the old NFE mechanics, then that branch will no longer be maintained.

The stock heating system isn't very stable. I prefer the one I wrote, which is stable, more customizable and has a better user interface.

It does. It can Discover resources from 300 km away and Identify them from 100 km away. Not in this mod. The tools in this mod are oriented towards stock resources. There is a balance between telling you everything. The map UI will tell you visually where a band is, but you need the in-situ scanner to go down and localize it precisely.

I haven't set the rotation rate yet, but you can set that in the module configuration and it calculates it (as in the current stuff) The endcaps are 5m.

@RoverDude I do disagree that no mod should ever edit another mod's stuff. Lots of mods do that, it's up to the author of the 'editing' patch to be clear that they are the support resource for the supported combination. If RR wants to screw with somebody else's resource distributions via MM, whatever. It's just now RR's problem. I realize how it changes the support model but fundamentally you can't make a license that says 'don't MM my stuff', you just need to spend the time setting up the process (canned reply, etc) for when the conflict inevitably comes up. @FreeThinker The point here is to get this argument out of CRP. If two mods have different ideas of balance right now it becomes everyone's problem, rather than a discussion between say, the RR and MKS authors. Better to have the community thing stable and fairly immutable than go through this every time an author wants to tune a distribution slightly.

The scanner thing is nice. I've had users complain about CRP causing bloat in this set of windows when it really shouldn't.

Yes I would prefer this also. Because fundamentally overlapping resource distributions don't conflict, they don't need to be defined in a community deconfliction pack.

Sorry, no plans to do this. I just got this bad boy all baked and animated! It was an extremely long and frustrating road!