- Joined
- May 18, 2015
- Messages
- 287
- Reaction score
- 165
Perhaps this counts as a bug, but it seems to me that the order in which Activation Modules(AM) get signaled on and off by a moving rail is inconsistent.
When a Rail Docker(RD) is moving along a rail, an adjacent AM only turns on when the RD fully "connects" to it. But when the RD starts to move off, the AM stays on until the RD is fully clear of the rail block.
This makes things like activating doors inconsistent without some convoluted logic to account for it.
Example:
The elevator arrives at a floor, and the doors immediately open. The elevator starts to move again, and the doors don't close until the lift is fully one block away.
Does anyone else think it would be more useful to have the AM deactivate as soon as the Rail Docker breaks full-face contact with the rail block?
If you really needed to know when the RD is fully clear, I imagine an OR-Signal between adjacent AMs on a section of rail would do the job.
When a Rail Docker(RD) is moving along a rail, an adjacent AM only turns on when the RD fully "connects" to it. But when the RD starts to move off, the AM stays on until the RD is fully clear of the rail block.
This makes things like activating doors inconsistent without some convoluted logic to account for it.
Example:
The elevator arrives at a floor, and the doors immediately open. The elevator starts to move again, and the doors don't close until the lift is fully one block away.
Does anyone else think it would be more useful to have the AM deactivate as soon as the Rail Docker breaks full-face contact with the rail block?
If you really needed to know when the RD is fully clear, I imagine an OR-Signal between adjacent AMs on a section of rail would do the job.
