Bundled Cable compatibility with ComputerCraft is broken
SquidDev opened this issue ยท 2 comments
Describe the bug
There appears to be a couple of minor bugs with ProjectRed's bundled cable API which mean that its CC compatibility is non-functional.
To Reproduce
Steps to reproduce the behaviour:
- Place down a computer, a bundled cable to the right of it, then a white insulated cable and finally a lamp.
- Open the computer and run
rs set right white true
. - Notice the lamp does not turn on.
- Replace the lamp with a lever and turn it on.
- Run
rs probe
on the computer. - This detects no redstone inputs.
Expected behaviour
I would expect the lamp to turn on, and rs probe
to indicate that the white channel is active.
Versions
Include versions of the dependencies. And since you're looking at it, make sure ProjectRed is up to date. Don't submit bugs for old versions, as they could have been fixed.
- ProjectRed Version: Tested in a dev environment at 292850d.
Additional notes
I've managed to find the cause of a couple of these problems, but afraid not everything:
-
The transmission API always returns
null
, rather than the newly generatedsignals
array:I noticed that
BundledSignalsLib
also contains a copy of this method with the correctreturn signals;
. I suspect this is just a relic of the Java port (which serious kudos, that must have been an incredible amount of work) -
The CC bundled redstone provider offsets the position and flips the direction:
This shouldn't be needed - doing
ProjectRedAPI.transmissionAPI.getBundledInput(world, pos, side);
and fixing the above bullet fixes issues with flipping the lever not being detected by the computer. -
The side passed to
IBundledTileInteraction.getBundledSignal
doesn't appear to be correct. I'm afraid I got a little lost here with how PorjectRed handles rotations, so haven't been able to debug this further.
Thanks for looking into this. Definitely seems like remnants from when we moved from Scala to Java.
According to the old Scala code, ITransmissionAPI#getBundledInput
should give you the incoming signal to the block specified, meaning it will offset the given pos towards the face, then ask that neighbor block for its output. The function BundledSignalsLib.getBundledInput
actually does this (see line 36), while the other does not (I believe I started writing this method in TransmissionAPI, then realized it fits better in BundledSignalsLib, copied it there, and forgot to redirect the call).
This is also why the IBundledRedstoneProvider
I implemented offsets the side/face. Your API is an output getter, while mine is an input getter, so it has to operate from the other block's perspective. At the time, both of our APIs were stable so I couldn't just change mine to match unfortunately. Maybe I'll revisit it.
So overall, I think we fix it like this:
- For ProjectRed -> CC, point
TransmissionAPI.getBundledInput
toBundledSignalsLib.getBundledInput
. This alone should fix probing. - For CC -> ProjectRed, like you said, there's a bug with the sides that PR's cables are querying interactions with. Looking into this now.
Found it! Here, the Bundled Cable asks its neighbor for a bundled signal. This line specifically is for registered interactions. For whatever reason, it's using the rotation index rather than converting it into a direction index.
Instead it should be doing what line 230 does, converting that rotation to direction.
Same deal with Bundled gate parts: