Closed esotericist closed 7 years ago
Mmm, I'm honestly mostly hesitant to add something like that because it'll make the connection code yet more complicated. It'd also add another angle of potential errors to the system (unless there's a very clear visual indicator which edges are locked, but "screen real estate" is quite limited already). The latter there are some ways around, just a minor gripe, the former is really why I'm not immediately on board with this. I'll give it some thought. For now, just leave some space between the redstone modules :P
That's what i'm currently doing, but it's making the build vastly more complicated than I anticipated. I'm trying to drive the 7-segment displays from Integrated Circuits, and in the manual mode, they need a bundled cable per display. The final result required me to alternate bundled redstone modules on the top and bottom of the chassis blocks. Then, successfully routing bundles to and from the panels to reach the 7-segment displays, required a different kind of gymnastics.
With regards to visual indicator, you could adopt some kind of standard which puts a visible link between panels that can communicate with each other -- similar to TIS-100's arrows -- and either remove or discolor said link when there's no connectivity.
In this mockup, I used white arrows to indicate active natural links, no arrow to indicate no link, and black arrow (hard to see, the particles were in the way for the two redstone bundles) to indicate disabled link.
I don't know how difficult this might be to implement, but I think it would be a very intuitive visual language for the problem space. Even outside of my original request, I think it'd help make it generally clearer how things connect to adopt the white arrow pattern.
Allright, finally got around to giving this a shot. Better late than never, right? >_>
Basically how it works now is that for each face, one can close the four incoming ports individually (by sneak right-clicking them while holding a key in hand). Visualization is also a bit different (always on the face, not across two, simply because that'd be a massive pain to implement...), but functionality is pretty much all there!
OO!
Looking forward to trying that at some point soon.
Thanks so much!
If you're doing work with bundled redstone modules, it's easy to separate adjacent bundled cable segments (either via color or simply using microblocks to divide them), but the modules constantly pass their state when adjacent.
This makes it impossible to use two bundled redstone modules next to each other, which hardly seems fitting.
Alternately, if things like the redstone module or bundled redstone module explicitly didn't propagate their values to adjacent similar modules, that would do the job as well. I'm not actually sure when someone might want that behavior, but I imagine someone at some point will build something reliant on that behavior, because that's how these kinds of systems roll. :D