Idea to fix p2p case

[ghost]

First, I'll resume what I know of the P2P: they are 2 kind of p2p, the bidirectional ones (P2P me and... that's it) and the unidirectional one (rf, item, liquid, light, ... the rest). They're connect to each other through frequency and not directly.

Basically, the change I have in mind will be more for the unidirectional ones and will consist to give more importance to the p2p itself by connecting them together. That way, because the p2p connection would be concrete, it would be more easy to concretely show it. Also, what I mean by p2p knowing each other doesn't mean that every p2p know all the other, it just mean that, at least, a p2p work as a central node for the other.

Little focus about p2p link showing: Since glasses were already a suggestion, why not using those ? However there a lot of possible p2p in the same network, so why not only showing the p2p related to a link card handle by a player (or in his tool bar). That way, the amount of connection to shown will be only 1 (or 9 if extend to the tool bar) and since the p2p know each other, finding them all will be easy and a path finder should be able to find a path between them (or at least between the p2p and the controller). Since the path is directly linked to the memory card, it can be saved within. Also, it would be possible to recycling the meteor compass. The p2p knowing each other, you can access all p2p coordinates and set the compass to the chunk and once reached the right chunk, the glasses should do the rest. For the setup, I've think of a GUI opening when shift right clicking with the compass in air. The gui providing a list of the different P2P connected (and they dimension id because even if in vanilla minecraft, they only 3 dimension, modded minecraft can really have a bunch of those) with the "source" p2p (emitter in fork mod or receiver in "join" mod) highlighted.

A bit more about glasses evoke in the previous paragraph: I think there basically 2 way of doing those. the first one would be some normal item which cost to craft but doesn't require anything... the OP meter would explode in this case. The second case is to add those in the list of item consuming power: it would consume power while showing connection. Because always consuming power while having a memory card assigned in your hand would be really power consuming, I think of making the link showing on smart and dense cable free, that way, you incite people of using smart cable instead of flux ones but would also mean showing the connection on other cable and maybe even inside component while activated (or maybe just leaving it to creative player trying to explain channel path)... or showing nothing when the glasses are just equipped and only on smart & dense cable for the link. The concept of showing p2p save in the memory card could even be extends to some other component but in that case, the OP meter would explode and memory card will deeply change. Leaving it as creative only would also be a easy mod.

The "join" mod (most important feature ever) & named p2p network: The organization of the p2p around a central p2p make unidirectional connection way more simple (or maybe just in my mind ?). The central node being the one which receive or send flux, the other node have just to know which is it and in which mod they are. A bandwidth limitation would found it place into this particular node easily. Also, if the central node is named, it name may be considered as the name of the p2p network because it can easily be spread to other p2p.

The down side I think that may cause: First, regardless to whether it would be useful or pointless, this change would implies a deep rewriting of the code and it completely leave the bidirectional P2P apart. It would probably imply p2p resetting if not worst like breaking retro compatibility and create issues along those things. Also, P2P would take more memory (except if an object reference and a boolean ("join" or "fork" mod) have smaller resource cost that a long)

That's all my idea. It seem to me like possible but I don't know how the code work in detail so, I let you see and judge. Thank you for taking the time to read this post.

[yueh]

First thanks for the very detailed comment.

I have not really looked at the code for p2p itself and the limitations about unidirectional tunnels. But let me add some other remarks.

First the glasses, I personaly find it an extremely bad solution. There are so many mods adding different headgears and compete with a single slot available as well as forcing the user to carry them around. We already have a network tool, which also enables the player to make facades transparent. So there is no real reason to add yet another tool for a minor maintenance task. It also works without requiring a limited gearslot.

In the same way letting a utility tool consume power is just adding tedious maintenance work. It gives no real advantage in terms of giving you access to your items, letting you mine and obtain more resources or put some limitation on the player to force them to consider their setup. Making a memory card only have limited uses and break after 20 uses is pretty similar. But most (if not all) mods do not have maintenance tools break on use, because it is mostly annoying to replace them as they always break in the wrong moment. Of course making it only work on smart/dense cables would make sense. (I wish we had shaders and would not need to stitch textures together)

The frequency is just a value to find their links, but they are knowing each others directly. But there can be quintillions of different p2p channels each with thousands of links and that is the challenge to visualize it. So printing it to the chat can overflow it, same for a GUI with a simple list.

Also there are no paths, a controller only traverses the grid/cables until it runs out of channels for the current side or hits an already visited part. But the path itself is not conserved, just that the part has a channel or not. So to actually render it, we would need to fully traverse the grid and locate the shortest path and account for every possible change in the network and recalculate it again

[ghost]

First, thanks you for taking time to read and answer my post.

About the glasses, as you said they a lot of mod which add glasses and that probably what make me think that would be a solution but since the network tool can already have visual effect for network maintenance, it would be dumb to add another. For the power consumption, I'm afraid that the tool assist too much the player but putting the way you did, it's logical to help it with simple tools that some various, complex and limited one. I've badly understood the spirit of the mod (and also good mod in general I think) on this point.

Now about the p2p, the idea (which may not require a rewriting finally) would be to only show p2p connected together. They still can be a lot but I don't think someone who use p2p rf to power his base will use a thousand of output, principally because it's easier to spread power to machine with one cable out of a p2p rf than using one p2p by machine. The id of connecting them together was to prevent all p2p communicating together even if there not linked but if frequency can do that, no need to rewrote the all thing.

About showing the link between p2p, rather than calculating it in the memory card and display it. Because it's more likely to found p2p linked together, it doesn't have to be dynamic or instant. Just something like a slot inside the network tool and when you place a memory card inside, it show you the actual shortest paths between p2p. I think just that may help a lot on p2p managing but as you said, it may require shaders.

Also, I've take more time to try to understand the code and... I'm really dumb and naive. Basically, p2p seems to have a "output" boolean in their code which, as far as I understand is used both to know whether the p2p output and if it is the "central" one (chosen by the memory card). Everything related to p2p connection is handle into the Part.P2P.PartP2PTunnel.java class. In both click and shift click methods, there a variable call "mc" representing the memory card used by the player so if the memory card define whether the p2p work in "fork" or "join" mod, you can access it here. For the switch, something like placing the memory card into the crafting table (like toggle bus) should be way enough. That with a clean of the frequency to make sure there can be multiple output and multiple input in one frequency (if it keep the frequency of "fork" p2p while being in "join" mod, it may happen) should allow a sure switch. Also, the output mod being use to know whether a p2p is the p2p on which the memory card was set, a new way to know this p2p or the mod of those is need, which is common for all p2p as the same frequency. Something like "If the frequency is peer, it's a fork mod" (or "frequency & 1 == 0" in code) should do it and them, changing the code to acting according given by the test.

I... This post is probably way more relevant that the other one... I feel dumb and that I've make you wasting your time and I'm deeply sorry about that :(

[ghost]

I'll close this issue and work on a fork with those things.