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.
Editing v0.34 Talk:Lever
Jump to navigation
Jump to search
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
You are editing a page for an older version of Dwarf Fortress ("Main" is the current version, not "v0.34"). Please make sure you intend to do this. If you are here by mistake, see the current page instead.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| 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'. | |
| − | |||