danfarnsy

Feedback for WOLF in a career save: I know the different parts of the resource chain are all interconnected so it's hard to implement a few components without all the others, but the bulk of WOLF (using CTT) is at the end of an 8,000+ science points research chain. Besides the basic resource extractors (which, don't get me wrong, are very useful), it's hard to increment gradual increase in WOLF capability alongside gradual increases in MKS colony capability. That is, you have to build out a regular messy pre-WOLF style resource chain anyway before you get anywhere near unlocking the parts that are intended to abstract that away, which feels like it's conflicting with itself. I don't have a proposed solution, just thought I'd share my impression. Also, a question: is there any way to later undo additions to a depot? Adding MHU-100s to a biome doesn't consume power (that can't be added until the tech is unlocked), but it consumes just as much ResourceVein as MHU-500s. Is there a way to later upgrade, so you're not, for example, permanently locking out most of a biome's ore production?

Early career station, munar night:

Similar shadow bug. Running in 1.12.1, with Kopernicus release 56, on Windows 10 with an old computer. I've tracked it down to Kopernicus and certain new part textures, but not older part textures. Example: A test vessel with both older and newer Nertea parts, with Kopernicus installed, shows funky shadows on the newer parts, but not the older ones, past a certain draw distance from the camera. The issue goes away with Kopernicus uninstalled. This took a long time to troubleshoot. Pictures follow. Test vessel without Kopernicus: Test vessel with only Kopernicus added: Zoom up on vessel with Kopernicus to show camera distance cutoff for the issue: I hope this helps you narrow things down.

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.