Print

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

[Steendor]

Objective
The idea is to control something based on a number of inputs.  Maybe you want to automatically flood a chamber when there are at least n victims present.  It's not too hard for small numbers, but it quickly gets out of hand when you have a lot of inputs.  I wanted a solution that was both easy to build and didn't require hundreds (or thousands) of mechanisms for a handful of inputs.

Problems and Inspiration
To know when any 2 of 3 inputs are on, you can use 3 2-input AND gates and 1 3-input OR gate.  If you want to know whether any 6 of 9 inputs are on---as I did---you can use 84 6-input AND gates and 1 84-input OR gate.  That's requires a bit more material and time than I wanted to invest.  With a bit of quick searching, I learned about sorting networks, which take a series of inputs 100110001 and output 000001111---that makes it easy to know how many inputs are on.  With a bit more searching, I found that a 9-input sorting network requires 25 sorting elements (each consisting of a 2-input AND gate and a 2-input OR gate), but the network itself is non-trivial.  I spent a few hours trying to plan a sorting network anyway, but I couldn't find a way around the fact that each stage of the network had to be physically separated from the following stage (invariably using fluid-sensing pressure plates).  I imagined a system that could act like a sorting network, by filling a vertical pit a bit at a time---but I couldn't figure out how to drain it properly.

Figuring that I would eventually have to design a massive system to make this work, I cast about for inspiration, and I found it:

Now since the windmill is providing 40 power, the fixed gear and pumps draw 25 power, we can have up to three additional gears connected and still have the pumps turning.  If four gears are engaged, we need 45 power.  There isn't enough power, so the pumps halt.  This is how we perform our overpopulation test - the pumps will halt if four or more cells are active.

Design

  ABCDE
LP*****O
  FGHI

A-I: gears linked to inputs
L: "gear resistor" or other mechanical load
P: power source
O: output
*: unlinked gear---merely transmits power

A power source, a rotation sensor, and a bunch of meshed gears.  It's very important that all of the input gears mesh with unlinked gears.  To control when it turns on and off, you have to do a little math.  Five unlinked gears use 25 power, a rotation sensor uses 10, and a water wheel uses 10.  That's 45 power needed if all the input gears are disengaged.  If you want to change states when 6 inputs are engaged, then we're up to 75 power.  A water wheel generates 100 power, so you would need to attach enough components to sap 26-30 power from the system.  (Less than 26, and you need 7 input gears to engage; more than 30, and you only need 5.)  The bare essentials (45) + the load (26-30) + the engaged gears (30) = 101-105 power needed, and the system is locked.  If any one input gear disengages, the usage drops below 100, and the system starts immediately.

The key here is that this gate can be easily expanded to any number of inputs.  (I am not responsible for any lag spikes if you decide to build one that covers an entire z-level...or three...or more.)  Building in two dimensions, you need an unlinked gear for every 2 inputs, but if you expand to three dimensions, you only need one for every 4 inputs.  Barring geometric restrictions, you can build a 100-input gate with 425 mechanisms (100 pressure plates, 100 linked gears, 200 linking mechanisms, and 25 unlinked gears) + materials for a power source and rotation sensor.  I don't even want to know how many mechanisms would be required for the other methods I considered...

Extra Credit
Now suppose you want to add some hysteresis to this system.  Maybe you want it to stop when at least 6 gears are engaged, and then not start until no more than 3 gears are engaged, and then not stop again until at least 6 gears are engaged.

  ABCDE
LP*****O
  FGHIZ
      *

Z: gear linked to the rotation sensor's output

The power usage rose over 100 when 6 gears were engaged, and we want it to stay over 100 until no more than 3 gears are engaged.  So, we need 6-3+1=2 more gears.  (Only one of them needs to be linked.)  This adds 10 power to the system, for a total of over 110.  It will drop below 100 when no more than 3 gears are engaged, and the system will start again.  The power usage will then drop by 10 once Z disengages again.

A note on "pre-toggled" gears: They don't have to be toggled in advance, unless you absolutely need it to work correctly the first time.  Whether or not you need to toggle any of these gears depends on the application.  For my prototype, I toggled only the Z gear.  (It works quite well, but I may decide to rebuild it, as I didn't properly account for the delays of the related pressure plates.)

Postscript
The fortress where I built this prototype is my longest-lasting fortress to date, and the first where I've safely managed magma.  After just barely recovering from a tantrum spiral, I've managed to maintain a fortress that's stable enough to do some real dwarven engineering.  I'm sure I'll find some !!FUN!! when I least expect it...

[Urist Da Vinci]

Are you making a trade depot that auto-processes merchants?

[Steendor]

Now that you mention it...

Anyway, my prototype controls floodgates to drain a water trap. Floodgates open, some water drains out, floodgates close, water spreads out and evaporates. I mentioned not properly accounting for pressure plate delays---I had to enlarge the evaporation area to make it work properly. Not the most efficient method for resetting a water trap, but I wanted to test it on something fairly innocuous.

I figure the most practical use for this would be what I mentioned---automatically setting off a trap once enough victims are present. (Your definition of trap and victim may vary.) However, I was hoping for more ideas, practical or not.

[Sphalerite]

It had occurred to me when I designed the Game of Life engine that the mechanism I discovered could be used for any arbitrary decision logic needing to trigger when a certain number of inputs were active.  I never did use it for anything else.  It could be used to trigger a trap when a certain number of enemies have entered, although you'll need to control for the fact that pressure plates take 100 cycles to reset.  If the pressure plates are all near each other, one creature could step on multiple plates and cause a false positive in the triggering logic.  It might be possible to use it as part of an overly elaborate automatic animal breeding engine, where a minimum population of adults are kept in breeding rooms and excess are sent to drop pits.