danfarnsy

Any chance you can make RCS thrusters attached to the Spectra utility module fire uncontrollably after docking until all monoprop is expended? It would be a nice realistic touch.

Because the extras are just .cfg files, it's fine to put them as GameData/SystemHeatConverters/stuff or GameData/SystemHeat/SystemHeatConverters/stuff . I wouldn't recommend putting the contents of SystemHeatConverters directly in GameData, since that will spread the files all over GameData/Squad, GameData/NearFutureElectrical, etc. It would still run, but updating would be messy and probably lead to conflicts.

Thank you for sharing. I also was missing this library and had the same issue. Weirdly, MechJeb worked fine without ToolbarControl and ClickThroughBlocker installed, but then spammed NREs and wouldn't draw windows correctly with LGG's tools installed. In addition to the picture @Virtualgenius included, MJ was missing several parts like orbit and surface info, also couldn't find/display information like delta-v to add to custom windows. It was very strange. I don't see SpaceTux Library listed as a dependency for either ToolbarControl or ClickThroughBlocker, nor included in the downloads. But installing it did resolve the conflict.

Thank you. My ignorance didn't come from over-engineering but under-playing. I've been on other games for a bit, but I still follow the forums and look at change logs, which have had little mention of emissives. Sure enough, they work now! They didn't when I had last tested months ago.

I've had a few designs using the large static radiator modeled after the ship in Avatar that looked pretty cool, though I frequently end up replacing it with microchannel for weight and performance. I also would love to see emissives integrated with SH, if possible.

I love good IVAs and good views out windows. I've much appreciated the previous work you've put into them, and, for me at least, it's definitely not wasted. Thank you.

That meaning is not good.

I vote yes. Messing up in-flight craft isn't nothing, but there aren't additional gameplay reasons to keep incorrect ratios here. Probably would need a big warning. Edit to add: since these are controlled by config files, maybe a MM optional patch to preserve the incorrect ratios until they're ready?

So, fun tidbit. He had a no-graphics version of his NSWR that he posted a link to on Twitter. I brought FFT to his attention, suggested he could use it for graphics.

Most aspects of this mod seem to be working well. I'm enjoying the "more but lighter" radiator changes. Two notes: I caused problems for myself when I docked two ships with loops on the same loop ID. Even after undocking, changing loop IDs, and redocking, they were put back on the same loop. I haven't tested this rigorously. I haven't seen radiator emissives glowing. Are they working for anybody else?

Rich Kerman is a steely eyed missile man. What a read! You've inspired some changes for my own ship designs, too.

You can install FFT and its dependencies without conflict. If you want Near Future Electrical and Kerbal Atomics parts to work the same way as FFT parts do with SystemHeat, SystemHeat has optional patches for NFE and KA, but ships you have already in flight with fission reactors and engines may break (e.g. for not having enough radiators). So, it's safe unless you want a more cohesive integration with SystemHeat and the older mods.

They also provide fast transfers or high payload fractions for closer planets, or having multi-planet tours with transfers well outside the normal windows. You do so very much. Thank you.

Ratios look good now! Two converters on the Squad ISRU aren't producing any heat: LH2 + Ox and Ox. The others, including the converters on Whirlijig and Vulcan, generate heat correctly. Large and small drills have very different efficiency curves. Smaller drill is 100% efficient through 400 K, then drops toward shutoff temp. Larger drill drops off nearly linearly from 0 K, with 50% efficiency at 350 K. Not necessarily a bug, but is inconsistent.

Since those are just Module Manager patches, they just need to go somewhere the GameData directory. I've put mine in GameData/SystemHeat to keep from cluttering the GameData folder.

ConfigCache here. I made a sandbox test save, testing by removing FFT, SpaceDust, SystemHeat, and Waterfall. The converter worked correctly with those uninstalled. Then I re-added them, tested again using identical craft, and the issue reproduced. So if the issue is only on my end, it's at least from some conflict with these FFT requisites. Here's what I got from testing: LiquidFuel converter, alone, converts Ore to LqdFuel at 1:1 ratio. Oxidizer converts at 1:1 ratio. LqdFuel + Ox produces 1 LqdFuel and about 60ish oxidizer per 1 ore. Lots of free oxidizer appearing from nowhere. Monoprop converts at 1:1 ratio. LH2 converts at 1:1 ratio, and about twice the overall speed of conversion as liquid fuel (e.g. liquid fuel at 0.62/sec, LH2 at 1.22/sec) LH2 + Ox produces LH2 at 1:1 for ore, plus about 60ish oxidizer per ore, similar as LqdFuel + Ox converter, getting free mass from nowhere. I did not test methane or lithium converters. Edit: LCH4 converts at 1:1. LCH4 + Ox gives huge amounts of Ox, similar to LqdFuel + Ox and LH2 + Ox. Lithium converts at 1:1

Could the recent SystemHeat ISRU changes be overriding the resource ratios from the CryoTanks ISRU patch? With the latest update, things seem to be generating heat correctly, but my 2.5m ISRU is converting Ore to LH2 at a 1:1 ratio, instead of 1:141. I'm not 100% confident SystemHeat is to blame. The only mods in my log modifying the ISRU and MiniISRU parts are SystemHeat, ReStock, CryoTanks, NFP, and FFT. These last two are lithium specific. ReStock doesn't appear to be touching the actual resource module, just the emissives. CryoTanks specifies ratios for LH2, LH2+Ox, methane, and methalox, which aren't being respected. SystemHeat seems to replace the converter modules with moduleIDs converter6 and converter7 for the cryo fuels, with no ratios specified. It's not clear to me how ModuleSystemHeatConverter is supposed to work. Log is here.

I had something similar, but I didn't suspect waterfall. I was using FAR, and the issue didn't persist when I removed FAR. Is FAR also a part of your mod list?

Nice. There's some parts on there I don't recognize. What's that RTG and boom?

This cleared up a lot. Thank you. I'm looking forward to testing when it's available. I'm thinking of a few use cases I expect to backfire. Here's one: ISRU on Loop A operates at 450 K. Reactor and radiators are stable on Loop B at 800 K, and have an extra 200 kW radiative capacity. I add the exchanger between A and B, sending 200 kW of heat to B. The exchanger has an outlet temperature of 450 K on Loop B, so now loop B has a nominal loop temperature of 625 K (average between reactor and exchanger), making the radiators on B less efficient and failing to actually reject the extra heat. The reactor then overheats and shuts down. This sounds like fun.

I like the idea. A few things I'm thinking about: Currently, the nominal temperature of a loop is determined by heat source parts, like drills, ISRUs, reactors. Radiators just try to get rid of heat in excess, e.g. you can't use radiators to make an 800 K reactor 650 K (though you could use the current compressor part for that). Since radiators don't determine the preferred nominal temperature of a loop, what happens with a loop that only has radiators on it, with an exchanger pumping to it? Does the exchanger count as a source on Loop B with its own preferred nominal temp? Does the exchanger draw more electrical power to pump as Loop B gets that much hotter than Loop A? And if so, does that cause a reactor on Loop A to increase throttle, providing more heat that needs to be rejected, creating feedback in Loop B?

Looking again, they do indeed bump loop ID for all parts in the loop. I may have reported this wrong before, as it is working correctly. Loop IDs bumped enough times get to Loop ID **Not Found**, after which it won't increment to 0 again. Other bugs with loading, etc. seem fixed. Nice. I don't intend to be argumentative about the sources and radiators balance, since you explained your concern about simulation, but I just wanted to still give the feedback that it feels weird to have a system that is perfectly balanced at 805 K, deactivate a radiator for a moment while the system climbs to 1005 K, then turn that radiator back on, and have the system be in perfect equilibrium at 1005 K as well, even though the radiators are hotter. Should radiators balanced with sources ought to be able to bring temperature back to equilibrium at Loop nominal temp? I won't beat that horse any more. Just wanted my feedback to be clearly explained.

Porcine aviator dudes are the best! Man, there's so many good people who've had such a good influence on this game.

Turning on individual loops, or lighting up individual parts with a highlight? Visualizing the idea that they're call connected in a loop is cool, but the lines with their right angles take up a lot of real estate. So, what if a compressor is a way for two loops to send heat to each other? Use cases there are great. You'd have to figure out whether the compressor's own temperature and heat output belong to the sending or receiving loop, and probably have its efficiency and effectiveness decrease if it gets too hot. That makes sense. In my test, I had Loop 0 and Loop 1. During flight, I changed one part in Loop 0 to Loop 1, and then all System Heat parts on the ship displayed Loop 2. If I tried to change a Loop ID on a part again, it incremented all of them to 3, 4, etc. It was definitely buggy. Maybe it should go the other way around. Right now, your radiators have linear response to nominal loop temperature. E.g. the GR-150 on a nominal loop at 1000 K radiates 100 kW, and 80 kW for an 800 K loop. As long as your heat sources have predictable maximums, and the actual temp of the loop is below the radiator max, then it should be easy to know at what temperature radiator output matches heat sources. E.g. Eight GR-150s on an 800 kW reactor will only radiate 640 kW at 800 K, so the temperature will continue to rise until the radiator max temp of 1000 K, at which point radiation = sources. Seven radiators will peak at 700 kW, which isn't enough, so the temperature will continue rising until core failure. Nine of those radiators will peak at 888 K and then hold steady, etc. And... I just saw your update! I will try it later today.

I've been doing some testing. Here are some things I've noticed. Craft with fission reactor load on the pad with varying degrees of core health. E.g. I have a mining/refining platform test on the runway, with a Garnet reactor, which loads with varying amounts of core health each time I revert to hangar and then launch again. The amount on load is anywhere between 100% health and core destroyed. The UI overlay gets really cluttered, such that it quickly goes from being informative to being overwhelming and unhelpful, depending on how you're clustering radiators, compressors, etc. I don't exactly know what the compressors, coolants, and heat sinks do. I know what those things do in real life, just not how you're implementing them here. If a compressor is set to heat the temperature of a loop, everything in the loop heats up together, so I can't make my radiators more effective by pumping them up to a higher temperature than my core. If a core is at 800 K, then I need more/bigger radiators because they can only reject so much at a lower temp. If I don't have enough radiators for the max heat output of a reactor, but my system isn't drawing much, the temperature remains fine. I can adjust it downward or upward with a compressor. But if I try to adjust the temperature too far downward, the compressor draws more power and the loop overheats. This is awesome. I don't know how much of the heat of the system is changing because the reactor is generating more heat to supply the additional power, or how much is because the compressor part is adding its own heat to the loop. Is loop volume just the total thermal mass of the loop, i.e. everything has a same specific heat capacity and you're just changing how fast or slow it changes? What's the difference between a heat sink and a radiator? Sink seems almost limitless. Heat sink storage temperature rate of change doesn't change with time warp. Heat sink storage temperature doesn't appear to have anything to do with loop temperature, just rate of heat input from generators? Heat sink percentage stored seems to plateau around 85-86%, even though its temperature keeps climbing. With two heat sinks, only one is filling and the other remains empty. Does it fill one first and then the other, and I just haven't reached max capacity on the first? Now one is at 87% filled, 3800 K, while second heat sink is empty. In flight, if I change the Loop ID of any particular part, all of the parts change what Loop ID they display, and none of them seem to match reality anymore. Are those supposed to be fixed in the VAB and no longer changeable in flight? Edit to add: Radiator efficiency changes with temperature in the simulator in VAB, does not seem to change with loop temperature in flight scene. Loop with Garnet powering a Charon MHD and eight GR-150 radiators will overheat well past 1000 K, even though GR-150 says it radiates 100 kW at 1000 K. Exactly 10 GR-150s will keep up with 800 kW heat output, regardless of loop temperature between 800 K to 1050 K. Radiator efficiency is listed as "-80%" on part info panel at all temperatures. Notes: System Heat Development version as of 12 Aug, NFE 1.1.2, KSP 1.9.1.