P2P QoL Rework #2674

yueh opened this Issue Dec 1, 2016 · 1 comment


None yet

2 participants

yueh commented Dec 1, 2016


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.

colour coded p2p tunnel

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.

Memory card

These could also feature the colour coded frequency at least as text.


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.

@yueh yueh added this to the rv4 beta - 1.10 milestone Dec 1, 2016

As an end-user this would be fantastic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment