Pwent Posted August 12, 2013 Posted August 12, 2013 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
weirleader Posted August 12, 2013 Posted August 12, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
Viktor_Berg Posted August 13, 2013 Posted August 13, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
PessimiStick Posted August 13, 2013 Posted August 13, 2013 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.
jakalth Posted August 13, 2013 Posted August 13, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
Pwent Posted August 13, 2013 Author Posted August 13, 2013 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.
weirleader Posted August 13, 2013 Posted August 13, 2013 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.
jakalth Posted August 13, 2013 Posted August 13, 2013 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.
Viktor_Berg Posted August 14, 2013 Posted August 14, 2013 Do not forget that you can force the rednet cables to disconnect from any blocks you do not want them to connect to, by using an omniwrench or a precision hammer.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now