[Dominik][0.17.17][Mod] Fluid boxes not updating connections after create entity script event

[Staplergun]

It seems that fluid boxes don't update when placed via a script in certain situations during runtime.

Saving and loading does cause a proper connection.

Old behavior:
https://gfycat.com/ImprobableInfatuatedAmurratsnake

New Behavior:
https://gfycat.com/niftydiligentangelfish

After rotating them:
https://gfycat.com/nastymaleduckling

After a load:
See factorio_2019-03-23_21-49-43.png down below


This behavior was not present in previous versions of 0.17. It seems to have sprung after the fluid box fixes (it worked in 0.17.12) and seems related to the create_entity...possibly. I'm no expert. My advanced fluid handling mod works correctly and seems to update all of it's underground connections correctly after replacing it.

Steps:
Load map and mod given.
Use any regular pipe and click and drag it (or click one at a time, however you like to place it) like either the old or new behavior gif.
Save/load or rotate any one of the caution striped (clamped) pipes.

[Staplergun]

The intended behavior if the pipe changing and why it's not working is:
When placing pipes, it checks to see if the pipe it's being placed next to has two neighbors, as long as one of the neighbors is not the previously placed pipe. The script replaces the pipe with a different entity (pipe to ground) that has a modified fluid box that has different connections than a regular pipe that restricts connections allowing neighboring placement without connections. Since the fluid boxes don't update connections correctly, it doesn't recognize it when running the neighbors method on the entity, so it doesn't get it's count correctly.

[Dominik]

What I see in the video is that when the script replaces the normal pipe by the special one, it is placed but does not connect.
Why would you use pipe to ground for it when you are making normal connections? Using pipe to ground only makes things complicated and I don't see any benefit. It is not a reason why it should not work though.
I don't understand LUA so I can't help you with that side. But in the code everything seems fine (setup is run and making connections attempted) and I suspect that your connections are not configure correctly.
Even more so now. I am trying the same horizontal case, but the connections are north/south. So please, check if the script is ok.

[Staplergun]

The issue isn't on my end. This exact script worked just fine in 0.16 and earlier versions of 0.17. The fact that the connections aren't made until I rotate the pipe, or save and reload the file, shows that it is something that isn't working right underneath.

Pipe to ground is used because it has a different picture set than the regular pipe, and it can be rotated, therefore using far less entities for the same effect as what it would take for a pipe.

[Dominik]

Nice argumentation but not entirely correct
Worked before - does not mean it was correct. Often things work because of a bug. When it gets fixed they stop working.
Rotation/load - good point and useful information. But that is a different situation - those actions happen only after the whole script has finished.

I was wrong about the direction - the direction is ok.
What I see now as the problem is that when the new pipe is being setup, the old pipe is still alive and well, the side pipes connected to it, so the new pipe has nothing to connect to. Your script only removes the old pipe afterwards and that is too late. But when you save/load or rotate, the old pipe is already gone and it connects.
I still don't know what change caused that it behaves differently now. But what it does now makes sense. So please, see if you can make your script remove the old pipe earlier. That should fix it.

[Staplergun]

I have to delete the old one after the fact to port fluid and be able to pass certain information for the purpose of other scripts interacting, though I may be able to work around that for sure. I'll definitely look into doing it.

Also I'm sorry I was mistaken. It wasn't working in earlier versions of 0.17 as far as I can tell.

[Recon777]

Nice argumentation but not entirely correct
Worked before - does not mean it was correct. Often things work because of a bug. When it gets fixed they stop working.
Rotation/load - good point and useful information. But that is a different situation - those actions happen only after the whole script has finished.

I was wrong about the direction - the direction is ok.
What I see now as the problem is that when the new pipe is being setup, the old pipe is still alive and well, the side pipes connected to it, so the new pipe has nothing to connect to. Your script only removes the old pipe afterwards and that is too late. But when you save/load or rotate, the old pipe is already gone and it connects.
I still don't know what change caused that it behaves differently now. But what it does now makes sense. So please, see if you can make your script remove the old pipe earlier. That should fix it.

I've done a fair bit of experimenting with this and here is the simplest scenario where I can demonstrate a change in core game behavior between 0.16 and 0.17 using the same script.


Step 1 is to draw a line of pipes. Note that the game considers these continuous, as the picker pipe tool overlay indicates.
Step 2 is to add a single pipe adjacent to the middle (not the ends) of that line of pipes.
Note that the segment which the new pipe touched is now clamped, isolating it from the new pipe.
Note also that the original pipe is still continuous, as indicated by the overlay.


Repeating the exact same procedure in 0.17 produces different results.
This time, the pipe segment placed adjacent to the previous continuous line severs that continuation at the clamp.

To be clear, this is the exact same script. Why would behavior be different in 0.17? Can this be isolated in the base game code?

[Dominik]

Yes, this is the setup I use for testing. It splits it, because the new pipe with stripes is placed, does not connect yet as the neighbouring pipes are still connected to the old normal pipe, then the normal pipe is deleted and this is the result. As I wrote, I don't know why it is different. Too much code has changed since then.
If you enable the debug mode by F6 I think or F5, you can see the fluid system numbers in the tooltip. That also works to see what is connected.

[Bilka]

I can reproduce a desync when placing two pipes on top of each other.

Steps to reproduce:
Load the attached map which contains a simple setup of 3 pipes in a line with infinity pipes at each end, one of the pipes is located at the position {-2.5, 0.5}.
Run /c game.player.surface.create_entity{name="pipe", position ={-2.5, 0.5}, force= "player"}
Run /toggle-heavy-mode

Observed:
Heavy mode fails

Expected:
The game handles two pipes on top of each other in a save-load stable way.

[Rseding91]

Yes, this is the setup I use for testing. It splits it, because the new pipe with stripes is placed, does not connect yet as the neighbouring pipes are still connected to the old normal pipe, then the normal pipe is deleted and this is the result. As I wrote, I don't know why it is different. Too much code has changed since then.
If you enable the debug mode by F6 I think or F5, you can see the fluid system numbers in the tooltip. That also works to see what is connected.

In 0.16 and previous inside the destroy() logic for a given fluidbox it would collect the list of other fluidboxes connected to it, and after disconnecting itself, reconnect them. This was changed some time during the pipes logic of 0.17 by the logic just being deleted. Now it only reconnects underground pipes that where connected to it.

To fix it, the 0.16 logic needs to be restored: when a fluidbox is destroyed it needs to tell anything it was connected to to re-connect. That is of course going to cause fluid mixing so that will have to be handled (or not).

I made a test for the logic and send you a PM about it.

[Dominik]

I realized that this does not concern only pipes but any entities with fluid boxes. So while still don't think there is any sense in having overlapping pipes, the issue spans further and is not worth potential disruptions of I don't know what modded stuff. So I have changed it so that also normal connections reconnect when a fluidbox is destroyed.

[Dominik]

No, sorry, turns out the fix did create troubles. Will have to postpone this until I come back from EGX.

[A.creature]

HI, any news about fixing this glitch?

[Dominik]

Being in the resolved category is the news. Sorry I did not post anything.