[0.15.x] Solving the Heat Pipe Problems
Posted: Tue May 09, 2017 11:33 pm
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?
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?
