Redstone relay

[SquidDev]

This adds a separate redstone peripheral, as described in #1624.

There's still a lot to do here, but felt it was worth making this public and getting some feedback here.

• The peripheral is currently called "Redstone Control". I'm not wild about the name, so here's some alternatives I considered:

  • Redstone Control/Redstone Controller: My main worry here is that this suggests it only outputs redstone signals, not that it can receive them too.
  • Redstone IO: this is what OC uses. It makes sense, but I don't just want to steal the name from another mod.
  • Redstone Integrator: This is what Plethora does (my mod so I can steal from it :p). However, Plethora intentionally went for kinda pretentious(?) names (i.e. Kinetic Augment, Introspection module) — I'm not sure this quite fits the vibes of CC itself though.

  Not sure, feedback welcome!

• I'm using @TheStraying11's proposed textures from Add a separate redstone peripheral #1624. These originally came in an on/off variety for each face. I've decided against this for now, and the block is always "on", as doing the models for this is really awkward. We could just have the whole block be on/off, rather than each face. Not sure!

• The block is directional and uses relative sides ("left", "right", etc...), like the redstone API. We use the same direction mapping as turtles, where left/right are relative to the direction the block is facing (like turtles), rather than the player facing the block (like computers).

Still to do

• Tests
• Documentation

[Karotte128]

I really like this feature!
Another possible name is "Redstone Port", but not sure if this name is good.

[Wojbie]

One alternative naming scheme worth considering could be Redstone extender or Redstone relay? As it extends/relays computer redstone control over peripheral network.

[SquidDev]

Oh, "Relay" is a good one!

[MCJack123]

I know this was already merged, but could we get a side parameter on the redstone event? It can be frustrating to have to check every single input on all connected relays to see if one side changed, especially if there's a lot of inputs - it would be much simpler code-wise if the input change could be narrowed down to a single relay.

(For my specific use case, I'm wrapping peripherals with a driver that limits peripheral events to programs that request them. Not knowing which event corresponds to which peripheral means I have to figure it out myself through a lot of peripheral calls, or the event needs to be sent to all redstone devices, regardless of whether that peripheral changed.)

[Wojbie]

Question is how its implemented.
Correct me if i am wrong but currently even if multiple changes happened at once, they would all generate only one redstone event right? Or would there be several of them?

• If its just one per all changes, then adding name/side argument would mean increasing amount of events generated on busy redstone control system. It may be problematic due to event queue size?
• But if its already generating multiple of them, then adding names/sides it would add some clarity.

I am about 90% sure its just one event for all changes.

[fatboychummy]

Looking through the code, it looks to me like it is one event per relay. Which, if the relay included its own name (and assuming I've read things correctly), would not increase the number of events. However, this would decrease the amount of getInput calls required per event from n*6 (n=#relays) to just 6. This would keep the current limit of 256 redstone relays changing any number of sides per tick (1536 total redstone changes per tick).

Including the side of the relay that changed as well would increase the number of events received, but could then also include the previous and current redstone values, thus eliminating the need to even call getInput at all. This would, however, limit a network to having 256 redstone changes per tick, which is still a decent amount (in my opinion at least). However, since the computer would now be yielding for every change, I don't know if this would have any performance impacts for the increased resumes.

My overall thoughts? Having just the relay name in the event would be a significant upgrade, but going to per-change events may be overkill.

[Lupus590]

I would also be surprised if (in most setups) any given restone relay has more one side being used. While it would make usercode more complex, one could map which side of each relay is being used and thus not need to check all 6 sides of that relay when its redstone event is pulled.

So yeah, having a second return value on redstone events for which relay queued that event would be useful.