Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lucusLoC]

i was just posting in another thread about multi position levers, and decided to search  the forum for suggestions related to it. surprisingly i did not find anything. in the interest of getting it down in writing here it is.

all levers should be multi-position levers. when constructing a lever you would make it out of X amount of mechanisms, one for each active state. for example, a single mechanism lever would have one active state, and would act like levers currently do, an on and an off. a 2 mechanism lever would have 2 active states, an all off state, and an all on state (four total states). this could act like the toggle switch that everyone keeps asking for. 3 mechanisms would have 3 active states, and all off and an all on. each active state would be an attachment point for things, with attachment points acting like current levers do (i.e. when one bridge attached to that point is up, all bridges attached to that point are up).

when attaching things to the lever it would be important for a player to attach it to the correct position, but it would allow much easier control of complex mechanisms. this would of course have to coincide with more detail of what was attached and what state it activates on.

i think this would allow toady to retain the old lever code, it would just require him to repackage it into a new lever building.

(if this has been sugested before pleas use your superior search-fu and post a linky here.)

EDIT:

reading lots of other threads about this.

1. re: allowing levers to link to other levers, and power to levers.

when a lever gets a signal from another lever or power source, it increments its state by one, to the next available state. available states can be selected by players, so a 3 position lever with state all off, 1 and 3 selected would cycle, in order, between those states. position 2 and all on would have to be manually set by a dorf. a signal is measured by a positive change in state, from off to on, and only one shift is allowed per state change. so a lever would only change state once when power goes from off to on, or when its controlling lever attachment goes from off to on.

2. allowing multiple positons to be choosen.

if a player select an option to make the lever a single-pull, multi-throw lever they can select multiple positions to be on at the same time. each additional on state would require an extra mechanism to be available. for example, a lever with 5 positions would require 5 mechanisms normally. i you want to make any 2 of those positions active at the same time that would require 6 mechanisms, any 3 on simultaneously would require 7 mechanisms, etc. this should also invalidate the above all on state, so that a "all on state" for a five position lever (6 positions including "all off") would require 9 mechanisms. to mesh this with the above point players should be able to designate "virtual" positions to be cycled though, with their corresponding on states designated there. for balance reasons i would have each new virtual position also require a mechanism.

[Silverionmox]

We could let mechanics adapt gear assemblies to act like logic gates. You could reach any level of complexity by combining those, and when it's finished you're rewarded with marvelous rooms full of turning gears and rattling chains.

Specific things like portcullises or floodgates could be built so that they need 7 or so steps until they are pulled up (or raised up from below, respectively) completely. For those cases you would either build machinery that gives 7 impulses when a single lever is pulled, or you would just queue the order "pull lever: 7".

[winner]

If I'm understanding you right  there are three potential commands for each lever state.
on, off, increment (and possibly decrement).

When making a lever you choose what command each state gives out.
When attaching to a lever you choose which state you attach to.

'off' commands it's subordinates to go to their first state?
'on' commands it's subordinates to go to their second state?
'increment' commands it's subordinates to go to their next state?


What I would do is have an 'off' 'incr' and 'decr' and allow multiple commands to be given per state. So to turn something on I would make that state say, 'off', 'incr'.

[Hortun]

I guess you could make a switchbox or control station construction and have all of your mechanical linkings and other levers direct to that. Then you could select which device you would like to operate, and then which position to place it in. Might be simpler, but I don't know if that's too complex for dwarven mechanics.

[lucusLoC]

We could let mechanics adapt gear assemblies to act like logic gates. You could reach any level of complexity by combining those, and when it's finished you're rewarded with marvelous rooms full of turning gears and rattling chains.

Specific things like portcullises or floodgates could be built so that they need 7 or so steps until they are pulled up (or raised up from below, respectively) completely. For those cases you would either build machinery that gives 7 impulses when a single lever is pulled, or you would just queue the order "pull lever: 7".

i am not sure i completely understand your first suggestion, but the main idea is to make is so the old lever code does not have to be redone. if you change the lever code you have to change all the building code too. with my suggestion you just repackage the old lever code and the building code stays the same. you still get pretty good control, and you can still build logic gates out of levers, but the buildings themselves don't understand, since they behave  exactly as the do now (i.e. on or off, not toggling).

i do understand your point about having a specific building act like a lever changing states, and that should certainly be possible as long as you get to set what states it should change to. eventually Toady could update all buildings to have multiple states like levers, and it could be done on an as needed basis, but at that point we will have to be able to dictate how many on pulses a position should send when it is activated (activating a position would send X on pulses and end on on, deactivating would send y on pulses and end on off. this would allow a building to cycle though its states while remaining compatible with old on/off buildings. for this to work you would have to be able to set a lever position from "on" to "on" and "off" to "off", thus resending the pulses without actually turning switching its state first. this would also have to be a valid virtual state e.g. virtual state 1; position 1: on, virtual state 2; position 1: on)

all this is starting to make the mechanics job sound like an actual mechanics job, instead of just a glorified craftsdwarf :-)

keep in mind the idea her is not to rewrite code, but build on it without replacing it. backwards compatibility with old states is a must.

If I'm understanding you right  there are three potential commands for each lever state.
on, off, increment (and possibly decrement).

When making a lever you choose what command each state gives out.
When attaching to a lever you choose which state you attach to.

'off' commands it's subordinates to go to their first state?
'on' commands it's subordinates to go to their second state?
'increment' commands it's subordinates to go to their next state?


What I would do is have an 'off' 'incr' and 'decr' and allow multiple commands to be given per state. So to turn something on I would make that state say, 'off', 'incr'.

no, there is only two states possible per position, on and off. when a lever gets an "on" state it increments its current state by one, when it gets an "off" state it does nothing. there is no provision for decrementing. this preserves compatibility with the old buildings.

Edited for clarity

[Silverionmox]

all this is starting to make the mechanics job sound like an actual mechanics job, instead of just a glorified craftsdwarf :-)

keep in mind the idea her is not to rewrite code, but build on it without replacing it. backwards compatibility with old states is a must.

I completely agree. I started from retaining the lever code (a lever gives one pulse) and adapting some buildings to it. That way, the levers stay the same and buildings that don't need incremental treatment stay as they are. Only the few special cases where increments matter get a few extra specific rules:

 - a portcullis would be raised 1/7 with each pulse from a lever, requiring a dwarf to pull the lever 7 times to retract it entirely. Presumably, another lever would need only need to give a single pulse to let it drop again. You need two levers that way, but get much finer control and cannot open a portcullis at the wrong time by accidentally giving one pull command too few on the controlling lever.

 - Bridges would work similar as portcullises: x pulses (number depending on size) to crank them up, but only one to let them loose and fall down.

 - For floodgates, two levers would be needed as well, but they would both change the state only by a single 1/7 increment up or down, depending. When connecting the lever to such buildings, the player would have to indicate whether that connection should give "open" or "close" pulses.

That way, the system stays binary and therefore simple. Additionally, logic gates and all the know-how that exists for them can be applied into DF. (Introducing numeric values can be done by simply adapting the number of pulls on the lever. We should be able to command eg. "pull lever*7" on a lever, of course, so it's treated like a single job and the dwarf doesn't run off to sleep when the lever has given three pulses, releasing the magma into the dining room instead of in the moat.)

[lucusLoC]

 - a portcullis would be raised 1/7 with each pulse from a lever, requiring a dwarf to pull the lever 7 times to retract it entirely. Presumably, another lever would need only need to give a single pulse to let it drop again. You need two levers that way, but get much finer control and cannot open a portcullis at the wrong time by accidentally giving one pull command too few on the controlling lever.

 - Bridges would work similar as portcullises: x pulses (number depending on size) to crank them up, but only one to let them loose and fall down.

 - For floodgates, two levers would be needed as well, but they would both change the state only by a single 1/7 increment up or down, depending. When connecting the lever to such buildings, the player would have to indicate whether that connection should give "open" or "close" pulses.

i do have a couple of issues with this:

1. the states should not be a requirement, if the player only needs 2 of the states let it be specified. there is no need for a bridges to have 7 states if it really only needs to be up and down. what you seem to be suggesting is to use levers as a surrogate winch. weather or not you need to attach power to a bridge and how that is done should remain independent from the control of said bridge.

2. if you are custom designing a building then you can custom design its behavior from scratch. for your floodgate example i would have the on pulses increment the level. the behavior of the building would be as follows:

and off pulse sets the level to 0 or all the way open
each pulse raises its level by one, up to a total of 7. all additional on pulses are ignored. any off pulse sets the level back to 0.

now here is the issue, if a player knows he only needs all the way open and all the way closed he can specify that one on pulse sets the building to option 7, and all other additional on pulses will be ignored since they are redundant. this will give us behavior like out current floodgates, and control is maintained with only one lever.

all buildings should behave like this, to help maintain compatibility.

also do relies that these pulses are actual a series of off/on or on/off pulses that occur in a single tick, and end in the appropriate state. that way old buildings do not change state, while new non binary buildings will have to be able to count these pulses so they know what state they should be in.

[Silverionmox]

I agree with the customizability. The problem with specifying the number of states as needed is that levers that function differently still seem to be the same. I would prefer to keep the different smallest parts functioning the same everywhere, and let the player enhance their functioning by combining them in different ways.

I feel that the standard portcullises, bridges etc. are heavy stuff that's not going to zip up with just one flick of a lever without additional machinery with counterweights etc. (Additionally, the floodgate needs to be watertight and therefore has to slide to another position step-by-step instead of falling shut.) The fortress entrance is always a weak spot in the defenses, and it wouldn't hurt to let it require some effort on behalf on the player to find a good combination of defensibility and economical practicality. So personally I think that that counterweight machinery ought to be set up by the player rather than being assumed to be included with a simple lever.

[lucusLoC]

that is perfectly fine, and i would not be opposed to a separate winch and/or counterweight machine to run things like manual bridges and such. in that case i could understand the lever only being required for control if the winch was powered, otherwise control of the building would be dictated from the winch, and dorfpower would get the job done in however long it took. in the case of a powered winch you may even wish to have the lever linked to the winch instead of the bridge, but that really is all about interface and balance, and has nothing to do with how levers function.

it will be important to be able to specify what state we want a building to go to per pulse if we ever get other control structure like water level floats and such.

the main idea behind the functionality i propose is that multi-state buildings can have their selectable states altered just like multi-state levers. with a 5 position lever you can select only position 1 and 5 as its available states, and a single pulse will increment from 1 to 5, skipping the inactive intermediate states. there is no reason that that functinality should not be extended to buildings.

i think for consistencies sake that levers should also only increment to their highest active state and also ignore all extra on pulses, and that pulses should always be counted from 0 (in other words a tick always starts at 0 and increments from there, so pulses in separate ticks are not additive)

does that address your concerns? if not can you rehash your first paragraph, as i am not 100% sure i understand what your are saying.

[lucusLoC]

i am rereading things and i think i am getting into an inconsistent state. let me start from the beginning.

we start from the assumption the buildings can have only one lever linked to them at one time (or in this case one state on one lever). we also assume that a state can only be on or off. that works fine for 2 position buildings, but how do we control multi position buildings with this, and how can that be automated (like having levers linked to levers)?

we will need to make a virtual state for every position we want the building to be in. for each virtual state the player can dictate how many on pulses to send for each active state, always ending in "on."

there is no such thing as "off" pulses, as i mentioned previously.

[eerr]

could you have misspelled that title any worse?

[lucusLoC]

no? (fixing now)

[Silverionmox]

i am rereading things and i think i am getting into an inconsistent state. let me start from the beginning.

we start from the assumption the buildings can have only one lever linked to them at one time (or in this case one state on one lever). we also assume that a state can only be on or off. that works fine for 2 position buildings, but how do we control multi position buildings with this, and how can that be automated (like having levers linked to levers)?

we will need to make a virtual state for every position we want the building to be in. for each virtual state the player can dictate how many on pulses to send for each active state, always ending in "on."

there is no such thing as "off" pulses, as i mentioned previously.

AFAI can see there's no reason to forbid one lever to send a signal to several buildings, or one building to receive a signal from different levers. The only disadvantage is that several levers to the same contraption can be in different states. To address that, I'd say that there can be two types of connection between levers and buildings:

- simple: exclusive (one building, one lever), and the state of the lever and the building are always
the same (0 or 1, off or on, up or down).

- advanced: multiple connections possible, for output as well as input. Levers (or other input devices) are connected either to the "on" or "off" position. Each signal to the on position increments the state with 1, each signal to the off position decrements it with 1. Since most output devices will just have a 0 and 1 state, that's simple enough: pull the off lever to stop, pull the on lever to start.
Buildings with more states just require more pulses to reach the higher states. If you want to do it in one go, just connect that trigger with a few gear assemblies and connect those in turn with the on position of the building.

Some of the confusion will probably stem from my keeping other input devices in mind (pressure plates, mills, etc.) that give on but no off pulses, while levers have an on ànd off position.

Another consideration: heavier buildings (bridges etc.) might require more power per pulse, necessitating hooking up a mill or counterweight to deliver the pulses if speed is desired.