Checked for existing issues

• I have checked for existing issues, and have found none.

Tested latest version

• I have checked that this occurs on the latest version.

GregTech CEu Version

7.2.0 dev

Minecraft Version

1.20.1 Forge

Recipe Viewer Installed

EMI

Environment

Singleplayer

Cross-Mod Interaction

No

Other Installed Mods

runClient

Expected Behavior

Pipe networks do not cause sanity damage to the user

Actual Behavior

When a connection is added or removed from a PipeNet that uses a Walker (Item, Energy, Laser, Data; only fluids are exempt), the connection update does not propagate across the network to any existing entrances to the network.

This behavior is by far the most pronounced on ItemPipes, it is sometimes present on the others but is far less common or predictable.

For example, a Conveyor Cover attached to an item pipe and set to import items, the Conveyor will not react to its attached PipeNet changing unless the cover itself is removed and replaced, or the entire region is Saved and Loaded. This results in the cover refusing to send items down a newly created connection, or continuing to send items down a pipe connection that was removed (even if a full pipe block was removed), unless the pipe that was removed was directly adjacent to the pipe that is the entry source.

This causes even further weird behaviors if the source is a block or a cover on a non-pipe block, with source->destination distribution following seemingly completely arbitrary and uneven patterns.

Steps to Reproduce

[I do not have enough sanity left anymore to write a proper explanation]

Additional Information

This is some sort of data propagation or synchronization bug.

Pipe nets that are saved and loaded are loaded in a correct state. However, pipe nets that are modified using normal tools such as a Wrench or "placing new blocks" will exhibit these behaviors.

There is a function to reset a pipenet's routes, which is called on using a wrench on the network. However, pipe net entry points such as Conveyor Covers appear to have an internally cached copy of the pipe net they held on placement or load, and that cached copy is not updated to match the new state of the world.

Additional investigation:

Unsure if this is the same bug or a different bug

Having an existing item pipe net, removing a pipe splits the net

Attempting to place a new pipe to fill the gap and reunify the nets, fails. Specifically, the failure happens in the Blocked Connection Check. And so the new pipe is not added to the old net, and the networks are never reunified until reload.