DrTarDIS
Eldrich Timelord
- Joined
- Jan 16, 2014
- Messages
- 1,114
- Reaction score
- 310
Hope that's clear to you. I'll re-explain the function in detail just in case. You can kinda see the compressed/installed version in the background above the various doors on deck 1
area trigger controller sends a "change" signal to any logic touching it
-> button touching AT Controller gets turned "on" whenever someone passes through trigger, and turns itself "off" half second later
-> button sends it's "on"(and half second later, "off") signal to the 1st delay, that delay sends to second delay, second delay sends to third delay, (and onward as many half seconds as you want the door to stay open)
-> the button, and all delay each sends it's "on" to the "or" block in turn
->"or" block sends it's "on" to the "not" (in this picture the "not" is "off"orange, but it SHOULD be blue, i didn't "boot up" the system by pressing the button before I took the capture, you should push the button after connecting everything)
->"not" block takes the "on" signal so goes "off", -> controled plexdoors "open"
(the "not" defaults to "off" when placed like all other logic, should be always "blue" / closed unless there have been area trigger activation for the circuit to work. when the circ is "primed" after first use it's fine, but will fail that use in order to "prime" the "not")
So, when someone goes through the area trigger, the button turns "on", which turns the "or" block "on", which turns the "not" block "off" and opens the plexdoors.
The "or" block stays "on" as long as any block feeding into it is "on", so your "delay-chain" determines how long the plexdoors stay "open"
If you want to use this for rail-doors you just harvest the "on" signal from 2 points
->You use the "on" from the "or" to activate the << >> "open"rail orientation
->You use the "on" from the "not" to activate the >><< "closed" rail orientation
(this version does not care about the "not" being "primed". it's "stay open" "or" timer is the same delay chain)
Clear enough?
AS for placement of the area triggers being controlled by the controller, it's good to make sure they cover at least 2 blockspaces away from the door, and built at least 2-3 high off the floor. This makes sure there's enough time for the game to realize it needs to use logic, and that players have enough time to realize the door is already open so they don't press "r" and trap themselves
(a crude ASCI top-down layout)
FTTTTF
TTTTTT
- -DD--
TTTTTT
FTTTTF
**protip for rail-doors: if you face the docker INTO your core on the door, and use picup (green) rails, you can save some space with the core "clipping through" the green rails. needs atleast a temporary "pickup point" to dock it to though.
Last edited:
