[1.12.x] SystemHeat - a replacement for the CoreHeat system (November 20)

[modus]

Haven't seen one yet...

[Grimmas]

I was looking at it earlier this year when I wrote the SystemHeat patch for FUR. It's not very difficult but you'll likely need to write some C# code for this. I'm not sure it could be done purely with MM patching. SystemHeat works by replacing (MM patching) stock converter/harvester modules with their custom SystemHeat modules. But MKS does not actually use the stock converter modules but rolls its own (USI_Converter and  from USITools mod - does not even derive from the stock converter) and also adds another custom module to enable hotswapping of USI converters (USI_ConverterSwapOption). So at the very least you'll have to come up with your own custom module for enabling hotswapping of SystemHeat converters. 

[modus]

@Grimmasjust FYI, SH release 0.5.0 had

"Added ModuleSystemHeatBaseConverterAdapter, a new module that can adapt anything derived from BaseConverter to SH"

which mister Nertea explains as follows: "It is not very relevant for users but will allow people to write patches that integrate SH functionality to modules that are derived from the stock BaseConverter." and "This is more for taking mods that don't have anything to do with SH (specifically targeted at MKS) and allow them to be adapted without touching the other mod's code at all. "

(page 22 of this thread)

and on page 23, where someone asked for a USI patch, the same señor Nertea said:  'it's doable with just patching as of 0.7.0 ' (which seems to be a typo)

 

 

[Grimmas]

Actually USI_Converter does derive from ModuleResourceConverter (sorry about that - there are two different versions of that class, I was looking at the wrong one earlier) but the above doesn't solve the issue of hotswapping (that's not a feature available in stock) or the Addon side effects of USI converters.

Without custom code here, you'll lose the ability of retooling your converters and you'll lose the ability of having converter side effects (like consumption of the secondary resource Machinery and production of Recyclables, or the efficiency bonuses from Kolonists, or possibly even the custom catch-up mechanic). All of those are core features of MKS parts.

So yes, while technically you can probably get away with only MM patches but it will be a severely suboptimal, possibly even broken experience and not in any way representative of how MKS should play. 

 

Edited November 9, 2021 by Grimmas

[modus]

I thought all that was fixed with 0.5.0, but I'm too much of a noob to argue here 

It's just that when I look at the conversations about an MKS patch in both the SH and MKS threads chronologically, in january @Nertea said

and (also look at what Roverdude says)

 

while in august (so after the 0.5.0 release) he states in the MKS thread 

but again, I'm too much of a layman to say anything relevant about what actually has to been done. It is offcourse not desirable to end up with broken gameplay.

(I also don't really mind if there's no patch -wouldn't say no though-, in my head canon it's just two different companies using different technology)

 

 

[Grimmas]

Rather than look at what people say you should look at the actual code and parts definitions and patches in question  Because no matter how many quotes you see from people saying something or other, at the end of the day only the actual code is going to be running on your machine. 

TBH even though it will almost certainly require coding it's actually fairly low effort to implement this, there just hasn't been anyone willing to do the legwork so far. The ModuleSystemHeatBaseConverterAdapter you cited above provides a clue. You could do something similar for MKS - derive a replacement module from USI_ConverterSwapOption and add ModuleSystemHeat through composition like ModuleSystemHeatBaseConverterAdapter does, then call into it when/as needed. That is probably already 90% of all that needs to be done (the other 10% mostly being writing the MM patches using that module). Might be a good weekend project for anyone looking to get into modding KSP (or you could try the MM patch-only approach and see how far you can get, though I don't think it's reasonable in this specific case). Of course, that would be a fairly rudimentary support, but it should be enough to make it work.

Edited November 9, 2021 by Grimmas

[modus]

Like I said I'm not trying to prove you wrong or argue with you. I'm not even asking for a patch.

Was just pointing out something by quoting the mods author (who, imho, isn't just 'people' and very much better placed to comment on this), that's all. 

[Grimmas]

No worries, I am not arguing with you or proving anything, I am simply telling you why I don't think it's gonna work with only MM patches, by looking at the actual code in question (which at the end of the day is the only thing that really matters). Nertea himself said that it's untested, too. And I did not read both code bases from class to class, just looked at the relevant classes here, so there's still room for me being wrong of course.

I would write this compatibility patch myself but currently I'm not playing my USI save so I have no real interest in that patch (this may change in the future). 

[Nertea]

On 11/9/2021 at 8:39 AM, Grimmas said:

TBH even though it will almost certainly require coding it's actually fairly low effort to implement this, there just hasn't been anyone willing to do the legwork so far. The ModuleSystemHeatBaseConverterAdapter you cited above provides a clue. You could do something similar for MKS - derive a replacement module from USI_ConverterSwapOption and add ModuleSystemHeat through composition like ModuleSystemHeatBaseConverterAdapter does, then call into it when/as needed. That is probably already 90% of all that needs to be done (the other 10% mostly being writing the MM patches using that module). Might be a good weekend project for anyone looking to get into modding KSP (or you could try the MM patch-only approach and see how far you can get, though I don't think it's reasonable in this specific case). Of course, that would be a fairly rudimentary support, but it should be enough to make it work.

If things work as expected coding is not needed. ModuleSystemHeatBaseConverterAdapter is specifically designed to NOT require replacing the target module - it just talks to any module derived from BaseConverter to translate heat values. 

The only unknown is SwapConverter, which this should handle in theory too. 

[Grimmas]

That's the main problem actually, the way I see it. AbstractSwapOption does not derive for BaseConverter but is a generic class using BaseConverter as part of its parameters.

SwapOption is used literally everywhere in MKS. Any part that does anything interesting in the production toolchain defines at least two or three swap options. It's the main way USI converter modules get into the parts.

[Nertea]

19 hours ago, Grimmas said:

That's the main problem actually, the way I see it. AbstractSwapOption does not derive for BaseConverter but is a generic class using BaseConverter as part of its parameters.

SwapOption is used literally everywhere in MKS. Any part that does anything interesting in the production toolchain defines at least two or three swap options. It's the main way USI converter modules get into the parts.

I'm not sure you understand what I'm saying so I'll be more detailed.

USI converters and harvesters are both derived from ModuleResourceConverter (and thus BaseConverter). SwapOptions provide different sets of parameters for that converter. When you select an option, those parameters are baked into that converter.

The adapter module doesn't replace or touch the USI converter. It communicates with any module derived from  BaseConverter, which encompasses the USI converters. It does this in a very primitive fashion: it causes the linked converter to add heat to a loop at a temperature, and causes the converter to be shut down if the max temp is exceeded. Nothing fancy. 

None of this directly conflicts with the swap system, which just changes out pieces of the converter (resources converted, rates, etc). The link between adapter and converter is unchanged. 

Like I said though, testing I did here was not a lot. So someone who knows USI needs to validate this. 

[Grimmas]

I see what you mean. I was under the impression that ModuleSystemHeatBaseConverterAdapter should replace the existing converter and be configured in its stead, whereas it seems that the intended usage is actually for it to live alongside as another module on the same part. That does make it more likely to keep it at patch level only.

I would still be concerned about for instance 

converterModule = base.part.Modules[converterModuleIndex] as BaseConverter;

you call this once at Start() so you'd be bound to the old converter even if it gets replaced by swapping later. 

[Nertea]

16 hours ago, Grimmas said:

I see what you mean. I was under the impression that ModuleSystemHeatBaseConverterAdapter should replace the existing converter and be configured in its stead, whereas it seems that the intended usage is actually for it to live alongside as another module on the same part. That does make it more likely to keep it at patch level only.

I would still be concerned about for instance 

converterModule = base.part.Modules[converterModuleIndex] as BaseConverter;

you call this once at Start() so you'd be bound to the old converter even if it gets replaced by swapping later. 

Yup. So generally (and I didn't check everything, hence the hedging) MKS modules have one converter or harvester module which is modified by the swap options. So targeting that module should work. 

[Axelord FTW]

I think I'm finally starting to get the hang of heat exchangers. Balancing heat away is actually quite fun, but until now I kept all my loops very much separate. I fugged it up somewhere the last time I tried them out and steered clear of them since. Well, color me surprised I'm definitely lost.

Spoiler

Loop 9, where the sole radiator is, is kinda overkill but I like my margins, and I tend to keep that loop open for any systems with leeway. I might tone it back a bit, but probably not. The extra coolant tank should give me time to catch up if something unforeseen happen.

It's starting to look like The Strip at night, which is also nice.

Alright, I'm either having a smoothbrain problem, or it's meant to be this way.
If I've got a reactor-at-25% load hooked up to an heat-exchanger, which is pumping all of its excess heat away to another loop (like in the picture above, loop 3 toward 9), and then turn off the reactor at any given moment, the core heat will shoot up like mad (up to 1200K at least) before slowly going back down. It's like the heat-exchanger will only do its thing if it has an 'active' heat producer on the intake loop. A reactor core still need that cool juice while it is spooling down.

I've also had some strange fluctuations in heat intake-outake when going in and out of time warp. One moment I'm fine with the reactor idling at 25% load, the next it'll have to scram.

Edited November 19, 2021 by Axelord FTW

[Gordon Dry]

11 hours ago, Axelord FTW said:

It's like the heat-exchanger will only do its thing if it has an 'active' heat producer on the intake loop. A reactor core still need that cool juice while it is spooling down.

That would be a bummer, though.

[Awesomesauce1337]

Uploading Crash Report
NullReferenceException: Object reference not set to an instance of an object
  at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

(Filename: <faa8f438e27f4148b7041ce82be5b9c9> Line: 0)

CorrectCoL_Persistent.Start
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

KK: [KerbalKonstructsSettings] Start: Career Module Start Called
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

NullReferenceException: Object reference not set to an instance of an object
  at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

System heat spits this out in the log file after I try to place down a  LV-T91 Cheetah engine

[AtomicRocketBooster]

In reference to the USI patch:
I've been noodling with the BaseConverterAdapter bit and have cobbled together a (very lightly tested) MM Patch for the 1.25, 2.5, and 3.75m Material Processing Units:

@PART[MKS_Processor*]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries]
{
  !MODULE[ModuleCoreHeat] {}

  MODULE
  {
    name = ModuleSystemHeat
    // Cubic metres
	// Sets volume to be equivalent to fully loaded mass+machinery
    volume = #$../RESOURCE[Machinery]/maxAmount$
	@volume *= #$@RESOURCE_DEFINITION[Machinery]/density$
	@volume += #$/mass$
	moduleID = isru
    iconName = Icon_Gears
  }

  !MODULE[ModuleOverheatDisplay] {}

  @MODULE[USI_Converter]
  {
    !ThermalEfficiency  {} 
    !TemperatureModifier {}
    
    @GeneratesHeat = false
  }
  MODULE
  {
    name =  ModuleSystemHeatBaseConverterAdapter
    
	systemHeatModuleID = isru
	
    // The shutdown temperature of the part
    shutdownTemperature = 800

    // The temperature the system contributes to loops
    systemOutletTemperature = 500

    // Heat generation (kW)
	systemPower = #$../MODULE[USI_ConverterSwapOption]/INPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]/Ratio$ //set the heat ouput as proportional to the EC usage/Ore.
	@systemPower *= .9  //lets assume 90% of EC usage turns into heat.
	
	moduleID = baseConverter
  }
}
  
@PART[MKS_Processor250]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries]
{
	@MODULE[ModuleSystemHeatBaseConverterAdapter]
	{
		converterModuleIndex = 6
	}
	@MODULE[USI_Converter],1
	{
		!ThermalEfficiency  {} 
		!TemperatureModifier {}
    
		@GeneratesHeat = false
	}
	+MODULE[ModuleSystemHeatBaseConverterAdapter],0
	{
		@converterModuleIndex = 7
		@moduleID = baseConverter2
	}
}
@PART[MKS_Processor375]:FOR[SystemHeatResourceConverters,UmbraSpaceIndustries]
{
	@MODULE[ModuleSystemHeatBaseConverterAdapter]
	{
		converterModuleIndex = 7
	}
	+MODULE[ModuleSystemHeatBaseConverterAdapter],0
	{
		@converterModuleIndex = 8
		@moduleID = baseConverter2
	}
	@MODULE[USI_Converter],1
	{
		!ThermalEfficiency  {} 
		!TemperatureModifier {}
    
		@GeneratesHeat = false
	}
	+MODULE[ModuleSystemHeatBaseConverterAdapter],0
	{
		@converterModuleIndex = 9
		@moduleID = baseConverter3
	}
	@MODULE[USI_Converter],2
	{
		!ThermalEfficiency  {} 
		!TemperatureModifier {}
    
		@GeneratesHeat = false
	}
}

Seems to work as expected in basic usage - haven't dug into any of the efficiency calcs at all, but the switches work decently well.  Also haven't really considered balance at all.  Feel free to play around with it and see what you think.

Edited December 3, 2021 by AtomicRocketBooster
Updated for multi-bay converters

[Nertea]

On 11/28/2021 at 12:59 PM, Awesomesauce1337 said:

Uploading Crash Report
NullReferenceException: Object reference not set to an instance of an object
  at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

(Filename: <faa8f438e27f4148b7041ce82be5b9c9> Line: 0)

CorrectCoL_Persistent.Start
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

KK: [KerbalKonstructsSettings] Start: Career Module Start Called
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

NullReferenceException: Object reference not set to an instance of an object
  at SystemHeat.SystemHeatEditor.FixedUpdate () [0x0001a] in <faa8f438e27f4148b7041ce82be5b9c9>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

System heat spits this out in the log file after I try to place down a  LV-T91 Cheetah engine

Is there any other actual effects?

[AtomicRocketBooster]

Ok so I have functional patches for USI+System Heat - they're pre-Alpha but would love some feedback.

They cover:

• MKS_Processor125 (1.25m MPU)
• MKS_Processor250 (2.5m MPU)
• MKS_Processor375 (3.75m MPU)
• MKS_Drill_01 (Small drill)
• MKS_Drill_01A (Small automated drill)
• MKS_Drill_02 (Medium drill)
• MKS_Drill_02A (Medium automated drill)
• MKS_Drill_03 (Large drill)
• MKS_Drill_03A (Large automated drill) 
• Duna_PDU (Duna-class PDU w/ integrated reactor)
• Tundra_PDU (Tundra-class PDU w/ integrated reactor)

I explicitly did not cover the USI reactors - they're all base resource converters and don't do any special USI stuff. There's no reason to use them over the existing System Heat fission reactors from NFE unless you just like the models better - in which case, you can write your own patch. You should be able to just patch in a SystemHeatFissionReactor module - no need for the special connector.

However

The heat outputs for these are totally wonky. The PDUs and drills need what feels like a ton of radiators, while the MPUs need barely any. 

How  should I balance those heat outputs? Some ideas:

• Come up with some "heat output/ton" balance
• Calibrate it such that they need the same radiator mass as before (would need a lot more testing)
• Something else?

@Nertea How do you balance the other converter/reactor/harvester modules? 

Edited December 6, 2021 by AtomicRocketBooster

[Electrosynthesis]

Hi Nertea, thanks for making this great mod, I'm really enjoying it.

I'd like to report an incompatibility with Near Future Electrical. When both are installed, I no longer get the UI option to transfer nuclear fuel between containers.

Tested on a fresh install of KSP 1.12.2 with only NFE and System Heat installed (plus any required dependencies according to CKAN). I saw in a previous patch note this problem might depend on localization - I'm using English. Hope that helps!

 

[panarchist]

6 hours ago, Electrosynthesis said:

Hi Nertea, thanks for making this great mod, I'm really enjoying it.

I'd like to report an incompatibility with Near Future Electrical. When both are installed, I no longer get the UI option to transfer nuclear fuel between containers.

Tested on a fresh install of KSP 1.12.2 with only NFE and System Heat installed (plus any required dependencies according to CKAN). I saw in a previous patch note this problem might depend on localization - I'm using English. Hope that helps!

 

Do you have an experienced engineer on board? If not, then this behavior is by design: 

 

[Electrosynthesis]

Yep. I have a level 5 Engineer in sandbox mode.

These were my testing steps if anyone wopuld like to try reproducing it:

1. Back up, then delete KSP game directory. Redownload fresh from Steam. English localization.
2. Install NFE and any required dependencies via CKAN (I made sure not to add any optional/recommended mods, only the strict requirements)
3. Start KSP, begin a new sandbox game, and design a craft. Craft has 2 nuclear fuel drums, one empty and one full,  and a pod with a 5* engineer
4. Launch the craft and confirm the transfer is working
5. Close game and install system heat via CKAN. Include the 4 system heat config packages (engines, reactors, converters and harvesters). As with NFE, required dependencies only, no optionals.
6. Start KSP, reload the sandbox game, launch the exact same craft with the same kerbal. Observe that the fuel transfer option no longer appears in the UI.

 

I was quite careful with the whole process because I was trying to discover which mod in my mod list was causing the problem. Took a while - System Heat wasn't high on my list . By the way, I am running on Ubuntu 20.

 

[Nertea]

8 hours ago, Electrosynthesis said:

Start KSP, reload the sandbox game, launch the exact same craft with the same kerbal. Observe that the fuel transfer option no longer appears in the UI.

That is as intended. Just try transferring the fuel in the usual KSP way.

[Electrosynthesis]

3 hours ago, Nertea said:

That is as intended. Just try transferring the fuel in the usual KSP way.

There's no UI option for that either

[modus]

Have you alt-right clicked?