Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heat transfer has an apparent directional bias #37

Closed
mel-odious opened this issue Oct 8, 2021 · 2 comments
Closed

Heat transfer has an apparent directional bias #37

mel-odious opened this issue Oct 8, 2021 · 2 comments
Labels
bug Something isn't working

Comments

@mel-odious
Copy link

When smelting multiple iron mix nodes, the nodes in the -X and -Z directions (west and south) heat faster and reach higher temperatures than the others. Not if this effect also occurs during cooking or firing pottery but those processes don't last as long so it may just be less obvious.

For a small underpowered smelter (three iron mix nodes and one charcoal block) the effect is most obvious: The node with the lowest X or Z coordinate heats the most, reaching 1800 C and smelting, while the middle node gets to around 1300 C and the opposite node stays at 1100 C. Once the hot node is finished smelting the other two heat up more, though the middle node is still hotter. Here's a screenshot where I extinguished the fires after the first node smelted and removed the top layer, north is up:
exile heat transfer bug

I've reproduced this on 0.3.3 and whatever branch is running on the Land of Catastrophe server currently (I'm m0dus there). I noticed from mods/climate/temperature.lua:482 in climate.air_temp_source(), the function iterates over the nearby heatable or air nodes - from some logging the ordering of the list is consistent with lower-coordinate nodes first so it hits the southwest nodes first. Then at line 510 a passed-in function parameter is modified each time the loop hits a heatable node: "temp_effect" is effectively scaled down with each pass through, starving the later nodes of heat.

A quick hack to lines 510 and 513 to declare and use a new local variable indeed leads to far more even heating, though I'm not familiar enough to know if that gives a reasonable heating rate. I don't have the repo cloned right now so you'll have to forgive the lack of PR, though I'm enjoying the game a lot so I might figure it out c:

@jeremyshannon
Copy link
Owner

Yeah at first glance, it looks like instead of using pairs and going methodically over each node in heatable with a decreasing chance, we should select a random entry up to #heatable and dump heat/cold there, then select another one until we've used up temp_effect. It might even be faster, too, if it dumps all its heat/cold in the first couple of blocks and then doesn't have to load metadata from the remaining blocks. That's probably not important, though, profiling showed that climate was not a big cpu sink. (that's the mobs.)

@jeremyshannon jeremyshannon added the bug Something isn't working label Oct 9, 2021
@jeremyshannon
Copy link
Owner

No, on second glance, that would make "chance" kind of useless, and while it makes a kind of sense, I don't think using up temp_effect was intended. A local variable, it is! This will probably buff heating again, at least a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants