[rubensworks]

Closes #1785

Cause

When a chunk containing a cable loads, its parts come back with new states that still need to be attached to the network (afterNetworkReAlive).

1. A cable with parts is still ticking, so BlockEntityMultipartTicking#onLoad leaves revalidation to its ticker.
2. Before that ticker runs, the network tick lazily revalidates the cable's first updated part (Network#isValid → PartNetworkElement#revalidate). That links the cable's shared network carrier, and only that part gets afterNetworkReAlive.
3. The cable now has a network, so NetworkHelpers#revalidateNetworkElements is never called for it.

As a result:

• Other updated parts on that cable are revalidated but never receive afterNetworkReAlive.
• Parts that are not updated, such as Integrated Tunnels interfaces, are never revalidated at all, so their new state never learns about the network.

In the reported setup, an Integrated Tunnels energy interface shares a cable with an omni-directional connector (an updated part). After a reload the interface exposes no energy capability, so Oritech generators can no longer push energy into it. A wrench click reinitializes the network, which is why that worked around it.

Fix

The part that links the network carrier during revalidation now also revalidates the other parts at its position and calls afterNetworkReAlive on them. Parts revalidated through NetworkHelpers#revalidateNetworkElements don't get a second afterNetworkReAlive, because the carrier is already linked by then.

Reproduction and verification

Reproduced on a 26.1.2 dedicated server running Integrated Tunnels 1.13.3, Oritech 2.0.0-exp12 and NeoForge 26.1.2.126. The setup was an Oritech creative storage pushing into an energy interface, linked by omni-directional connectors to a second energy interface feeding an Oritech large storage.

• Before: after the source chunk unloaded and reloaded (or loaded after server start), the sink received nothing. The interface's part state had no network.
• After: energy kept flowing in every variant: runtime source reload, source loaded after startup, plain restart, and sink loaded after startup.
• Control: moving the omni connector to its own cable also avoided the problem without the fix, which confirms the cause.
• Setups that never broke: setups using ID batteries or Tunnels exporters. They pull energy from the network by position, which never depends on the interface's state.

Tests

• New game test testNetworkRevalidateAllPartsAtPosition. It recreates the part states as a chunk reload would, then lets the first part relink the cable. It fails without the fix ("Second part was not attached to the network") and passes with it.
• ./gradlew build passes.
• ./gradlew runGameTestServer: all 1084 required tests pass.

---

Generated by Claude Code

[coveralls]

coverage: 49.54% (+0.09%) from 49.451% — claude/laughing-franklin-9r024o into master-1.21-lts