The ability to connect the peripheral using the side of a wired modem.
accrrsd opened this issue ยท 6 comments
Problem: Right now I'm building a schematic with a rather complex cc:tweaked circuit, a bunch of peripherals and a lot of peripheral device names. When I share the schematic with another player and he builds it, he will have to write down all these names himself (and in a certain order) and change the hard code at the beginning of my program, which in itself sounds incredibly inconvenient and requires video instructions for him.
Solution: It would be great if wired modems had the ability to identify sides and connect peripheral devices using these sides, like a computer. This would potentially eliminate the use of names altogether, but they would still have a niche, for example, for quick access to the far side of the network.
This is a feature that will not break existing programs, but will greatly help in the construction of structures that you want to share with other players, as well as get rid of the hard code of names in programs, replacing them with a path to the periphery
For example (see screenshot)
There are 2 monitors connected here, but it is impossible to access them except through the name in this case, with the proposed method it could be:
local mainModem = peripheral.wrap("back")
local rModem = mainModem.wrap("right")
local rMonitor = rModem.wrap("right")
I just came up with this example, but I think the essence is clear.
This can be applied to a larger number of peripheries, and it is intuitively clear how it works.
In that case, something like:
local mainModem = peripheral.wrap("back")
local rModem = mainModem.wrap("right")
local rMonitor = rModem.wrap("right")
local rBackModem = rModem.wrap("back")
local rBackMonitor = rBackModem.wrap("back")
Combined with something like #264, this would allow you to create self-connecting computers that work "out of the box" for the player who received your schematic and program.
Well, in such cases, you can mark one side as the "front", for example, by making the glow around it blue. And the rest of the arrangement of the sides will be the same as in the case of a computer.
About monitors, this was a simple example that I came up with on the go. In my particular case, these are redstone integrators from another mod, in order to identify them, I have to put a redstone block on one side, but I can only do this 6 times.
Usually players solve that issue by having installer program that asks user to click on monitors in specific order or asks for number displayed on monitor to determine network names of multi monitor setup and then saves that for future use.
I feel like this suggestion would quickly lead to odd instances like for example where is back or front of a full block modem? After all they are directional less blocks so this kind of reference don't make much sense?
Thanks for the report! I definitely understand the motivation for making more reusable builds, but I'm not sure this is the right solution to the problem.
I think tying in the topology of the network into the program is a really quick way to produce unreadable (peripheral.wrap("back").wrap("right").wrap("back")
) and unmaintainable code. This might work for a couple of modems, but it fails to scale beyond there. There's also the obvious question of what you do for any non-trivial network layout, such as this:
I think the better solution here is to allow naming/tagging specific peripherals (see #78 (comment)), though I've not found a design for this I really like.
Thanks for the report! I definitely understand the motivation for making more reusable builds, but I'm not sure this is the right solution to the problem.
I think tying in the topology of the network into the program is a really quick way to produce unreadable (
peripheral.wrap("back").wrap("right").wrap("back")
) and unmaintainable code. This might work for a couple of modems, but it fails to scale beyond there. There's also the obvious question of what you do for any non-trivial network layout, such as this:I think the better solution here is to allow naming/tagging specific peripherals (see #78 (comment)), though I've not found a design for this I really like.
Why would it need to be that redundant though. you could far simplify this and make it way more readable by passing in a path string or table that's a path to the peripheral. Ex. peripheral.wrap("back>left>top>top>bottom")
where > is an arbitrary delimiter for an example. Or even more granular something like this peripheral.wrap("back:modem>left:modem>top:modem>top:printer")
that would the same behavior but also allow filtering by type along the path as well.
you could far simplify this and make it way more readable by ...
I believe the point being made was that this is not something that could be applied to most networks -- the simplified code will run into the same issues as well, and those are assigning which modem is which, and the reliability of accessing them.
For an example, imagine an arbitrary network with one modem that connects to 20 other modems (with nothing in-between but a bunch of cables). From that one modem, which modem should be considered "left" in this case? Which modems should be considered the other directions? When you assign all possible directions, how do you access the remaining modems with this system? Will any modems be assigned multiple directions from the first modem? Are any modems impossible to reach through any path in the system?
As for the actual path itself: Note that there are many different ways to set up a network. For reason A or B or C it may not be feasible for someone to set their network up such that modem X is to the left of modem Y. Normally this can be handled by just saving the name of the peripheral, or as recommended before having the user touch the monitor/enter a code displayed on the monitor, but in this case the code will now just throw an error because the positioning of the modems is no longer exactly as specified. Thus, the code becomes less resilient to outside factors.