[1.12.x] SystemHeat - a replacement for the CoreHeat system (September 1)

[Nertea]

10 hours ago, Great Disnub said:

Howdy, been enjoying a lot of your mods recently, they're honestly amazing. Unfortunately, it seems that there's an issue with System heat in my KSP instance, as Nerv rockets aren't being put in a heat loop. The mod appears to work for the Cherenkov, though I haven't exactly done exhaustive tests  as. I wouldn't be surprised if it was a mod conflict, given the quantity I have, but there doesn't seems to be any obvious conflicts. So far Ive tried reinstalling the mod and associated configurations, but no dice.

Any help or possible solutions would be much appreciated, let me know if you want the modlist or something. Thank you in advance!

 

They're not supposed to be part of a loop as they don't generate excess heat (solid core NTRs don't get hot enough to need it generally). If this occurs with any of the other solid-core, no cogeneration engines that has to be fixed. 

[Great Disnub]

Ah, gotcha, that makes sense. Thank you for the quick response!

[dave1904]

Any Idea what would cause this to spam my log? 

[LOG 13:28:16.169] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.190] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True
[LOG 13:28:16.190] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.211] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True
[LOG 13:28:16.211] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.232] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True

An important thing to add is that im playing with kerbalismsystem heat too so it might be conflicting with the new version. I cannot really recreate it either because its different for different craft. 

 

 

Edited September 1 by dave1904

[Nertea]

5 hours ago, dave1904 said:

Any Idea what would cause this to spam my log? 

[LOG 13:28:16.169] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.190] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True
[LOG 13:28:16.190] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.211] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True
[LOG 13:28:16.211] [SystemHeat][ModuleSystemHeat] seting module tank system state from True to False
[LOG 13:28:16.232] [SystemHeat][ModuleSystemHeat] seting module tank system state from False to True

An important thing to add is that im playing with kerbalismsystem heat too so it might be conflicting with the new version. I cannot really recreate it either because its different for different craft. 

 

 

I don't know what terrifying things the Kerbalism patch does so I can't really say (I would guess you're using the CryoTanksSystemHeat thing and something is causing the tank to toggle between needing cooling and not repeatedly), but the source tells me right now that DebugModules is on by default. I'll fix this in the next version, but in the meantime you can go to the Settings.cfg file in the SystemHeat directory and add a line saying DebugModules = false to remove the logging call. 

 

[dave1904]

17 minutes ago, Nertea said:

I don't know what terrifying things the Kerbalism patch does so I can't really say (I would guess you're using the CryoTanksSystemHeat thing and something is causing the tank to toggle between needing cooling and not repeatedly), but the source tells me right now that DebugModules is on by default. I'll fix this in the next version, but in the meantime you can go to the Settings.cfg file in the SystemHeat directory and add a line saying DebugModules = false to remove the logging call. 

 

Ok thanks. Ive a second issue too. Maybe related. It also happens on certain craft and I dont know how to recreate it. 

 

[EXC 18:23:34.934] NullReferenceException
    SystemHeat.UI.ToolbarIconTag.SetWarningNone () (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    SystemHeat.UI.ToolbarIconTag.Update (SystemHeat.SystemHeatSimulator simulator) (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    SystemHeat.UI.SystemHeatUI.Update () (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

[Nertea]

9 minutes ago, dave1904 said:

Ok thanks. Ive a second issue too. Maybe related. It also happens on certain craft and I dont know how to recreate it. 

 

[EXC 18:23:34.934] NullReferenceException
    SystemHeat.UI.ToolbarIconTag.SetWarningNone () (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    SystemHeat.UI.ToolbarIconTag.Update (SystemHeat.SystemHeatSimulator simulator) (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    SystemHeat.UI.SystemHeatUI.Update () (at <2efe72f4cf3649c9bbc755ab96be8088>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Looks different. Are you certain you're using SystemHeat >= 0.7.1? There was an issue fixed in that version that created a very similar log message in that version. 

[dave1904]

12 minutes ago, Nertea said:

Looks different. Are you certain you're using SystemHeat >= 0.7.1? There was an issue fixed in that version that created a very similar log message in that version. 

    "VERSION":
    {
        "MAJOR":0,
        "MINOR":7,
        "PATCH":3,
        "BUILD":0
    },

I have 0.7.3? 

GitHub - judicator/KerbalismSystemHeat: Kerbalism support for SystemHeat mod

This is the patch im using so it could be the cause of the issues. Maybe it is causing the issues. 

[Nertea]

8 minutes ago, dave1904 said:

    "VERSION":
    {
        "MAJOR":0,
        "MINOR":7,
        "PATCH":3,
        "BUILD":0
    },

I have 0.7.3? 

GitHub - judicator/KerbalismSystemHeat: Kerbalism support for SystemHeat mod

This is the patch im using so it could be the cause of the issues. Maybe it is causing the issues. 

Yeah I'd need a log of the event and reproduction steps. 

[dave1904]

2 minutes ago, Nertea said:

Yeah I'd need a log of the event and reproduction steps. 

Ok. Will see if I can get more data. 

[Nertea]

Release 0.7.4

• Fixed a config oversight that made the heat exchanger always cost power no matter its settings
• Fixed a relatively harmless NRE on editor scene loads
• Fixed UI null reference spam when switching away from a vessel with SH modules in flight
• Fixed UI null reference spam when switching to a vessel with SH modules in flight after switching to one with none   
• Added a few null checks/guards in places that might have bad things happen
• Ensure all debug flags are set to OFF by default and added examples of the hidden ones to the settings file
• Added an adapter module for ModuleCometDrill
• Adjustments to EXTRAS patches to fix a few issues
  • Unnecesary SH modules for some NTRs
  • Harvester patches now support Asteroid/Comet drills

[Kurbalizer]

Sorry to bother, but I've been chewing on a problem on my installation for a while. It boils down to a problem that appears together with "System Heat" and MoarScience (Station Science). Seperately they run fine, but together they won't. Especialy on the Station Science part. If installed together, the experiments of Station Science cannot be completed. Even when cooling is tightly watched (none of the parts overheat! so can't be the problem here), at the start of the experiment the game immediatly throws an error and says that the experiment detached from the vessel and cannot be finalized. Well, if interested in the issue, the logs and a screenshot of my GameData is found under:

https://www.dropbox.com/scl/fo/8aohyeitdtt7d35v4lu78/AKyutzSezlDhPS0SN7aKdJ8?rlkey=mri26dl7jzmk05f5vnhxjvdy3&st=8g5olh7u&dl=0

(P.S.: I posted a similar text on the other thread, because I don't know on which side it could be solved. Thanks in advance.)

[dave1904]

11 hours ago, Nertea said:

• Fixed UI null reference spam when switching away from a vessel with SH modules in flight
• Fixed UI null reference spam when switching to a vessel with SH modules in flight after switching to one with none

This is the spam I posted to you yesterday. I should have mentioned to you that I was dropping an X-15 from a B-52.

And its fixed. Thanks

Edited September 2 by dave1904

[Streetwind]

Hey @Nertea, is there a SystemHeat module that can output "dummy heat" based on another module's status?

I was looking at MKS resource drills. They use their own bespoke resource harvester module, which the SystemHeatHarvesters patch cannot replace. I'm assuming that supporting this custom module in Systemheat directly would be a bunch of work.

So I was instead thinking, is there perhaps some way to trick one of the existing SystemHeat modules into outputting heat if that USI module is running? (The USI module can already be set to not generate heat itself, so there would be no issue with stock CoreHeat accumulating.)

If not, I suppose I'll just turn off heat generation on the drills and have them run that way, since there are no CoreHeat radiators to service them...

[Nertea]

3 hours ago, Streetwind said:

Hey @Nertea, is there a SystemHeat module that can output "dummy heat" based on another module's status?

I was looking at MKS resource drills. They use their own bespoke resource harvester module, which the SystemHeatHarvesters patch cannot replace. I'm assuming that supporting this custom module in Systemheat directly would be a bunch of work.

So I was instead thinking, is there perhaps some way to trick one of the existing SystemHeat modules into outputting heat if that USI module is running? (The USI module can already be set to not generate heat itself, so there would be no issue with stock CoreHeat accumulating.)

If not, I suppose I'll just turn off heat generation on the drills and have them run that way, since there are no CoreHeat radiators to service them...

I wrote an adapter module ages ago: https://github.com/post-kerbin-mining-corporation/SystemHeat/blob/master/SystemHeat/SystemHeat/Modules/ModuleSystemHeatBaseConverterAdapter.cs

This should naiively do it but I don't think anyone has tried it ever. 

[Streetwind]

*squints at code*

...so if I understood this correctly, I would add a ModuleSystemHeat to the part, and a ModuleSystemHeatBaseConverterAdapter. I would give the adapter the name of the ModuleSystemHeat, and the... index of the USI resource harvester module? (How do I find this index? Is it just counting modules from top to bottom in the part definition, starting at 0?)

Then I tell the adapter how much heat it should be generating in the harvester's stead, and other relevant values, while turning the harvester's core heat output off and (possibly) getting rid of the ModuleCoreHeat?

I can certainly try and see if this works.

[modus]

Well, you have my moral support!

[Streetwind]

Well, this was easier than I feared it might be. Guessed the index correctly on the first try

Of course, this is just a quick simulation in the VAB, I haven't tested this in the field. But it behaves the same in the simulation as the stock drill, so there's that, at least...

...Now to actually choose some sane values for the anything-but-sane default values of MKS.

[Streetwind]

Well, this is what I came up with in the end:

https://pastebin.com/0NLY0CgP

Outlet temperature had to be 500K, as that is the efficiency sweetspot of the USI harvester module. It also makes these drills slightly easier to cool than the stock ones, which I think is a good thing. Because the Atlas harvesters are gigantic and consume mountains of power. I originally aligned with the heat output of the stock drills, which ended up with the largest Atlas harvesters at 4MW of cooling required; but in testing this with actual radiators, it became ridiculous. You needed seven 'Delta' high-temperature radiators from Heat Control, or sixteen of the stock Thermal Control System (Large), to cool a single large Atlas harvester. And you're meant to deploy more than one. The endgame Atlas domes have five harvester slots each.

So I scaled everything down a little, to peak at no more than 2.5 MW. That's still a hefty enough challenge at this low a temperature.

As an aside - Nertea, would it be possible for SystemHeat to not round MW values to the nearest whole number in its various displays, and the part module info in the VAB parts list? A single decimal digit would go highly appreciated, at least for otherwise single-digit MW numbers

 

Now, for anyone who actually wants to use this patch: I'm afraid it's not necessarily going to be a "drop in and forget" deal. Because if you have any other mods installed that affect the USI harvesters in any way - or heck, if I had other mods installed that affect them while making this patch and you don't - then there's a chance the patch will not work. Because the module index of the USI harvester module might change. It's a fairly small chance, admittedly, because new modules will usually be appended at the bottom, and thus not modify the existing order of modules further up. But have have to be aware of this - and when it happens to you, you'll need to go and fix it yourself. Because the indices you need to set will be specific to your own set of mods, so no one else can fix it for you.

The easiest way to do so will be to load up the game, hit Alt+F11 to bring up the ModuleManager menu, and dump the DB to disk. That will create a new folder in your KSP directory, which will contain every single part.cfg file in its final state, after all MM patches have been applied. Find the files for the various USI harvesters, open them, and count every instance of MODULE you see in each one. Do not count any other subnodes, only those named MODULE. Count top to bottom, starting at zero. The number you reach when you find the USI_Harvester module will be the number you need to input into the patch.

Be aware that not all the harvesters may use the same index, due to differences in their file structure. In my case, I found some to use index 4 and some to use index 5.

 

Edited yesterday at 09:17 AM by Streetwind

[modus]

1 hour ago, Streetwind said:

Well, this is what I came up with in the end:

https://pastebin.com/0NLY0CgP

Outlet temperature had to be 500K, as that is the efficiency sweetspot of the USI harvester module. It also makes these drills slightly easier to cool than the stock ones, which I think is a good thing. Because the Atlas harvesters are gigantic and consume mountains of power. I originally aligned with the heat output of the stock drills, which ended up with the largest Atlas harvesters at 4MW of cooling required; but in testing this with actual radiators, it became ridiculous. You needed seven 'Delta' high-temperature radiators from Heat Control, or sixteen of the stock Thermal Control System (Large), to cool a single large Atlas harvester. And you're meant to deploy more than one. The endgame Atlas domes have five harvester slots each.

So I scaled everything down a little, to peak at no more than 2.5 MW. That's still a hefty enough challenge at this low a temperature.

As an aside - Nertea, would it be possible for SystemHeat to not round MW values to the nearest whole number in its various displays, and the part module info in the VAB parts list? A single decimal digit would go highly appreciated, at least for otherwise single-digit MW numbers

 

Now, for anyone who actually wants to use this patch: I'm afraid it's not necessarily going to be a "drop in and forget" deal. Because if you have any other mods installed that affect the USI harvesters in any way - or heck, if I had other mods installed that affect them while making this patch and you don't - then there's a chance the patch will not work. Because the module index of the USI harvester module might change. It's a fairly small chance, admittedly, because new modules will usually be appended at the bottom, and thus not modify the existing order of modules further up. But have have to be aware of this - and when it happens to you, you'll need to go and fix it yourself. Because the indices you need to set will be specific to your own set of mods, so no one else can fix it for you.

The easiest way to do so will be to load up the game, hit Alt+F11 to bring up the ModuleManager menu, and dump the DB to disk. That will create a new folder in your KSP directory, which will contain every single part.cfg file in its final state, after all MM patches have been applied. Find the files for the various USI harvesters, open them, and count every instance of MODULE you see in each one. Do not count any other subnodes, only those named MODULE. Count top to bottom, starting at zero. The number you reach when you find the USI_Harvester module will be the number you need to input into the patch.

Be aware that not all the harvesters may use the same index, due to differences in their file structure. In my case, I found some to use index 4 and some to use index 5.

 

I will try it out and see if I'll need to adjust anything.

Do you have any example of a mod that affects the harvesters? I can't really think of anything. 

Anyway, thanks alot for this!

Edit: Actually, now that I'm at my PC, I see that I already have MKS-SH patches. I totally forgot about that (just got back into ksp1).
They were made by @Grimmas (don't know if they're still active here), I'll see if I can find the source.

edit²: found them: GrimmModlets/Content/GameData/GrimmAerospace/GrimmModlets/USISystemHeatPatch at main · Grimm-Aerospace/GrimmModlets · GitHub

Edited yesterday at 10:39 AM by modus
remembered I already had something

[Streetwind]

Neat! They did it the same way as I did, which gives me confidence that I did something right

A difference being, their patches straight up copy the heat output of the MKS core heat configs, ending up with 200 kW heat load on the large Atlas harvesters, whereas my patch attempts to scale heat output according to EC input and ends up making them generate more than twelve times that much. (The small drills are very similar though.)

 

Edited yesterday at 10:57 AM by Streetwind

[JadeOfMaar]

9 hours ago, Streetwind said:

4MW of cooling required; but in testing this with actual radiators, it became ridiculous. You needed seven 'Delta' high-temperature radiators from Heat Control, or sixteen of the stock Thermal Control System (Large), to cool a single large Atlas harvester. And you're meant to deploy more than one. The endgame Atlas domes have five harvester slots each.

I've been quite aware of a distinct lack of very large capacity, low-temp radiators. Under System Heat it quickly becomes impractical to make any sort of radiator panel that's big enough to cool anything more than cryo tanks, much less to provide for the ISRU infrastructure at any grand settlement like an Atlas dome cluster. For this exact situation I created the Gulf Stream series of open cycle radiators within Sterling Systems. There is more capacity in them than most players will ever need, however, they will chug on an atmosphere (IntakeAtm resource) or Water.

[Brigadier]

1 hour ago, JadeOfMaar said:

There is more capacity in them than most players will ever need, however, they will chug on an atmosphere (IntakeAtm resource) or Water.

I get the first part of the sentence but the second half eludes me.  What do you mean?

[Streetwind]

@JadeOfMaar I'll have a look.

And just like that, the quest to finish customizing a playable modded instance to my liking gets extended once more...   Currently on day 8 and counting.

28 minutes ago, Brigadier said:

I get the first part of the sentence but the second half eludes me.  What do you mean?

It means these radiators need to either be in an atmosphere to function, or will consume water instead when in a vacuum.

In other words, they're not radiators at all, but rather convection devices that use pumps/fans to move ambient air (or supplied water vapour) through a heat exchanger. They can't work without a convection medium.

 

Edited 21 hours ago by Streetwind

[JadeOfMaar]

1 hour ago, Streetwind said:

they're not radiators at all, but rather convection devices

Hold my beer ginger ale. I should actually remove "radiator" from the part description.

1 hour ago, Streetwind said:

extended once more...  

Oops