I would argue that connectivity between tiles can be handled separately from the active objects.
You could have wiring/piping started by something similar to the quantum wires in DF - you indicate where you want it to start, and then it lets you know which other nodes are in range as the endpoint . The pathing is done on installation, with resource costs determined by distance. At the moment of install, two things happen - you create (or add on to an existing) ‘network’ using a data structure outside the reality bubble, and you generate the wire/piping path in the reality bubble by the fields method mentioned. The network data structure would just need to be a list (not even a tree) of all nodes, with each entry containing something pointing to the actual corresponding in-game object, what network the node belongs to, what nodes are directly connected to it, and what the node is actively doing. The fields would only need to know two things, and both of those passively - what kind of network it represents and what network it belongs to.
Then any time a tile with a field in it has Something Substantial happen (i.e., something that could/does break a connection), you eliminate that field and then run a fill from an arbitrary node in that network, checking the connection along the entire route. If there are any nodes that can’t be reached by that check, run a fill from each of those in sequence (still using existing connection fields) and create/re-connect them into their own networks as necessary. There could be a construction command to rip out wires or pipes (and maybe a tool or two to let you find wires/pipes through in-game means?) to get resources back. The network data structure’s simplicity could also lend itself to letting your networks run while you aren’t there. Instead of directly modifying the data for a running generator connected to a storage battery (since I assume that’s pretty thoroughly offloaded when outside the bubble), the network could just take a snapshot during the offload of any given node and store deltas to be applied when those nodes are back within the bubble. And since these networks would ONLY exist as the player creates them, you shouldn’t run into issues unless players are doing stupid player tricks with ridiculously sized networks.
So a straightforward example - I want to connect a bicycle generator to a storage battery. I set up the generator, then I set up the storage battery. I then go to one of them and say I want to connect the two. It checks the distance, says it will cost so much copper wire and I say OK. It then routes the power, building the connection directly between them, adding them both to Network 0. I then want to connect a floodlight to the storage battery, but they’re too far away, so I craft and then set up a repeater at a midpoint. I then wire the midpoint in, and then the floodlight, and now Network 0 has four nodes. I decide to go scavenging and accidentally leave the floodlight on - when the node objects are offloaded, it snapshots that the battery has X power and it knows the floodlight is on and that floodlights consume Y power/minute. While I’m out and about, it acknowledges that the amount of power consumed == X, so it knows that the floodlight should be off and the battery should be at zero power. When I get back home, and it loads the floodlight and battery into memory, it applies those deltas to the objects and I get very upset at myself. Later, I accidentally throw a grenade into my wood stove, and the repeater is destroyed in the chaos. The game then recalculates the network, and moves the floodlight into Network 1 pending home repairs.
To handle an edge situation like damage to a network that is partially within the reality bubble, the reconnection logic only needs to make one assumption - that the only things that can change are those within the reality bubble. So when Something Substantial happens somewhere in the reality bubble that causes a network connection recalc, every node within the relevant network should be flagged for a recalc individually. The logic would then randomly select for the fill test only a node that is within the reality bubble. When doing the fill, it assumes that if a connection is on the border of reality heading outside the bubble, then everything beyond that point is intact (and can be handled using the nodes’ connection info stored in the network data structure). If every node within reality is handled and the flagged out of reality ones haven’t been addressed yet, then they would default into being their own network. And since everything is specific to a network, if a player had 20 networks but damage only happens to network 14, it would only be network 14 that needs to be calculated.
IANA coder, but I imagine that the above could handle a lot of the weird edge cases while also allowing for player constructions to continue to operate off-grid. It certainly has a hefty smell, but I don’t think it’s quite as hefty as fiddling around with stored map data.
