Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NOT gates become inactive when teleporting to region. #bug #64

Open
200found opened this issue Mar 10, 2013 · 3 comments
Open

NOT gates become inactive when teleporting to region. #bug #64

200found opened this issue Mar 10, 2013 · 3 comments

Comments

@200found
Copy link

I play on a server where i made a simple door trap. That is, when mobs come pounding at the door, I press a button that activates two sets of pistons, one that opens a pit next to the mob outside, and the other to push the mob down into a pit. Fun times.

All piston sets are remotely controlled by a redstonechip transmitter/receiver combo. The action is, one set pulls away blocks with a NOT gate, revealing a normally-concealed pit; the other set pushes the mob into the space where the pit now is (with a slight repeater delay).

The problem is that the NOT gate doesn't always maintain state when I teleport into the area (which is also my spawn point). When I die and respawn, it seems to be fine, but when my coordinate position just suddenly changes due to a spell (or end pearl), it goes wonky, and I must click the switch for the NOT-pull pistons, twice.

I can't easily provide a world file, but I can demonstrate the behavior on the server I play on.

--Brad

@socram8888
Copy link

Are you using Redstone torches or levers on the RSC outputs?
El 10/03/2013 02:43, "200found" [email protected] escribió:

I play on a server where i made a simple door trap. That is, when mobs
come pounding at the door, I press a button that activates two sets of
pistons, one that opens a pit next to the mob outside, and the other to
push the mob down into a pit. Fun times.

All piston sets are remotely controlled by a redstonechip
transmitter/receiver combo. The action is, one set pulls away blocks with a
NOT gate, revealing a normally-concealed pit; the other set pushes the mob
into the space where the pit now is (with a slight repeater delay).

The problem is that the NOT gate doesn't always maintain state when I
teleport into the area (which is also my spawn point). When I die and
respawn, it seems to be fine, but when my coordinate position just suddenly
changes due to a spell (or end pearl), it goes wonky, and I must click the
switch for the NOT-pull pistons, twice.

I can't easily provide a world file, but I can demonstrate the behavior on
the server I play on.

--Brad


Reply to this email directly or view it on GitHubhttps://github.com//issues/64
.

@200found
Copy link
Author

Just levers!

On Sun, Mar 10, 2013 at 12:56 AM, Marcos Vives Del Sol <
[email protected]> wrote:

Are you using Redstone torches or levers on the RSC outputs?
El 10/03/2013 02:43, "200found" [email protected] escribió:

I play on a server where i made a simple door trap. That is, when mobs
come pounding at the door, I press a button that activates two sets of
pistons, one that opens a pit next to the mob outside, and the other to
push the mob down into a pit. Fun times.

All piston sets are remotely controlled by a redstonechip
transmitter/receiver combo. The action is, one set pulls away blocks
with a
NOT gate, revealing a normally-concealed pit; the other set pushes the
mob
into the space where the pit now is (with a slight repeater delay).

The problem is that the NOT gate doesn't always maintain state when I
teleport into the area (which is also my spawn point). When I die and
respawn, it seems to be fine, but when my coordinate position just
suddenly
changes due to a spell (or end pearl), it goes wonky, and I must click
the
switch for the NOT-pull pistons, twice.

I can't easily provide a world file, but I can demonstrate the behavior
on
the server I play on.

--Brad


Reply to this email directly or view it on GitHub<
https://github.com/eisental/RedstoneChips/issues/64>
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-14678380
.

Brad Carps

@socram8888
Copy link

I don't have any clue then. I have been having issues with Redstone torches
not notifying nearby blocks when they change their status, but levers have
been working fine.
El 13/03/2013 06:55, "200found" [email protected] escribió:

Just levers!

On Sun, Mar 10, 2013 at 12:56 AM, Marcos Vives Del Sol <
[email protected]> wrote:

Are you using Redstone torches or levers on the RSC outputs?
El 10/03/2013 02:43, "200found" [email protected] escribió:

I play on a server where i made a simple door trap. That is, when mobs
come pounding at the door, I press a button that activates two sets of
pistons, one that opens a pit next to the mob outside, and the other
to
push the mob down into a pit. Fun times.

All piston sets are remotely controlled by a redstonechip
transmitter/receiver combo. The action is, one set pulls away blocks
with a
NOT gate, revealing a normally-concealed pit; the other set pushes the
mob
into the space where the pit now is (with a slight repeater delay).

The problem is that the NOT gate doesn't always maintain state when I
teleport into the area (which is also my spawn point). When I die and
respawn, it seems to be fine, but when my coordinate position just
suddenly
changes due to a spell (or end pearl), it goes wonky, and I must click
the
switch for the NOT-pull pistons, twice.

I can't easily provide a world file, but I can demonstrate the
behavior
on
the server I play on.

--Brad


Reply to this email directly or view it on GitHub<
https://github.com/eisental/RedstoneChips/issues/64>
.


Reply to this email directly or view it on GitHub<
https://github.com/eisental/RedstoneChips/issues/64#issuecomment-14678380>

.

Brad Carps


Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-14825878
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants