- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "v0.34 Talk:Lever"
(section, re) |
|||
Line 3: | Line 3: | ||
:The peculiar behaviour for state changes when signals are sent to track stops from multiple connected triggers (not a "toggle' or "OR" as with other triggerable items) was tested with four levers. Not tested with pressure plates. I has suspicions this might be a problem with gear assemblies as well, but I have confirmed that is '''not''' the case. I have not tested other triggerable items, although I suspect they've been in common use long enough that unexpected behaviour would have been noticed and documented by now. [[User:13thEssence|13thEssence]] 00:34, 22 February 2013 (UTC) | :The peculiar behaviour for state changes when signals are sent to track stops from multiple connected triggers (not a "toggle' or "OR" as with other triggerable items) was tested with four levers. Not tested with pressure plates. I has suspicions this might be a problem with gear assemblies as well, but I have confirmed that is '''not''' the case. I have not tested other triggerable items, although I suspect they've been in common use long enough that unexpected behaviour would have been noticed and documented by now. [[User:13thEssence|13thEssence]] 00:34, 22 February 2013 (UTC) | ||
::I think the easiest way to time steps is to use {{k|.}} (One step) and count the steps between a lever pull and when the target reacts. I haven't exactly tried this, but a way to tell when the pull occurs is watching the lever's task list, advancing one step until the "Pull lever" task disappears. Then move to the target and advance, one step at a time, until the action is triggered. [[Main:Macro|Macros]] would help - just record 10 .'s and play the macro 9 times (it's faster if you reduce the macro down to 10 <code>D_ONESTEP</code>'s). --{{User:Lethosor/sig}} 00:15, 1 March 2013 (UTC) | ::I think the easiest way to time steps is to use {{k|.}} (One step) and count the steps between a lever pull and when the target reacts. I haven't exactly tried this, but a way to tell when the pull occurs is watching the lever's task list, advancing one step until the "Pull lever" task disappears. Then move to the target and advance, one step at a time, until the action is triggered. [[Main:Macro|Macros]] would help - just record 10 .'s and play the macro 9 times (it's faster if you reduce the macro down to 10 <code>D_ONESTEP</code>'s). --{{User:Lethosor/sig}} 00:15, 1 March 2013 (UTC) | ||
+ | I do not understand how track stops are supposed to be unique. If you link a single door to multiple levers, the door will likewise only react to signals which alter its state: if you link it to six levers and set all six to 'on', the door will be open. If you now pull a single lever, the door will close, although five levers are still in the 'open' position. If you pull further levers to close, the door will not do a somersault flip, but simply stay closed. Switching a single lever back to 'open' will open the door again. I fail to see the difference between this behaviour and what's been described for track stops in the article, to the best of my knowledge they behave like every other 'barrier'. |
Revision as of 11:44, 6 July 2013
Track stops
I do not know how to time the trigger delay for track stops when they go from enabled to disabled. Both state changes need to be timed and added to the "Multiple Uses" section. 13thEssence 00:34, 22 February 2013 (UTC)
- The peculiar behaviour for state changes when signals are sent to track stops from multiple connected triggers (not a "toggle' or "OR" as with other triggerable items) was tested with four levers. Not tested with pressure plates. I has suspicions this might be a problem with gear assemblies as well, but I have confirmed that is not the case. I have not tested other triggerable items, although I suspect they've been in common use long enough that unexpected behaviour would have been noticed and documented by now. 13thEssence 00:34, 22 February 2013 (UTC)
- I think the easiest way to time steps is to use . (One step) and count the steps between a lever pull and when the target reacts. I haven't exactly tried this, but a way to tell when the pull occurs is watching the lever's task list, advancing one step until the "Pull lever" task disappears. Then move to the target and advance, one step at a time, until the action is triggered. Macros would help - just record 10 .'s and play the macro 9 times (it's faster if you reduce the macro down to 10
D_ONESTEP
's). --Lethosor (talk) 00:15, 1 March 2013 (UTC)
- I think the easiest way to time steps is to use . (One step) and count the steps between a lever pull and when the target reacts. I haven't exactly tried this, but a way to tell when the pull occurs is watching the lever's task list, advancing one step until the "Pull lever" task disappears. Then move to the target and advance, one step at a time, until the action is triggered. Macros would help - just record 10 .'s and play the macro 9 times (it's faster if you reduce the macro down to 10
I do not understand how track stops are supposed to be unique. If you link a single door to multiple levers, the door will likewise only react to signals which alter its state: if you link it to six levers and set all six to 'on', the door will be open. If you now pull a single lever, the door will close, although five levers are still in the 'open' position. If you pull further levers to close, the door will not do a somersault flip, but simply stay closed. Switching a single lever back to 'open' will open the door again. I fail to see the difference between this behaviour and what's been described for track stops in the article, to the best of my knowledge they behave like every other 'barrier'.