[0.15.x] Solving the Heat Pipe Problems

[malventano]

Greetings all (especially devs dealing with the heat pipe implementation/issues),

The heat pipes have caused a lot of heartache for folks who have paid attention to how they actually behave. The current implementation has been acknowledged by devs as 'not clear', and 'from a gameplay perspective, not working well'. I'd like to propose a solution that I believe will be easy to implement and also solve all of the issues that appear to exist with the current implementation.

Issues:
- Heat pipe placement order impacts heat transfer efficiency.
- Heat pipes / other heat related items report their temperatures incorrectly. There is an apparent northeast bias, where the northeastern item (regardless of placement order) may end up reporting as the hottest item in the system (even hotter than the reactor itself) and actually *leads* temperature as the system is warming up. In those cases, the reactor won't start heating above 15C because the heat is somehow magically starting from that other 'hot spot', and the reactor will never reach 1000C itself, even with no heat exchangers thermally loading the system.

Proposed solution:
Have the heat be calculated (programmatically) as if it were 'heat fluid' levels, and treat heat conducting items (heat pipes) as if they were standard pipes. I've calculated a rough set of variables based on the estimated heat capacity and usage of the current implementation:

Reactors:
- Capacity: 1000 units (starts at 15 units when placed).
- Treated as a standard tank.
- Single reactor (40MW) 'self-fills' at a rate of 4 units per second while operating. Neighbor bonuses increase fill rate as expected.
- 1 MW of power = 0.1 heat units per second.
- 'Heat fluid' level is translated by the engine (1:1) and reported as temperature units (C).

Heat pipes:
- Capacity: 100 units (starts at 1.5 units when placed). *
- Treated as standard pipe connections (including fluid flow).
- 10x multiplier is applied to calculate the displayed temperature (100 units = 1000C).

Heat Exchangers:
- Capacity: 100 units (starts at 1.5 units when placed). *
- Does not operate unless level >= 50 units (500C).
- Consumes 0.58 units per second while operating (5.8MW).
- 10x multiplier internally applied for displayed temperature (100 units = 1000C).

* Note: I came to the conclusion that heat pipes and heat exchangers have a heat capacity approximately 1/10th of a reactor by my own timed tests. These figures may be a bit off due to the heat pipe bugs mentioned at the top of this post, but they should be reasonably close.

Heat pipes 'flow' just as their standard pipes would. Yes, this means heat can go in both directions (this is how heat pipes actually behave IRL), but it also means that we will see a 'temperature drop' across longer distances, just as we see with pipes currently. If the devs desire a lower heat transfer rate per heat pipe, simply scale down the unit capacities of all items proportionally while inversely scaling the display multipliers to compensate, or alternately space out the ticks where these particular levels are equalized across items. This will naturally lead to 'slower' heat flow/transfer without needing to reinvent the wheel.

This solution should allow the system to work virtually identically to how it does currently, except that the heat pipes will display the expected temperatures. As an added bonus, the devs can get the 'heat pipe transfer rate' that I believe they desired originally, which should enable an effective distance limit. The ultimate bonus here is that with the heat items treated by the game engine as fluid carrying items, placement order/robot placement/etc. is irrelevant as the 'fluids' will all balance out just as they do now in the current game engine.

Ok, so that's it. From where I sit this looks like a win-win-win. Devs get a solution that should be less of a headache to implement, temperatures behave as expected, and the general confusion experienced by those playing with heat pipes is eliminated.

Thoughts?

[malventano]

Upon further research, it appears the devs desired a hard distance limit of 30 heat pipes from the reactor to the exchangers, as I've occasionally seen heat pipes laid in a particular way drop a constant 16.67C across each pipe (16.67*30=500C). I recommend abandoning this mechanic as it is producing very buggy results as implemented, and is likely a coding headache to get right given the placement order issues and the fact that reactors are cyclic (meaning heat flows both ways during heating/cooling). The 'heat flow' method I proposed above can easily accommodate a form of that distance limit, and it will also make more sense to the player, as the distances for a single heat pipe run will need to be shorter as the heat demand increases, naturally forcing the player to use shorter / additional parallel pipe runs in higher power builds - just as you would expect. It won't be the same as a static 30 pipe limit from the heat source, but it will be effectively the same under load and will be immune to placement order, saving a lot of other headaches and potential confusion.

[ssilk]

I'm yet not so firm with the heat pipes. ... cause of suggestions ...

I don't understand, why that should be better.

BTW: The current state of discussion is, that it will be changed, see
viewtopic.php?f=30&t=44972&start=40#p271400

The pipes have their own problems and when Rseding implements his idea with his pipe changes (see link and then the following post), then a lot of what makes pipes realistic would be killed.

[malventano]

I'm yet not so firm with the heat pipes. ... cause of suggestions ...

I don't understand, why that should be better.

BTW: The current state of discussion is, that it will be changed, see
viewtopic.php?f=30&t=44972&start=40#p271400

The pipes have their own problems and when Rseding implements his idea with his pipe changes (see link and then the following post), then a lot of what makes pipes realistic would be killed.

I actually like the ideas behind how it is currently, but the main issue is that the current implementation is inconsistent/broken. I believe implementing the way I suggested above would keep the intent of the current implementation while also making things behave properly (and realistic).