{"action":"created","issue":{"url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/1163","labels_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/1163/labels{/name}","comments_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/1163/comments","events_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/1163/events","html_url":"https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/1163","id":65342651,"number":1163,"title":"P2P Terminal","user":{"login":"Musicdude14z","id":2349563,"avatar_url":"https://avatars.githubusercontent.com/u/2349563?v=3","gravatar_id":"","url":"https://api.github.com/users/Musicdude14z","html_url":"https://github.com/Musicdude14z","followers_url":"https://api.github.com/users/Musicdude14z/followers","following_url":"https://api.github.com/users/Musicdude14z/following{/other_user}","gists_url":"https://api.github.com/users/Musicdude14z/gists{/gist_id}","starred_url":"https://api.github.com/users/Musicdude14z/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Musicdude14z/subscriptions","organizations_url":"https://api.github.com/users/Musicdude14z/orgs","repos_url":"https://api.github.com/users/Musicdude14z/repos","events_url":"https://api.github.com/users/Musicdude14z/events{/privacy}","received_events_url":"https://api.github.com/users/Musicdude14z/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-03-31T01:48:42Z","updated_at":"2015-04-02T09:22:40Z","closed_at":null,"body":"So first off, this is a suggestion not a bug, I hope I am putting this in the right place (pretty sure I am otherwise I wouldn't post!).\r\n\r\n## The Problem\r\n\r\nBefore I get into details of the idea, I'll give an example of the problem I'm trying to solve. Imagine wanting to create a massive AE network in a huge base, but you foresee yourself needing 500+ channels, and you want to spread out your machines over the surrounding chunks to avoid lag. Instead of running tons of dense cable adjacent to each other in all directions, it obviously makes sense to run far fewer dense cables outwards as a sub-network, and run several P2P tunnels over that sub-network. \r\n\r\nGiven that, a good design would be a sub-network with a network controller or two, allowing sets dense cable transmitting a total of 32+ channels that connects different regions of your base back to a central using P2P tunnels. This central location would have the network controller multi-block for the main network, and the P2P tunnels would come directly out of the faces of the controller and into the sub-network.\r\n\r\nThe only setback with this design is *book-keeping*. Essentially, after adding more than 32 P2P tunnels sending channels from the main network over the sub-network, it would become increasingly complicated to keep track of which P2P's are connecting to which and how many channels the parent P2P is sending.\r\n\r\n## My Proposal\r\n\r\nI know this is not exactly *crucial* to the functioning of your mod, but I think it could add a useful (*and __not__ redundant*) feature that is in the style of the rest of the mod.\r\n\r\nI am proposing the addition of a single block: the P2P Terminal.\r\n\r\n### \"Requirements\"\r\n\r\nAssuming that each P2P tunnel placed in the world has a couple of states that can be distinguished between (or assuming that they could be changed to keep track of these states internally), then I believe the following would at least be feasible. The states that would be required are a boolean representing whether or not the P2P is a parent node (sending channels versus receiving); how many channels any given P2P is transmitting/receiving; and if the P2P is a child node, some unique identifier of the parent node it is receiving channels from. The last bit about child nodes is only needed for a more advanced feature of my idea that is not necessary for the functionality of the proposed block.\r\n\r\n### Functionality\r\n\r\n##### The Interface and Main Functions\r\n\r\nThe terminal would be placed on the sub-network that the P2P tunnels communicate over. Its interface would be very similar to that of the Interface Terminal. It would display a line for each parent P2P sending channels over the sub-network (similarly to how the Interface Terminal has a line for each interface), except instead of having 9 inventory slots to place patterns it would have 32 grayed out tick marks (or some other representation of the 32 available channels). For each channel that the given parent node is transmitting, a tick mark would be colored in (maybe purple?).\r\n\r\nIt is reasonable to note that a P2P connected with a smart or fluix cable to the back would only be able to transmit 8 channels. However this is not a limitation of the P2P tunnel, but of the network design, and so the **best implementation** would probably be to consider all P2P's to have a **maximum of 32 channels** when viewed in the terminal (so the sum of colored in and grayed out tick marks is always 32). \r\n\r\nA P2P Tunnel that has not been bound (not a parent or child) should probably **not** show up in the terminal. If it is connected with a child node, it would then show up in the terminal. If it is loaded with configurations of a parent node, it would become a child and not show up in the terminal. \r\n\r\n##### Paring and Memory Cards\r\n\r\nIn addition to offering an organized way of viewing the network usage of your P2P tunnels, I thought this block could also organize the pairing of P2P parent and child nodes.  The current system of pairing P2P would not be removed, this would simple be an addition.\r\n\r\nThis could be done one of two ways. First, the terminal's interface could have a single inventory slot where a memory card would be placed. This slot could be on the right hand side (similar to the upgrade card slots some of your machines have), or in any other convenient location (a corner maybe?). Once a card is in this slot, there would need to be a way of selecting a parent P2P tunnel in the central portion of the interface. This could be done, for example, by allowing the last clicked line in the central portion to be visibly selected (shaded darker or something), and having a \"Bind\" button near the inventory slot to click. Upon this event, the memory card would be loaded with the configuration information of that parent node. This card can then be used to configure future child nodes.\r\n\r\nAnother option would be to have no inventory slots or buttons, but to allow the card to be \"placed\" in a line as if each one were a very long inventory slot. Upon the card being placed in a given line, it would immediately be placed back in the player's inventory (or dropped to the ground if full) configured to that parent P2P.\r\n\r\nAnother worthy note would be that you could also implement both of the above techniques, but allow a P2P tunnel item to be used instead of a memory card, to bind directly to that tunnel. I doubt this is easily doable though because I suspect the P2P tunnels must be placed and connected to the sub-network their parent is on before being bound to that parent.\r\n\r\n##### Bonus Feature (Less Crucial to Functionality, But Cool and Useful)\r\n\r\nThis is where the bit about a child node have a unique identifier of its parent node comes into play. Instead of coloring each channel tick in the same color, a color could be assigned to each child node associated with that parent, and the ticks being sent to that child are colored in with its color.\r\n\r\nThis would be simply done given a parent node's load, and it's children's loads. For example, if a parent is sending 15 channels, and it has three children receiving 7, 6, and 2 channels. Then 6 ticks could be colored purple, 6 green, 2 orange, and the rest grayed out.\r\n\r\nAdditionally, since the maximum number of child nodes is 31 (I'd say 32 [1 channel each], but I don't think you could hook up a parent and 32 children together without having channel issues), the color pallet would only have to support 31 (or 32) different colors (in addition to the grayed out state).\r\n\r\n##### The Block Itself\r\n\r\nObviously, the block itself would be a multi-part just like any other terminal, and similarly require a data channel. \r\n\r\nIts crafting recipe would almost definitely contain an illuminated panel. It would probably contain a memory card and/or a P2P tunnel. And it would most likely contain at least some form of processor.\r\n\r\n## Final Words\r\n\r\nI know this wouldn't be the easiest of features to add, but I was thinking about your mod and some efficient network designs and I though this was at least a worthwhile idea to have you consider!\r\n\r\nAnd honestly, if anyone had read this far, thank you for your interest/dedication and time because I definitely wrote a whole lot here :P "},"comment":{"url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/comments/88838530","html_url":"https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/1163#issuecomment-88838530","issue_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/1163","id":88838530,"user":{"login":"yueh","id":151949,"avatar_url":"https://avatars.githubusercontent.com/u/151949?v=3","gravatar_id":"","url":"https://api.github.com/users/yueh","html_url":"https://github.com/yueh","followers_url":"https://api.github.com/users/yueh/followers","following_url":"https://api.github.com/users/yueh/following{/other_user}","gists_url":"https://api.github.com/users/yueh/gists{/gist_id}","starred_url":"https://api.github.com/users/yueh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yueh/subscriptions","organizations_url":"https://api.github.com/users/yueh/orgs","repos_url":"https://api.github.com/users/yueh/repos","events_url":"https://api.github.com/users/yueh/events{/privacy}","received_events_url":"https://api.github.com/users/yueh/received_events","type":"User","site_admin":false},"created_at":"2015-04-02T09:22:40Z","updated_at":"2015-04-02T09:22:40Z","body":"I should also add that the list wil never be guaranteed to be complete. It will only know the currently loaded and active links. If you have 3 distant and usually unloaded bases, it will never show these as valid endpoints and you probably will not notice any issue before all 3 are loaded.\r\n\r\nI would consider using the inside of a ring as trying to build the most compact version. Nobody really forces you to do so.\r\nI personally never used more than a single controller block. It was mostly a medium sized base, but going massive in terms of improving the amount of parallel machines would be completely irrelevant. 1 Pulverizer would have used the same amout of channels as 1000 ones on the main network. And no I did not use any pipe mod.\r\n\r\nWaila is optional. So we cannot but any information in it, which are not visible with AE2 alone. Otherwise we would enforce Waila (or any other mod) as hard dependency for users."}}