Goal

Improve the QoL for P2P tunnels without having to resort to 3rd party modules.

Change tunnel frequency from long to short.

The main idea is to allow some actual QoL improvements.

This will introduce a regression and reduce the amount of p2p links to 65k per network (not actual tunnel parts). Considering that the maximum amount of channels should be around 20-22k for the largest controller, there is still no way to actually hit the potential limit of 65k tunnels of a single network. Non useless setups will be even limited to around 10-11k tunnels in total.

We could further create a combined id of the type and frequency which would expand it to types * 65k possible links, should it ever be a problem.

One of the few real issue would be joining two networks using the same frequency for their links as this will cause a collision by introducing 2 input tunnels. But that should be really unlikely to happen, if we assign random frequencies with smaller networks and joining large networks will certainly have more issue than some P2P conflicts. A possible solution would be using using a global frequency generated by an LFSR or similar, but that would limit it to 65k links for everyone, which might be hit on very large servers. Or we could simply downgrade a random input tunnel to an ouput, when necessary.

Colour code tunnels

The back of each tunnel currently provides 4 2x2 pixel areas, which could be used to map a frequency to a colour code.

This is the main reason to change the frequency to shorts as this allows us to encode them with 4 minecraft colours. ( 16^4 = 2^16 )
Each spot could represent one colour, which would give it a more visible area for each colour, but could more easily be obstructed at certain angles. Or as alternative each spot could contain all 4 colours at the cost of having smaller areas per colour and thus less visible from further away.

Mockup:

Linked state and output/input could also potentially be encoded by colours similar to the state indicator on parts. With the dark colour for everything fine, light for missing channel and off for no power.

Tunnels could use the dark colours for linked input tunnels, medium for linked output and the light one for unlinked ones (of course losing input/output here) and off for no power.

Another option would be to keep longs as value and encode them as 16 colours, It would still fit the available area with 4 * (2*2) pixels. While 4 colours are certainly easy to remember and compare, this will not really be the case for 16 ones. As well as each colour being limited to 1 pixel and thus being more easily obstructed and less visible from farther away.

Waila/OneProbe/etc

We can make these colour codes also visible in WAILA or similar to further improve certain cases, but the requirement to not expose any information not provided visually or in some other way by AE is no longer unmet.

As an end-user this would be fantastic.

Really good idea with the color feature. It was always a mess to reassign all p2p tunnel of my ME-System when moving some p2p tunnel.

I agree tunnel numbering is a usability issue right now but I differs about what to do to handle it.

• Color coding can be an issue for color-blind peoples
• Collisions shall be avoided in all circumstances.

Can't we just keep the Long as tunnel frequency ID but expose a string textual Name to the end-user?
I'd see it as world storage level.dat for a map/table :

TunelName would be what is shown to player when probing a tunnel.
It would be entered by player when creating a Tunnel, the system would choose a random long without collision on existing tunnelID from table above, and maintain a record for each Tunnel.
And as you keep the original long tunnelID, it would not break existing worlds. Just those no name tunnels would use TunnelName = tunnelID.toString().

As said, it should be phyiscally impossible to ever have enough tunnels to exceed the even the range of a short. Collision avoidence could be starting to get costly with a very high amount of tunnels. But that could easily be avoided by a LFSR. There might be even an option to automatically resolve joining two grids and simply regenerate the ids based on the LFSR state of the other grid.

Strings would be just stupid. It would have a GUI to pop up every time you place them and would still force the player to remember was it "Treefarm", "TreeFarm" or "Tree Farm"? Also displaying would be impossible without a major performance issue caused by every tunnels also has to be a fake entity similar to item frames to be able to show the name tooltip.

Also it would force any user to actually name them, certainly not everyone actually wants it and instead just wishes to place them down and be done. Sure they could dismiss the GUI, but having to remember a number with 19 digits is just bad usability.

What about adding a special GUI to the network tool (or a new one)? When you right click a P2P tunnel, it will show you the individual P2P network that P2P tunnel is on, some special information about that P2P network, the coordinates of the input tunnel at the top of the list, and the coordinates of the output tunnels. Highlight the tunnel you selected in the list.

ME Tunnels:
-In tunnel - Number of channels used and number of channels remaining; or used / total available.
-Out tunnels - number of channels that tunnel is using/outputting.

Light: Light level able to pass through tunnel

Redstone: Redstone signal strength

power: perhaps power loss and/or power tracking?

Item: No ideas beyond the default connection list.