Optimize Vis Relay Networks

[DrParadox7]

Is your feature request related to a problem? Please describe.

Optimize Vis Relay networks to be TPS friendly:
https://spark.lucko.me/Y9iyvDRX5E

Describe the solution you'd like

Refactor relays to have parent and child connections stored in a separate class much like Gadomany's Jar Networks.

Have 2 lists in the network:

Set<TileVisRelay> children = new HashSet<TileVisRelay>(); // To check if the network is intact, else refresh connections
Set<TileVisRelay> providers = new HashSet<TileVisRelay>(); // To provide the Vis Relays that are in range of a TileVisNode.isSource()

So instead VisNetHandler.drainVis needlessly cascading through all relays with VisNetHandler.getAllChildren() it just accesses those that have direct access to vis sources with providers.

Refreshing connections resets all VisRelays.
VisRelays within a TileVisNode.isSource() will initiate the creation of a new network if it does not have one.

These Vis Relays will connect to nearby VisRelays, thereby integrating them into its VisRelayNetwork.

This process continues recursively, ensuring that each connected VisRelay updates and further connects to additional VisRelays within range.

When multiple VisRelayNetwork connect to one another, the smallest gets absorbed by the largest, which adopts all of its children.

Describe alternatives you've considered

Adding mirrors that extend the range of TileVisNode as long as these are not are not instances of TileVisRelay (hence not making even more cascading lag).
That's a bandaid to a bigger issue but I might get to do it soon.

Additional context

This change would allow to fix #17 as network refreshes would update the parents of VisRelay.

This whole proposal is already a tall order and the fact that it needs to be done through mixins/asm makes it a needlessly convoluted task.
I would want to take this on with someone who is already closely familiar with TC4 code and a better coder than myself.

Your expertise would be invaluable in executing this improvement effectively and in a timely manner.
I look forward to your views and opinions on this proposal.

[Glease]

Sorry for not responding for so long! many things happened and I'm now finally (sort of) back to modding.

Your proposal probably works, but it might be a bit too complicated than necessary. Please do remember vis relay networks is strictly a single root tree, whereas jar network could be a star network. IIRC my local WIP copy just adds a root field to TileVisNode to prevent having to jump through the pointers to get the source node.

afaik the bigger problem atm with vis network is their instability across chunk reloads. The lag fix would be good, but that along probably won't do much.

[Glease]

IMO mirrors won't work, as VisNetwork.drainVis won't recognize your mirror. Unless you go mixin VisNetwork of course...

[Glease]

After taking a look at vis relay code again, I found a problem with the proposed solutions: vis relay will send visual FX to all the relays alone the path of consumption. Calculating the path is done as a side effect of tracing through the parent. We can sure just remember said path while building the graph, but IMO it will not offer too much in return, as most vis relay network is at most 100 steps deep. 100 pointer deref isn't that much more expensive than iterating over 100 heap objects in an array, since java doesn't guarantee objects in same array to be stored packed together

I can't really say if there is a fix to this..