Jump to content

Pwent

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by Pwent

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
×
×
  • Create New...