Jump to content

Recommended Posts

Posted

Hello all,

I'm trying to build a 4x4 door handled by a programmable rednet controller. The mechanics works, I got the right sequence from the controller, using lights for debugging, as well as the rednet meter. I must have done something wrong however because some of my pistons don't act as expected.

On one point (my debug point) a piston connected to the blue new assumes the same state as the lamp, which is also the correct state. On most other points (all I have tested) the piston will be extended, even though the lamp on the same net is dark and the rednet meter reads zero. (While typing this post some of the points actually changed behaviour...)

Any suggestion what I may have messed up in order to cause this? This is on Tekkit Server 1.0.6.

Best regards

mc.png

Posted

Any chance the block in question is directly in the path of a floodlight? It's been a while but I think I had very odd behavior for a piston due to a floodlight.

Posted

Thank you for your suggestion.

My only lights are the ones from the lux capacitor upgrade from the modular power suites mod. I did try to add and remove some of those lights, but it did not affect the piston behaviour for the faulty ones, nor the correct ones.

I was unaware of the flood light block, I shall have to try it out.

Posted

A couple of questions: if you remove and replace the faulty piston, does it auto-extend again on the same RedNet state? Did you try removing the piston and replacing it with something else that is redstone-activatable, like an illuminator? Did you also try to replace it with a VANILLA redstone-activatable block or tile entity? For instance, place a block there, force RedNet to connect to it, and place a redstone torch on it, which should invert the signal (if any).

I am just wondering if this is an issue with RedNet or the pistons themselves, because as you know, pistons can behave VERY weirdly, based on block updates. 99% of block update detectors are piston-driven.

Posted

I have tried to remove and replace the piston, and it acts the same after replacement. I also tried to remove and replace some of the rednet cables as well as change the orientation of the piston(through replacement). I have not tried any of the other suggestions yet, I will do that tonight and report my findings.

Thank you for the link to the block update detectors, I was not aware of this. I shall make sure to read it thoroughly.

Posted

I removed (other faulty) pistons adjacent to the piston under test (also faulty). This did not change the behaviour. I replaced it, with no change. I replaced the piston with a lamp and placed lamps connected to the same point. The position where the piston used to be behaves differently (see attached image). I initially thought this was a piston issue, but now Im not so sure.

I am not sure what you mean with the redstone torch and forced connect, how can that be achieved? I connected the rednet to the torch however, and it turned dark (see image).

Best regards.

mc2.png

mc3.png

Posted

I have a 2x3 piston door on Tekkit 1.1.5 that's doing something wonky as well.

Pistons with the following layout:

1  4

2  5

3  6

My behavior is even stranger than your seems to be. I have them all set to blue, hooked to a PRC in T Flip Flop mode. When triggered by a pressure plate on a rednet cable, Pistons 2, 3, and 5 behave as expected. Piston 6, however, only toggles when the pressure plate pops back up. Pistons 1 and 4 do absolutely nothing.

I'm pretty close to just scrapping it entirely and just using Reappearing Blocks even though they don't quite fit the aesthetic.

Posted

Pwert, is the rednet cable below the piston active? It could be leaking a signal into the piston through the cobblestone block. Rednet has a tendency to connect to regular blocks if something touching that block can accept a redstone signal. It won't always show that it is connecting to the block either.

Try moving the other rednet cable 1 block further away from your pistons and see if that has any effect.

Posted

jakalath,

excelent idea! Here is what I found:

The rednet cable you pointed out is below and to the right of the position at issue. The cable actually carries the same signals as seen on the picture (where we have this interesting behaviour). I disconnected this cable, and everything turned dark, as it should. Connecting the lamps through a more direct route to the PRC resulted in all of them still being off. Reconnecting the cable (thereby creating a loop) does not turn the light back on. However, if I restore the circuit to the original state, the one lamp (as in the image above) lights up again. Putting back the cable that created the loop will not turn off the light, only breaking the connection to the below right cable will do that.

It seems the rednet cables do have some issues in this regard. I shall have to rethink my mechanical design to facilitate a more sparse routing of the rednet cables as the current one requires cables to pass close to each other. I will report any additional findings on this for future reference. Thank you very much everyone.

Best regards.

Posted

Bah, silly me. I finally got your point, removing the cobblestone block from below the piston/lamp solves the problem. It doesnt need to be there, it's only a leftover build support.

Posted

Ok, so now my 4x4 door works. As it turned out removing the cobblestone did fix that one thing, but there were still issues of the same kind. In fact, some pistons behaved this way despite only being adjacent to other pistons on the same net, and the rednet cable. For me, the solution was to stop using the white net, as "false high" values only occured when white was high.

Posted

That actually makes a lot of sense, as if there are any unexpected (invisible) connections, like Jakalth described, they would default to white. So that might be a nice general fix.

Posted

Also found that if you link anything to retnet cables, using a single line of redstone, you can and usually do end up with residual signals in the redstone. For some reason redstone connected to rednet cable, never completely turns off. use a dirt block or cobblestone block as the connection between rednet and a redstone device(like say, a computer), if you can not connect it directly. 00Ducky found this fix actually.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...