[0.15.1] [kovarex] Non-Conducting heat pipes after 60 tile

[malventano]

A bad or unclear design or implementation isn't a bug. It's just working as designed, albeit not working in a way that the end user/player understands. Strictly speaking, if heatpipes are designed to work directionally, this wasn't a bug, but it does leave a lot of room for improvement in terms of communicating that to the players. Still, keep in mind that 0.15 is the -expirimental- branch, so some vagueness/black magic is to be expected. Glad to see it get fixed. Hope that the hybrid plant issue gets fixed too

I think the problem was that is was classified as a "feature" (the description of "not a bug", look at the posts in there and it's mainly people complaining about how the game is meant to work). This may not be a bug, but this definitely was not a feature: it wasn't fun, it wasn't a challenge. It was needlessly frustrating in every way.

And your experimental branch point is why I think everyone here would have been fine if it was placed under "Known Issues" or even "Minor Issues". Or heck, if it had been placed in "Won't Fix" I think many people would be less annoyed. But it was called a feature which is frustrating because it should be fixed, and an added slap in the face with "it's supposed to be fun/challenging" (theoretically the purpose of a feature in a game of this nature).

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

[mOoEyThEcOw]

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Missed that, hence why I said "may" not be a bug.

It is placed under "Resolved For next release" so, it is fixed.
besides, it does make sense to call it a feature and not a bug: https://en.wikipedia.org/wiki/Undocumented_feature

I know it's fixed, but in case you were being serious with your second sentence (highlighting mine):

In other cases, software bugs are referred to jokingly as undocumented features. ("It's not a bug; it's an undocumented feature!") This usage may have been popularised in some of Microsoft's responses to bug reports for its first Word for Windows product, but doesn't originate there. The oldest surviving reference on Usenet dates to 5 March 1984. Between 1969 and 1972, Sandy Mathes, a systems programmer for PDP-8 software at Digital Equipment Corporation (DEC) in Maynard, MA, used the terms "bug" and "feature" in her reporting of test results to distinguish between undocumented actions of delivered software products that were unacceptable and tolerable, respectively. This usage may have been perpetuated.

This would be in the unacceptable category (and besides I doubt the developers meant it as a tongue-in-cheek joke).

[bartekltg]

There is something wrong with the design of the system, we are aware of this, the mechanic of the heat transfer isn't clear, from a gameplay perspective it isn't working well

Can I guess? Is the problem that you tried to do a physical simulation of heat transfer, so temperature in the next tick at point x is
T_{n+1}[x] = T_n[x] + k * sum_i ( T_n[ y_i ]-Tn[x] )
sum goes through all neighbors y_i, k is heat transfer coefficient times dt (times 1/mass 1/ heat capacity...) = just a constant * dt.

And the solution oscillate.


Edit: As a bonus, I see that temperature is updated not every tick, but less often. It isn't bad solution, there is no need for computing is so often (this is no electricity ) but in only make the osculation problem worse.

[kovarex]

A bad or unclear design or implementation isn't a bug. It's just working as designed, albeit not working in a way that the end user/player understands. Strictly speaking, if heatpipes are designed to work directionally, this wasn't a bug, but it does leave a lot of room for improvement in terms of communicating that to the players. Still, keep in mind that 0.15 is the -expirimental- branch, so some vagueness/black magic is to be expected. Glad to see it get fixed. Hope that the hybrid plant issue gets fixed too

I think the problem was that is was classified as a "feature" (the description of "not a bug", look at the posts in there and it's mainly people complaining about how the game is meant to work). This may not be a bug, but this definitely was not a feature: it wasn't fun, it wasn't a challenge. It was needlessly frustrating in every way.

And your experimental branch point is why I think everyone here would have been fine if it was placed under "Known Issues" or even "Minor Issues". Or heck, if it had been placed in "Won't Fix" I think many people would be less annoyed. But it was called a feature which is frustrating because it should be fixed, and an added slap in the face with "it's supposed to be fun/challenging" (theoretically the purpose of a feature in a game of this nature).

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

[malventano]

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

Cool deal. Were you able to keep the static (16.67C) delta across each heat pipe or did that have to go?

[Aeternus]

A bad or unclear design or implementation isn't a bug. It's just working as designed, albeit not working in a way that the end user/player understands. Strictly speaking, if heatpipes are designed to work directionally, this wasn't a bug, but it does leave a lot of room for improvement in terms of communicating that to the players. Still, keep in mind that 0.15 is the -expirimental- branch, so some vagueness/black magic is to be expected. Glad to see it get fixed. Hope that the hybrid plant issue gets fixed too

I think the problem was that is was classified as a "feature" (the description of "not a bug", look at the posts in there and it's mainly people complaining about how the game is meant to work). This may not be a bug, but this definitely was not a feature: it wasn't fun, it wasn't a challenge. It was needlessly frustrating in every way.

And your experimental branch point is why I think everyone here would have been fine if it was placed under "Known Issues" or even "Minor Issues". Or heck, if it had been placed in "Won't Fix" I think many people would be less annoyed. But it was called a feature which is frustrating because it should be fixed, and an added slap in the face with "it's supposed to be fun/challenging" (theoretically the purpose of a feature in a game of this nature).

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

Uh oh. That means for wide setups, the heat exchangers at the far ends of the array won't be receiving as much energy as the center, or at least not as quickly. That will make switched reactor setups even more of a challenge now that preheating the steam is gone.
Guess I'll see how my turbine rows fare in 15.11.

[Taipion]

A bad or unclear design or implementation isn't a bug. It's just working as designed, albeit not working in a way that the end user/player understands. Strictly speaking, if heatpipes are designed to work directionally, this wasn't a bug, but it does leave a lot of room for improvement in terms of communicating that to the players. Still, keep in mind that 0.15 is the -expirimental- branch, so some vagueness/black magic is to be expected. Glad to see it get fixed. Hope that the hybrid plant issue gets fixed too

I think the problem was that is was classified as a "feature" (the description of "not a bug", look at the posts in there and it's mainly people complaining about how the game is meant to work). This may not be a bug, but this definitely was not a feature: it wasn't fun, it wasn't a challenge. It was needlessly frustrating in every way.

And your experimental branch point is why I think everyone here would have been fine if it was placed under "Known Issues" or even "Minor Issues". Or heck, if it had been placed in "Won't Fix" I think many people would be less annoyed. But it was called a feature which is frustrating because it should be fixed, and an added slap in the face with "it's supposed to be fun/challenging" (theoretically the purpose of a feature in a game of this nature).

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

Just to make sure, please allow me to ask this probably very stupid question:

As it is intended to limit the maximum heat flow distance,
is it also intended / will it be possible, to mitigate this with masses?

In other words, where one line of heat pipes wont be sufficient to transfer "x" heat after "y" tiles distance,
will it be possible to make up for that by using parallel heat pipes, or will even a 20 tiles wide wall of heat pipes stop to work after a short distance?

[malventano]

The implementation was actually bugged. Temps were hotter where they should have been colder. Temps at the far ends of heat pipes were hotter than the reactor, etc.

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

Just to make sure, please allow me to ask this probably very stupid question:

As it is intended to limit the maximum heat flow distance,
is it also intended / will it be possible, to mitigate this with masses?

In other words, where one line of heat pipes wont be sufficient to transfer "x" heat after "y" tiles distance,
will it be possible to make up for that by using parallel heat pipes, or will even a 20 tiles wide wall of heat pipes stop to work after a short distance?

Well that depends on if they stuck with the satatic minimum temperature drop figure or not. If they did, there will be a fixed number of tiles that heat can transfer (regardless of load) before temp drops too far to generate steam. If it's the other way, a single line of heat pipes will have a max load it can handle before temp drops too far, but that can be remedied by simply doubling up on the pipes (just as it is with regular pipes now).

[bartekltg]

Yes, I noticed that as well and I also fixed that. Now the transferred heat is just a fraction of the difference (1/5 now), not all the difference. This makes it all more stable, but also decreases the maximum distance of full capacity heat flow, which was the goal anyway.

Do the game uses 1) temporary array for 'new temperature', so all heat transfers are computed based on temperatures from previous tick; or 2) it update temperature on the fly so heat flux is computed from some old and some new values of T? If you still want to tinker with heat pipes, I strongly recommend the first methods. Symmetry is very important for construction. And If data is arranged as SOA there is no need for two pass, just swap vectors.

Math:
1/5 make sense. Assuming game use first method, it works as in the previous equation: T_{n+1}[x] = T_n[x] + k * sum_i ( T_n[ y_i ]-Tn[x] ), in other words:
temperatures (now as vector ) in the next tick T_{n+1} = T_n - k M T_n = (I-k M) T_n (I is identity, M is called Laplacian Matrix of our graph, very simple one).

some math names and explanations

Temperatures of objects we can put it in table, one next to another (I'm not talking about implementation. We can there too, but now we work on idea and properties of the system:) So we can call it "a vector". Temperature in the next tick (also a vector) is linear function of some temperatures from previous vector. So the whole operation can be written down as matrix-vector multiplication.

Eingenvalue and eingenvector of matrix A is a pair (λ, v) that, when we multiply v by A, the results looks like v, only is enlarged/shrieked by λ. Av=λv. It is quite important concept in physic and numerical methods. Laplacian nave all his eingenvalues nonegative. The eingenvector connected to the biggest eingenvalue on full 2D grid looks like like chess board. Positive number on black squares and negative on white squares. So it looks bad in heat transfer problem.

Eingenvectors of symetric matrix (our is, if tile x is conected to tile y, then y is conected to x. Easy:) make a "base". You can think of a state(vector, let's call it w) as a linear combination of eingenvectors. w = a1 v1+ a2 v2 + ... vi are eingenvectors, and ai are just some numbers. "base" means every vector can be converted to this form. Why it is usefull? v_i are perpendicular and after multiplication by A it is the same vector, only rescaled. They do not influence each other, we can look at one of them (the worst one!) and check a couple of things much easier. For example, if without sources/sinks iteration give us eventually a flat solution. This mean all eingenvectors must become smaller in each iteration.

It is important to remember, that during simulation the solution will contain each eingenvector at least in a small amount.

We can look at the biggest eigenvalue of M (ant its vector T0). (I-k M)T0 = (1-k λ) T0. That number is less than 1. But if it is less than -1, it will grown 1-k λ times each iteration. Parasite solution will eat everything and only bitters survive. I'n quite sure λ in factorion (or, pore precise, on a plena and with at most 4 connection per vertex) is less than 8. 1-8/5 = -3/5, so we are OK. It it appears, it oscillate a couple of times then vanish reasonably fast. It gets >20 times smaller in 100ms

For the second method I can't write simple analysis (even the matrix is now complex, (I+kL)^-1 (I-kU) where L is everything from M below diagonal, and U is the rest; blah, in a coded loop it looks nicer:) ), but I tried setup "900 pipes in 30x30grid" and k=1/5 in octave. Results aren't the best. The biggest eingenvalue is 0.99317. After a "game second" (60 iterations, for 60 ticks/s) that eingenvector decrease only to 66%. And it not obvious that decreasing k works. 1/6 is worst, 1/4 is better (in the sense of biggest parasite solution, smaller k still should be better for other things). Of course I could make a mistake;-) But now I recommend the first method even stronger (all temperatures for fluxes have to be old temperatures). k as big as k<1/4.1 seems to be acceptable in that case.
Don't understand me wrong, I'm not suggesting creating matrices and attacking it with full power of computational linear algebra! (Yet...) Just to keep in objects "temperature" and "new_temperature".

Physics.
It seems there is need to keep k small. But there is second parameter, hidden by devs, pipes heat capacity. Singe game probably works here on temperature, this parameter is in a constant that gives relation between a degree C and a Joule. k is heat conductivity over heat capacity. Maximum flow is governed by conductivity (let's call it c). Then max flow is proportional to difference of temperatures (max is 1000-500=500) * total conductance. If game simulate equation properly, total conductance of a line (no other elements) is c * line width/line length. Too low c is bad, but we can decrease k by increasing heat capacity. One Joule from reactor increase reactor's T two time less, 1 deg C produce two times more 500deg steam. Energy production is kept the same, conductivity is kept, so the same flow for the same temperature difference. The only disadvantage is that our heat-pipe contain two times more energy.

And they even now they contain enormous amount of it

1GJ per tile! And can be used as 500MJ per tile storage:) Assuming everything is already at 500degC, You need 16 tiles to keep energy from a fuel cell. A reactor is already 10, so 152 tiles is needed to keep one input to 2x2 reactor setup. OP, nerf now.

What can be done in future.
Computing flux and then updating temperature is just a forward Euler scheme for differential equations applied to Fourier law (heat transfer equation). Forward (or explict) Euler method have quite small stability region. Bad news is that all explict method are bad for that type of problems ("stiff"). One can find method that have a bit wider stability region (high order RK) but change is ~ 20-30% if I remember correctly, and complexity increase significantly. That is a wrong way. Better news: we have implicit methods. Backward Euler will be stable for all k! Another one, Crank–Nicolson, was designed for simulations of thermal flow. Howewer, "implict" mean (in this case) that we have matrix on both sides of equation, before T_n and T_{n+1}! I tested*) that reasonably big system (3000 poles each connected with 4 others) still can be solved in ~1ms (athlon ii x4 955, with factorio and other stuff working on 50% cpu power), a couple of percent of tick time. Connected heat-pipe systems probably would be much smaller. But to work that fast it needs a couple of trick, nothing fancy, but still it may not be an hour of work:)

*)

tested for

for a electric network with resistance and loses I'm trying to prepare and make a post;) Heat transfer equation and electric grid equation are very different (one is parabolic, second elliptic), but from computational point of view the most expensive part is similar - solve equation with matrix looking like matrix of connections)

Oh, there is one trick that can increase flow without increasing capacity or decrease thermal capacity without slowing the flow. leave k as is, make two iterations per tick. I'm not joking. But it means game need to go two times through heat entities.

TL;DR.
- calculating fluxes from previous step guarantee symmetry and better numerical properties. It may be worth to increase complexity a bit.
- to increase flow without messing with k thermal capacity of heat-pipes can be increased. But this influence gameplay, since now heatpipes are the most dense energy containers:)
- There exist an ultimate solution for that problem. But it require a lot work (at least comparing to the first point of tldr). On the other hand, the same framework can be used for power grid, maybe fluids. Great to consider for factorio 2.0 or 3.0

[mOoEyThEcOw]

Or they could treat it like a network (a concept that they already have), convert it to a flow graph, and not simulate the heat pipes at all (unless they need an instantaneous number to give to the player). Then they could screw around with the numbers all the want without worrying about how the simulation ticks work.

Since it's a friday I am tempted to write like 100 lines of python (using existing factorio and graph libraries) just to prove my point (such code would be pretty trivial to convert to C++ FWIW). On the other hand I rather just play a bunch of factorio tonight.

[bartekltg]

Or they could treat it like a network (a concept that they already have), convert it to a flow graph, and not simulate the heat pipes at all (unless they need an instantaneous number to give to the player). Then they could screw around with the numbers all the want without worrying about how the simulation ticks work.

I'm not sure I understand correctly. Like in maximum flow problem?
In factorio we have multiple source and multiple sinks of fluid. In original formulation maximum flow gives only constant constraints "that pipe could conduct at most k units". With multiple sources and/or sinks, the solution isn't unique: lets say we produce 100 units in two reactors, consume 100 in two in heat exchangers, and the bottleneck is 50. So we can produce 50 in first, 0 in the second reactor; or 0 and 50, or 25 and 25. The same goes for sinks.
How to fix it?
The worst problem may be cmoplexity. The best one is around O(number of pipes^2).

The fat algebraic method with need O(n^2) only when entity is inserted or destroyed (7ms for 3000pipes) and for normal run is linear.
Simple version is just linear.

But what is the most important, is that it will feel different. With simulation from simple rules we get energy storage, system heats and cools, we have to look after heat flow, if it is enough for a give temperature gradient. It gives natural distribution of load between heat exchangers. And this is great feature of the game, that it gives us a toy version of real systems.

Since it's a friday I am tempted to write like 100 lines of python (using existing factorio and graph libraries) just to prove my point (such code would be pretty trivial to convert to C++ FWIW). On the other hand I rather just play a bunch of factorio tonight.

On the other hand, the solution I'm trying to sell for now is just add second double variable: T_old, and change
Edit: [This is what I assume is going in the code now]

Code: Select all

for (auto &v:heat_entities){ 
     double flow = 0.0;
     for (auto &w: v.neighbors )
         flow+= k ( w.T - v.T );
     v.T += flow;
 }

to

Code: Select all

 for (auto &v:heat_entities) 
     v.T_old = v.T;
 for (auto &v:heat_entities){ 
     double flow = 0.0;
     for (auto &w: v.neighbors )
           flow+= k ( w.T_old - v.T_old );
     v.T = v.T_old + flow;
 }

The fat version is quite short too

pseudpseudo

on tick:
Put all temperatures in a vecter T in an order given by permutation p.
T2 = L'\ T; //backsubstitutions with matrix L (and transposed version). One call to the linear algebra library.
T = L\ T2;
send T back to objects (if nessesary, game may just keep temperature in that way)

on event of deleting or adding an entity:
update matrix used in inverse iteration A (depend on connections and number k)
p = amd(A)//aproximate minumal degree, or different reordering algorithm, that reduce "fill in" in the 'chol' step
A = A(p,p); //reorder matrix.
L = chol (A); //cholesky decompositon.

A and L are sparse (they are nxn, but contain only O(n) elements, the rest is 0 and not kept).
Now you know why 'it is for factorio 2.0'
All of this operations are implemented in many libraries, quite few of them with commercial friendly licence.

The main problem would be integration with factorio code, and it may not a small task:)

[mOoEyThEcOw]

Or they could treat it like a network (a concept that they already have), convert it to a flow graph, and not simulate the heat pipes at all (unless they need an instantaneous number to give to the player). Then they could screw around with the numbers all the want without worrying about how the simulation ticks work.
I'm not sure I understand correctly. Like in maximum flow problem?
In factorio we have multiple source and multiple sinks of fluid. In original formulation maximum flow gives only constant constraints "that pipe could conduct at most k units". With multiple sources and/or sinks, the solution isn't unique: lets say we produce 100 units in two reactors, consume 100 in two in heat exchangers, and the bottleneck is 50. So we can produce 50 in first, 0 in the second reactor; or 0 and 50, or 25 and 25. The same goes for sinks.
How to fix it?
The worst problem may be cmoplexity. The best one is around O(number of pipes^2).

The fat algebraic method with need O(n^2) only when entity is inserted or destroyed (7ms for 3000pipes) and for normal run is linear.
Simple version is just linear.

But what is the most important, is that it will feel different. With simulation from simple rules we get energy storage, system heats and cools, we have to look after heat flow, if it is enough for a give temperature gradient. It gives natural distribution of load between heat exchangers. And this is great feature of the game, that it gives us a toy version of real systems.

You could treat the reactors as one giant node, which is more inline with how the game treats them anyway. I'll admit it is cool that heat pipes are a heat simulation, but what might be more relevant is simulating them as a set of pipes that behave consistently regardless of their placed order, and as they are pipes, treating them like they have a heat travelling *through* them (rather than being stored in them as you pointed out) might be relevant.

A flow network. Complexity is O(mn) or better (factorio has properties where it's probably O(m log n)). Also that doesn't matter because a] there are update in place algorithms that run in O(n), and this can be done async like pathfinding b] a quick pass on pipes can reduce them to a much smaller number of m arcs (for example a 1000 pipe run could be reduced to a single arc), c] this update pass would allow most pipes to be placed in O(1) update time d] It's not like anyone is building 3000 heat pipes, and if they are the flow network is definitely performing better: it only has to update nodes, which is any heat pipe manipulating entity, rather than every individual heat pipe for information users will not see 99.9% of the time.

(flow networks are also in plenty of commercial friendly licenses, also your spoliered solution involves an O(n^3) on update algorithm so... whoops, on sparse it would be O(n^2) which is fair, but with a reduction on heat pipes, still not as good as O(mn)).

The main problem would be integration with factorio code, and it may not a small task:)

That's the real trick of course.

[bartekltg]

You could treat the reactors as one giant node, which is more inline with how the game treats them anyway.

It is treated exactly that way.

I'll admit it is cool that heat pipes are a heat simulation, but what might be more relevant is simulating them as a set of pipes that behave consistently regardless of their placed order, and as they are pipes, treating them like they have a heat travelling *through* them (rather than being stored in them as you pointed out) might be relevant.

But... this is exactly the point of the proposition! The simpler proposition. In both placing order is irrelevant. As a bonus they have other nice properties, but the main reason for the simple one (just look at the code from my previous post) is to get rid of directional effects.
OK, from the point of view of physic they do not behave like real heatpipe, rather like normal thermal conductors (chunks of copper:), but it seems devs wanted to get the same effect, and simulating real heat-pipes, (where we have stream of gas caring heat and stream of liquid traveling back to the heat source, and boiling point is changing) is complex:) So only heat travel between pipes, not a fluid caring heat, but I think it nice solution, and even more interesting from gemeplay perspective.

The inconvenience isn't that heat is stored. In real life heat is stored:) The issue is that is seems to store a little to much.
But it seems I was wrong, at least a little. Lets say we have 4 pipes (it looks that in factorio when you make a grid, two up/down and two right/left), 1 meter long, 30cm diameter. Then energy needed to increase temperature from 0 to 1000 degree C is almost exactly 1GJ. Like in the game! http://www.wolframalpha.com/input/?i=(c ... 5cm)%5E2+) Pipes in the game looks tinier, but heat capacity is not from the roof. Lets say they store 4 times too much heat. Not 100 times.

(flow networks are also in plenty of commercial friendly licenses, also your spoliered solution involves an O(n^3) on update algorithm so... whoops, on sparse it would be O(n^2) which is fair, but with a reduction on heat pipes, still not as good as O(mn)).

O(n^2) only when updating grid (adding or deleting something). And, similar to Your method, there exist algorithms for "updating" decomposition (so called "rank one update", It should be linear in our case. But that post was too long already, so I skipped some details... I'm glad you asked and I can talk more;)). Still, full decomposition took 6ms on quite old PC for enourmous grid (as you said, no one would place 3000 heatpipes, it needs 187.5 fuel cells to heat to 500degree;) ). What is the most important fact, work that have to be done in one iteration is O(n) and took 0.5-1ms in tests. And we talking about the complex solution. The simple one (the code from prev. post) is O(n) and in my tests 5 times faster.

I'm not saying your algorithm is bad or would be too slow. It just models different phenomenon. I just like devs idea that this is a thermal conductor and it behave like Fourier said. We have fluids already, now we can have heat that behave like heat. So I throw two ideas: first: how fix asymmetry (placing order problem) and increase stability a bit using minimal modification in the code and only slightly increasing needed work. And second: what can be done to make this heat iterations stable without restrictions on parameters like heat resistance and heat capacity.

[Trepidati0n]

I know this bug is fixed..but i'm not sure it was all good

In order to get the 300% bonus you will have to sandwich. This means in this case the sandwich the reactor produces 32GJ of heat in 200 seconds or 160 MW. This takes 16 HE's to eat this. With the new length limits you are forcing a column for anything more 3x2 reactor setup. On top of this, that comes to ~1650 fluid/sec. This adds in dealing with pump mechanics and offshore pump merging. Neither of which are obvious to the casual player. Now we could reduce this to 1200/fluid per second which would leave ~8.7GJ of latent energy stored in the system. With the reactor at 5GJ and each heat pipe around 0.5GJ...it is reasonable and could be "fixed" with some clever circuit logic. But even then..we are still somewhat stuck on a "column design". because we need at least 4 tiles with for the HE, HP, and steam output.

So, to make very wide (big) reactors...it is not easy. Being able to well utilize a 300% bonus is behind close doors (inaccessible) too many. In most cases in this game I could puzzle my way through a problem and get it to work. I almost feel like i'm forced in this case to work in a creative world in order to get something that works reliably before I even consider adding it to my main world. Considering how much I enjoyed going through the spaghetti that was the 0.15 play through...it feels like nuclear is the exact opposite of that.

Potential ideas are:

• make heat pipes directional (this would also fix bot placing)
• increase the capacity of water/steam to 0.4 kJ/deg C (solves the 300% reactor bonus issue)
• make a "heat pump"? (makes us think of heat like water)

Thanks for reading.

[malventano]

Here are some initial observational notes on the new mechanic, now that it has been fixed in 0.15.11:

Heat pipes appear to now have a static 1C delta from pipe to pipe. Heat does not transfer unless the delta reaches that level first. Beyond that point, each pipe drops ~6.5C per tile per 100MW being transferred (don't forget to add the static 1C per tile after that calculation). 480MW can travel ~15 tiles before dropping to 500C. 1000GW = ~7 tiles (less when you consider needing to fan out to exchangers). Parallel paths assist in the heat transfer, but you have to have enough heat transfer taking place to overcome the 1C/tile thing to measure the impact properly. You can get away without adding the 1C/tile for shorter paths carrying higher amounts of heat, as its impact becomes less important.

[Optera]

With 0.15.11 my 2x4 reactor block still works, barely the last HE in each row hovers around 501°C.
I guess another redesign is in order this time doubling or tripling heat pipes for faster heat propagation.

[daniel34]

With 0.15.11 my 2x4 reactor block still works, barely the last HE in each row hovers around 501°C.
I guess another redesign is in order this time doubling or tripling heat pipes for faster heat propagation.

My 2x2 setup also has issues, the last block only has 501°C on the heat pipe before actually travelling through that section but I don't know if it actually works since I currently don't use the 480MW planned rate.

The reactors went to 1000°C aswell although the steam buffer tanks were not full, but laying the main heat pipes in triple solved that issue. I'm not sure if that is just an additional buffer (for the heat) or if laying the heat pipes in triple actually made the heat travel further/faster. I think it's the latter though.

[Optera]

Doubling the heat pipes of my existing design made it run properly.
I'm glad i didn't go for some fancy long heat pipe design.

overview

overview

2017-05-17-08-29-26-6915666.jpg (165.62 KiB) Viewed 7630 times

Reactor Block

2017-05-17-08-30-49-4713013.jpg (212.55 KiB) Viewed 7630 times

I'm controlling reactors using Inventory sensor. It makes it really simply to build an rs-latch triggering on average temperature.

[factoriouzr]

I know this bug is fixed..but i'm not sure it was all good

In order to get the 300% bonus you will have to sandwich. This means in this case the sandwich the reactor produces 32GJ of heat in 200 seconds or 160 MW. This takes 16 HE's to eat this. With the new length limits you are forcing a column for anything more 3x2 reactor setup. On top of this, that comes to ~1650 fluid/sec. This adds in dealing with pump mechanics and offshore pump merging. Neither of which are obvious to the casual player. Now we could reduce this to 1200/fluid per second which would leave ~8.7GJ of latent energy stored in the system. With the reactor at 5GJ and each heat pipe around 0.5GJ...it is reasonable and could be "fixed" with some clever circuit logic. But even then..we are still somewhat stuck on a "column design". because we need at least 4 tiles with for the HE, HP, and steam output.

So, to make very wide (big) reactors...it is not easy. Being able to well utilize a 300% bonus is behind close doors (inaccessible) too many. In most cases in this game I could puzzle my way through a problem and get it to work. I almost feel like i'm forced in this case to work in a creative world in order to get something that works reliably before I even consider adding it to my main world. Considering how much I enjoyed going through the spaghetti that was the 0.15 play through...it feels like nuclear is the exact opposite of that.

Potential ideas are:

• make heat pipes directional (this would also fix bot placing)
• increase the capacity of water/steam to 0.4 kJ/deg C (solves the 300% reactor bonus issue)
• make a "heat pump"? (makes us think of heat like water)

Thanks for reading.

Please DON'T make heat pipes directional. According to the changelog, the order of construction has been fixed. We don't need more complexity to nuclear and heat pipes. There is no reason why the game can't find an internal path for heat to travel in. It's done in so many other parts of the game, eg. belts, trains etc.

Please DON'T make heat like water. The water physics are extremely frustrating in this game. Even with pumps it seems it's impossible to get full throughput on a pipe. Not to mention if you merge pipes, add storage tanks etc. I really dislike the fluid physics in this game. This only became really annoying and frustrating with nuclear power. I spent hours coming up with the perfect 4 reactor system that also looks good. I ran into countless fluid issues, even when running different pipes it took a while to figure out the proper ratio of pumps and realizing I had to use underground pipes because they only count as 2. My reactor works well in 0.15.10 (not sure what happens to it in 0.15.11, I'm about to try it soon. Almost at the nuclear phase in my current game). Then I had to deal with the shitty heat pipes were order mattered. But though all this buffering steam doesn't give me full power until my steam storage runs low, but only for part of it (due to the amazing fluid flow in this game, and pumps attached to the storage tanks don't fix this either). I mean why doesn't a pump pump the same amount of liquid a second as an offshore pump. Why do we need 5 pumps to keep the flow maxed? How is this adding to the gameplay? It just seems tedious to me. Why can't a pump pump out fluid from a storage tank at full speed?

In summary, I'm not a fan of the water physics and the hidden and non intuitive rules that people had to figure out. If you have doubts, just look at all the documentation online and all the forum posts.