Describe your problem, including steps to reproduce it
When connected via xnet cables/connectors, some (not all) item routers do not get a block update when redstone signal is removed, and do not retract their blocks back into the router.. however, when a block is placed or broken directly adjacent to the routers that aren't responding, they update and will retract, (after redstone signal has already been removed and they didn't update).
all routers have the same modules and upgrades: Extruder MK2, had camo upgrade but removed for screen shots, and 2 Clock upgrades because they wouldnt sync properly with just one clock upgrade each, not sure why, (both clocks are set to 1 either way), and all routers have copied identical settings in the network controller from xnet.
I haven't been able to conclude a specific pattern to recreate this perfectly.. so far only happens with more than 5 routers operating on the same redstone signal. It's consistent with xnet and ender IO conduits, but inconsistent with rftools redstone transmission (happens sometimes but not everytime). has not happened with vanilla redstone for me so far.
Any other comments?
I was able to improvise in still automating my drawbridge using sticky pistons and a matching concealing block on the same redstone signal to force a block update on the routers that don't respond. with the sticky pistons it works everytime without fail.
Extruding
Retracting
Retracting: block active=false (others are active=true in same instance)
Retracting with a glass block that had just retracted on the sticky piston updating the block space directly above the router (block active=true)
Minecraft Version 1.12.2
Forge Version 14.23.5.2847
Mod Version 3.3.0-33
Describe your problem, including steps to reproduce it
When connected via xnet cables/connectors, some (not all) item routers do not get a block update when redstone signal is removed, and do not retract their blocks back into the router.. however, when a block is placed or broken directly adjacent to the routers that aren't responding, they update and will retract, (after redstone signal has already been removed and they didn't update). all routers have the same modules and upgrades: Extruder MK2, had camo upgrade but removed for screen shots, and 2 Clock upgrades because they wouldnt sync properly with just one clock upgrade each, not sure why, (both clocks are set to 1 either way), and all routers have copied identical settings in the network controller from xnet.
I haven't been able to conclude a specific pattern to recreate this perfectly.. so far only happens with more than 5 routers operating on the same redstone signal. It's consistent with xnet and ender IO conduits, but inconsistent with rftools redstone transmission (happens sometimes but not everytime). has not happened with vanilla redstone for me so far.
Any other comments?
I was able to improvise in still automating my drawbridge using sticky pistons and a matching concealing block on the same redstone signal to force a block update on the routers that don't respond. with the sticky pistons it works everytime without fail.
Extruding
Retracting
Retracting: block active=false (others are active=true in same instance)
Retracting with a glass block that had just retracted on the sticky piston updating the block space directly above the router (block active=true)