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

[5thHorseman]

Maybe someone should report "construction bots do not place heat pipes in the correct order" as a bug, seeing as there is a non-buggy correct order in which to place them.

[mOoEyThEcOw]

I was mainly describing something which would potentially take a minimal amount of effort to implement.

I'm not entirely sure if the fluid system would actually work plausably for this, since it is intended for there to be a distance limit for heat transfer; fluids don't have any concept of distance, though, nor could it be implemented sensibly on top of the existing logic.

Fluids do fall off with distance currently, try making a fluid pipe 700 units long and see how much water can flow through it. They have all the mechanics they need in there somewhere already.

Besides that, optimized network flow libraries exist for most major languages (including pure lua implementations and native bindings for lua), and you can implement it in ~20 lines of python. But most importantly they have been proven correct and been proven to run in a specific number of steps. Where your solution involves multiple values and states (and also the word "somewhat" to describe the result of a deterministic system). Using a well known algorithm would solve the problem with a single number on each pipe, not ticking the pipes *at all*, and the same update performance as a linked list (that is O(1)).

Maybe someone should report "construction bots do not place heat pipes in the correct order" as a bug, seeing as there is a non-buggy correct order in which to place them.

You could, since that seems like the correct bug report out of this according to the devs.

[TruePikachu]

I agree that using a network-flow system would be a good final solution, once the heat pipe system is reimplemented "as intended". Again, my suggestion was a potentially simple-to-implement improvement for the potentially-currently-implemented system.

My use of the word "somewhat" in "somewhat identical" was to mean that the two temperature states (which alternate between every tick) would be closer together than in a more-naïve implementation of my proposed "solution" to the problem (which could result in the two temperature states diverging from each other in a positive feedback loop). Everything is still deterministic and would run only slightly slower than the currently-assumed implementation (same time complexity, but slightly more logic).

Your example of fluid falloff relates to the pressure of the fluid, not the quantity. While fluid pressure might be similar to heatpipe temperature, there might still be confusion because there is a fluid volume as well -- what would that translate to?

[malventano]

I agree that using a network-flow system would be a good final solution, once the heat pipe system is reimplemented "as intended". Again, my suggestion was a potentially simple-to-implement improvement for the potentially-currently-implemented system.

My use of the word "somewhat" in "somewhat identical" was to mean that the two temperature states (which alternate between every tick) would be closer together than in a more-naïve implementation of my proposed "solution" to the problem (which could result in the two temperature states diverging from each other in a positive feedback loop). Everything is still deterministic and would run only slightly slower than the currently-assumed implementation (same time complexity, but slightly more logic).

Your example of fluid falloff relates to the pressure of the fluid, not the quantity. While fluid pressure might be similar to heatpipe temperature, there might still be confusion because there is a fluid volume as well -- what would that translate to?

Factorio doesn't use pressure - it uses level. In my alternative solution, the level correlates to heat directly. The fluid existing mechanic for fluid actually translates to heat almost perfectly.

[TruePikachu]

Has it been proven that there's a sort of hard limit on how far fluid will travel in a pipe? Also, do you have a good read for the fluid mechanics in Factorio?

[malventano]

Has it been proven that there's a sort of hard limit on how far fluid will travel in a pipe? Also, do you have a good read for the fluid mechanics in Factorio?

The distance limit depends more on the level in the previous section, meaning that fluid level (and therefore flow) tapers off as you try to draw more fluid from the far end of a long section of piping. Same sort of thing happens (IRL) with heat transfer.

[Optera]

Has it been proven that there's a sort of hard limit on how far fluid will travel in a pipe? Also, do you have a good read for the fluid mechanics in Factorio?

There's no hard limit, but it will reach immeasurable low throughput.
viewtopic.php?f=18&t=19851

[factoriouzr]

I just wanted to mention that the game already calculates complex paths in belts, train networks, and pipes. There is also a rail builder that can build long tracks of rail and it will quickly auto-calculate an optimal path around obstacles.

All one has to do is apply one of these same algorithms (like train pathing) to heat pipes. When a pipe is laid down, recalculate the path from the reactor to all connected heat pipes. This is done currently in game for train pathing for much much longer paths then heat pipes, so there is absolutely no reason to burden the player with having to lay pipes in a certain order. The internally expected order can be calculated by the game every time the heat pipe network changes. Instead of this, we got a broken system which breaks a large part of the game mechanics of automated construction, blueprints, blueprint sharing, roboports, personal roboports and replacing entities by robots after being destroyed.

[kovarex]

I agree that this needs to behave in an predictable way. Order of building shouldn't affect it.
The logic and balancing of the heatpipes is something that was basically just left out before 0.15 so I will change it (and also make balance change of it) in the next release after 0.15.10

[MeduSalem]

I agree that this needs to behave in an predictable way. Order of building shouldn't affect it.
The logic and balancing of the heatpipes is something that was basically just left out before 0.15 so I will change it (and also make balance change of it) in the next release after 0.15.10

Could it be made to work similar like Rseding talked about changing/reworking the pipe mechanics?

The following Quote is from this thread here: viewtopic.php?p=270273#p270273

The system I want to implement requires first that pipes be buildable without automatically connecting to every adjacent pipe. Once we think of some nice way to make that work it's quite simple to do the rest:

• All connected pipes act as one large "fluidbox". Pumps would be excluded from this merged set.
• All outputs for the merged set are recorded - outputs being things that consume fluid (assembling machines, pumps, mining drills).
• The merged set can only ever have 1 fluid in it at a time
• All things that input fluid simply do standard flow logic into the merged set as if it was a large fluidbox.
• Each tick the merged set takes the total set volume and the amount of fluid in the set and does flow logic to the outputs using the volume and amount in the set to determine flow speed.

In that way the number of pipes in a given set doesn't effect the flow calculation costs, all outputs get an even amount of fluid no matter how they're connected, and you don't have weird flow problems based off build order.

Now, I don't know if that's going to happen - it has some drawbacks like not having a defined fluid flow direction but (to me) the benefits far outweigh the loses.

If the same mechanic was applied to both regular pipes and heat pipes you'd eliminate 2 problems in one strike.

[factoriouzr]

I agree that this needs to behave in an predictable way. Order of building shouldn't affect it.
The logic and balancing of the heatpipes is something that was basically just left out before 0.15 so I will change it (and also make balance change of it) in the next release after 0.15.10

I'm glad this is finally recognized as a bug. I think most people (including myself) didn't like how it was moved to not a bug without any explanation why the existing behaviour made sense, or any reasonable reply to the criticisms of the current implementation.

[factoriouzr]

I agree that this needs to behave in an predictable way. Order of building shouldn't affect it.
The logic and balancing of the heatpipes is something that was basically just left out before 0.15 so I will change it (and also make balance change of it) in the next release after 0.15.10

Could it be made to work similar like Rseding talked about changing/reworking the pipe mechanics?

The following Quote is from this thread here: viewtopic.php?p=270273#p270273

The system I want to implement requires first that pipes be buildable without automatically connecting to every adjacent pipe. Once we think of some nice way to make that work it's quite simple to do the rest:

• All connected pipes act as one large "fluidbox". Pumps would be excluded from this merged set.
• All outputs for the merged set are recorded - outputs being things that consume fluid (assembling machines, pumps, mining drills).
• The merged set can only ever have 1 fluid in it at a time
• All things that input fluid simply do standard flow logic into the merged set as if it was a large fluidbox.
• Each tick the merged set takes the total set volume and the amount of fluid in the set and does flow logic to the outputs using the volume and amount in the set to determine flow speed.

In that way the number of pipes in a given set doesn't effect the flow calculation costs, all outputs get an even amount of fluid no matter how they're connected, and you don't have weird flow problems based off build order.

Now, I don't know if that's going to happen - it has some drawbacks like not having a defined fluid flow direction but (to me) the benefits far outweigh the loses.

If the same mechanic was applied to both regular pipes and heat pipes you'd eliminate 2 problems in one strike.

I like Rseding91's proposed implementation. It sounds like that would resolve most, if not all issues with the fluid mechanics and heat pipes. The best part of this proposed solution is that there will be no more "mysterious" issues with liquid flow in pipes and uneven distribution. I'm looking at you steam in relation to nuclear reactors. Uneven steam distribution, even in a perfectly symmetrical design results in 1.4 turbines not working on a 4 reactor system, where in reality only about 0.4 turbines shouldn't work (I added one turbine to make an even design).

I also don't see the need to disable auto-connecting pipes. I suggest keeping the existing mechanic of auto connecting pipes and just don't connect pipes if they already contain two separate liquids. Consider these two different sets of pipes. If however manually connecting pipes is handled in a nice and easy way, I also support that approach. There are a lot of situations in which I want to run two parallel sets of pipes, or I'm in close quarters or want to make a build as small as possible and I have to use underground pipes where two straight parallel pipes would otherwise merge. In other words, if done properly, not auto-connecting pipes would allow more flexible designs.

I would seriously love this fix to pipes. It would fix the issue I explained above with uneven distribution of steam leading to strange behaviours. Introducing pumps to the steam pipes in the above example just made bigger issues with the reactors. The design was perfectly symmetrical with enough piping for all the steam (as far as I could tell).

[Taipion]

This is currently how heat pipes work. The order you build the pipes will change how they behave.

It's not really desired to work that way but it's not a bug. We may change it in the future.

I'm sorry guys but this is most definitely a bug - in more ways than one. Something is absolutely broken with the mechanic as it is currently implemented. You guys are the best / most active developers I have seen across any software project ever, but it baffles me that you can look at what heat pipes are doing and say there is nothing wrong with the implementation. You might as well be saying that 2+2=5 is not a bug.

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

However the actual implementation is working as intended, it was written to act as it is acting, and thus there is no bug.

We have had some discussion about changing the way they work, but as it stands, it is working as it was designed

As you are at it, you should add some costly chain of research ingame that is labeled "Witchcraft I", "Witchcraft II" and so on, that does nothing but legitimately entitles the user to search the web for incredibly stupid and unnecessary implementations like this heat disaster.

I can very well understand that you, the guys developing Factorio, live in their own, secluded world, and that you can not understand the view of all those strange people from the outside "real" world,
but you should try and listen, this is, as it is, complete bullshit, mostly due to the fact that it is not, in no way and at no point, documented.

And even if it were documented, it clearly:
- defies any logic
- adds nothing but frustration to the game
- makes the game look broken (as it is broken at this point)
- does nothing good, in that, no one benefits from it (no, it does not add "difficulty", it only adds stupidity)

[malventano]

I agree that this needs to behave in an predictable way. Order of building shouldn't affect it.
The logic and balancing of the heatpipes is something that was basically just left out before 0.15 so I will change it (and also make balance change of it) in the next release after 0.15.10

Could it be made to work similar like Rseding talked about changing/reworking the pipe mechanics?

The following Quote is from this thread here: viewtopic.php?p=270273#p270273

The system I want to implement requires first that pipes be buildable without automatically connecting to every adjacent pipe. Once we think of some nice way to make that work it's quite simple to do the rest:

• All connected pipes act as one large "fluidbox". Pumps would be excluded from this merged set.
• All outputs for the merged set are recorded - outputs being things that consume fluid (assembling machines, pumps, mining drills).
• The merged set can only ever have 1 fluid in it at a time
• All things that input fluid simply do standard flow logic into the merged set as if it was a large fluidbox.
• Each tick the merged set takes the total set volume and the amount of fluid in the set and does flow logic to the outputs using the volume and amount in the set to determine flow speed.

In that way the number of pipes in a given set doesn't effect the flow calculation costs, all outputs get an even amount of fluid no matter how they're connected, and you don't have weird flow problems based off build order.

Now, I don't know if that's going to happen - it has some drawbacks like not having a defined fluid flow direction but (to me) the benefits far outweigh the loses.

If the same mechanic was applied to both regular pipes and heat pipes you'd eliminate 2 problems in one strike.

This mechanic might kill the 'pressure drop' that appears as pipes have increased flow from source to destination. This would be bad, as I suspect it is intended for pipes (and heat pipes) to have a pressure (level) / temperature drop from source to destination, limiting the ultimate length of those items. It also adds realism.

[malventano]

As you are at it, you should add some costly chain of research ingame that is labeled "Witchcraft I", "Witchcraft II" and so on, that does nothing but legitimately entitles the user to search the web for incredibly stupid and unnecessary implementations like this heat disaster.

I can very well understand that you, the guys developing Factorio, live in their own, secluded world, and that you can not understand the view of all those strange people from the outside "real" world,
but you should try and listen, this is, as it is, complete bullshit, mostly due to the fact that it is not, in no way and at no point, documented.

And even if it were documented, it clearly:
- defies any logic
- adds nothing but frustration to the game
- makes the game look broken (as it is broken at this point)
- does nothing good, in that, no one benefits from it (no, it does not add "difficulty", it only adds stupidity)

Easy, tiger, kovarex is on now the case!

[SeaRyanC]

It's absolute madness this was even briefly considered to be not-a-bug. I spent a very long time and actually built extra reactors because my steam setup wasn't getting as much heat as the calculations suggested.

Rseding91 and Klonan, I really respect the work you guys do here, but you badly need to recalibrate yourselves on what constitutes a bug. Trying to describe this as "working as designed" is an enormous miss. Something being so badly designed that it doesn't meet user expectations at all is a bug.

Literally nothing else in Factorio works this way. There's no visual indication that the pipes are "wrong", there's no way to inspect the pipes to see if they are "right", robots will happily lay the pipes down in the "wrong" order (as was in my case), there's no documentation on what the "right" order even is, there's no precedent for build order ever mattering, the procedure of "mine and rebuild" will cause behavior changes, a destroyed-and-auto-replaced heat pipe will behave differently from its original. There wasn't even a description given of how the design actually works! What? What?

I'm very glad to hear this will be fixed in the next release.

[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

[mOoEyThEcOw]

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).

[viveks711]

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).

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

[Zeblote]

A bad or unclear design or implementation isn't a bug.

Bug by design is still a bug from the end user point of view... it doesn't matter whether the design is bad or the implementation.