Describe the feature

Currently, ME networks are limited to a single controller structure. All channels must eventually terminate at the main "hub". ME P2P tunnels are commonly used to send large amounts of channels elsewhere. If players do not want to deal with the channel system, they can enable infinite channels in config.

I would like to propose a new mode where ME networks may have multiple ME controllers. This mode would be disabled by default in config, similar to the infinite channels mode. It would represent a middle-ground between infinite channels and the "hub" mode. Multiple controllers can be connected to each other using dense cable, at which point that cable becomes a "trunk" connection with all channels occupied. Invalid trunk configurations shut down the network in the same way that having multiple controllers normally would.

Reasons why it should be considered

In Ethernet networking, many switches are typically present in a single broadcast domain. These switches may be connected to each other, and end devices connected to any of these switches may communicate with each other. PCIe switches operate in a similar manner.

From a gameplay perspective, this allows more decentralized networks to be feasible. For example, if a player wanted to migrate their house somewhere else, they could do so by building a second controller at the new house, and then bridge it with the existing controller. Centralized networks are highly reliant on ME P2P tunnels, but configuring and keeping track of these tunnels is quite annoying. I personally do not find the gameplay of wiring up a hundred or so P2P tunnels very fun.

An implementation is available here: https://github.com/iczero/Applied-Energistics-2/tree/multi-controller (#8509)

Additional details

No response

How did you account for the changing network structure when chunks are unloaded and loaded again? I saw an error for invalid trunk connection on a quick peek, but didn't look closely.

Having a single controller is a design decision to force the player to think about network layout. Making p2p configuration nicer is a separate thing, and we agree that it would be good to do.

Would absolutely love this feature, especially in layouts where you have several bases of different players talking to each other.

Regarding #8509 (comment):

The feature flag was added because this was designed to be a prototype. In the future, a different type of controller could be used, perhaps named as a "router", and enabled by default.

I understand that AE2 wants players to think about network layout. However, I work in networking, and I believe that the "single-hub" restriction is both unrealistic and, more importantly, not fun. Modern large-scale networks, including the internet, use automatic routing to originate hundreds of thousands of prefixes. Even "small"-scale Ethernet networks use multiple switches, and such is possible even without automatic configuration with STP, assuming the network engineer ensures there are no cycles. This has been the case for decades. Hubs simply stop being scalable after a certain point, and AE2 without large networks just doesn't feel right. The concept presented here is roughly modeled after autonomous systems. Each controller structure represents the router(s) participating in one AS. Devices are connected to these routers, while peering links are established over dedicated ports to routers in other ASes.

In terms of gameplay, this provides both flexibility for expansion while also reducing "busy work". Networks spanning dimensions, or even just spread apart in one dimension, can benefit from the ability to effectively have another controller on the other end of a quantum ring. Moving bases does not necessarily become a piece of cake, but at least AE2 is not the bottleneck. Moreover, P2P tunnel setup and configuration has simply always been a pain. Sure, one can allow up to 1024 channels over a quantum ring, given they carry around 32 memory cards and spend a bunch of time right clicking tunnels. In the past, I have taken to using a spreadsheet to record where each P2P tunnel originates from and where it finally terminates. Sure, some may consider spreadsheets to be entertaining, but this isn't EVE Online. ME subnetworks are often proposed as a way to reduce channel usage, but they aren't particularly suited to that, especially since they only include storage. In any case, this change would not discourage the use of subnetworks for applications where they are well suited.

I have seen significant sentiment supporting Refined Storage as "AE2 without channels", and many simply disable channels anyways. In a sense, "AE2 with infinite channels in config" is already another "flavor" of AE2 that is quite commonly used. While I personally strongly prefer AE2 over RS, I understand why some prefer it the other way. This is one of the ideas I had to reduce the amount of time spent on what I feel to be "busy work" in modded gameplay.

@cplir-c Assuming you have two controllers, if one controller is unloaded, the other remains functional (and so do the devices connected to it). This allows "failover", in a sense.

You can just disable channels if there are multiple controllers. There is no purpose to channels if you can just add a controller at every place of your network.

Ethernet switches regrettably do not have infinite ports.

You can just disable channels if there are multiple controllers. There is no purpose to channels if you can just add a controller at every place of your network.

While I probably wouldn't use either option, I'd say multi controller is certainly more fun than disabling channels completely.