v50 Steam/Premium information for editors
- 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.
This notice may be cached—the current version can be found here.
Difference between revisions of "v0.34 Talk:Lever"
Jump to navigation
Jump to search
(→Track stops: Clarified, deleted my previous possibly unhelpful comment) |
|||
| 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 | + | :::I tested the times for track stop activation and deactivation with a cart-triggered pressure plate. It was interesting that the 'on' signal was processed instantly (track stop 'disappeared') but the 'off' signal took forty steps to re-enable the stop (started the count upon reversal of the pressure plate). I put the numbers in and deleted the verify tag. |
| + | :::I deleted the 'note' under track stops because that's how all linkable objects apart from gear assemblies behave. Their different states are invariably linked to specific signals: for a door, 'on' signals are linked to the 'open' position. So a door receiving an 'on' signal will either open, or remain open. Only 'off' signals can switch doors from open to close, and an 'off' signal sent to a shut door will effect no change. Gear assemblies behave differently, but it's gear assemblies which are the exception, as mentioned in the article. | ||
Latest revision as of 15:00, 7 July 2013
Track stops[edit]
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 tested the times for track stop activation and deactivation with a cart-triggered pressure plate. It was interesting that the 'on' signal was processed instantly (track stop 'disappeared') but the 'off' signal took forty steps to re-enable the stop (started the count upon reversal of the pressure plate). I put the numbers in and deleted the verify tag.
- I deleted the 'note' under track stops because that's how all linkable objects apart from gear assemblies behave. Their different states are invariably linked to specific signals: for a door, 'on' signals are linked to the 'open' position. So a door receiving an 'on' signal will either open, or remain open. Only 'off' signals can switch doors from open to close, and an 'off' signal sent to a shut door will effect no change. Gear assemblies behave differently, but it's gear assemblies which are the exception, as mentioned in the article.
- 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