Print

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

[Gag Halfrunt]

Is there any reliable way to set up a machinery that overseer command can trigger "instantly"?

I'd like my WidgetWobbler^TM to reliably start Wobbling its Widget promptly when *I* say, with delay time much shorter and more nearly constant than waiting for some dwarf or critter to get around to pulling a lever or tripping a switch.  For example, a big drawbridge could atom-smash (yawn) or launch (yay!) a bunch of (non-huge) enemies... if it can be triggered quickly while they're ON (or under) the bridge.

Mechanisms and switches can do wonderful things... if you're willing to wait for somebody to wander over and get things started.  Overseer whim can forbid or unlock a door or hatch instantly... but that doesn't have any useful effect until somebody wants to go through or around.

I realize response time could be much reduced most of the time by confining a dwarf near a lever.  Sometimes, though, that dwarf will take a nap or lunch break and response will be no better than usual; we'll have to wait for him to finish his nap or lunch, or for somebody to stroll over from East Anglia.  A pressure switch separated by a door from a farm animal isn't much better; they seem content to stand around waiting for the movement mood to strike.

Best I can come up with so far is to uncage a goblin at the end of a narrow hall behind a door, pressure switch, and cage trap:

wwwww
wgdpc
wwwww


Goblin prisoners seem pretty eager to run for the exit promptly when the door is unforbidden.  Seems a bit kludgy to rely on sentient behavioral quirks, and requires catching a suitable enemy.

Got any better ideas?

[Bumber]

IIRC, there was something involving cancelling a partially-built construction. Can't remember the details.

[Gag Halfrunt]

IIRC, there was something involving cancelling a partially-built construction. Can't remember the details.

The wiki says cancelling a partially-built construction can drop the building materials into open space beneath.
https://dwarffortresswiki.org/index.php/DF2014:Trap_design#Canceled_construction_deadfall

While that might be fun for observers below, I don't see how it can (directly) send a signal to activate a mechanism linkage.  That is, I don't think there's a way to park anything on the unfinished construction that can trigger a pressure plate below when the construction is cancelled.  Pressure plates don't respond to ordinary items like construction materials.

I suppose one could confine a critter atop a pressure plate in the drop zone.  The living creature holds the pressure plate ON until falling material turns him into a corpse and lets the plate toggle OFF.  While that might work (with some careful planning to avoid spurious triggers during setup and reset), to my taste killing a critter per shot seems wasteful and the initiation seems a bit exploity (emphasis my taste, which is more willing to accept the overseer's hand than an implementation convenience detail of letting works in progress hang mid-air)

[Gag Halfrunt]

Hmm... that wiki article does claim that cancelled construction is "the only overseer-triggered trap--it doesn't require dwarves to pull levers, enemies to cross pressure plates...".  The wiki might not be infallible, but it is the product of sharper minds than mine.

So I'm not gonna hold my breath.  Still... anybody got a better idea?

[PatrikLundell]

Using DFHack you can manually change the dump condition of track stops. That should allow you to cause them to dump magma and/or water to cause either direct damage effects or to trigger pressure plates set to trigger on the level of the appropriate fluid.

[Gag Halfrunt]

[HomerSimpson]

DOH!

[/HomerSimpson]

I knew that about track stops.  I've used that track stop behavior, mostly to fixup after bugged haul route loading^footnote.  Just never occurred to me to use it to dump water onto a switch.  Four years of college...wasted.

A nice benefit of this scheme is that it's simple to choose from ON vs OFF or momentary vs persistent behavior:
- Prompt ON or prompt OFF behavior determined by whether pre-dump level is within or outside switch level range
- Prompt momentary ON if there is adjacent space to drain dumped water away, prompt persistent ON if not
- Prompt persistent OFF if no adjacent drain space
- Prompt momentary OFF might be trickier; need to lower level back into ON range.  Linked drawbridge blocking drain space (possibly diagonal) might do it.

^footnote For some reason a route and stop intended only to dump minecarts brought up full of magma for use can get tangled up with instructions for another route and stop to load the emptied minecarts for travel back down to the filling station.  I think there may be an indexing problem when a erroneous stop (on an unrelated route) got deleted and fixed; I didn't report or search for the bug because I haven't tried hard enough to isolate the root cause nor demonstrate repeatably.  The Q&D workaround (and likely robust avoidance design) was to redirect dumpage to a new, distinct QSP stockpile.  Made my dozen-magma-loads-per-trip operation slightly more tedious, but not enough to rework the layout.

[PatrikLundell]

I assume you're not confusing an error with the dwarven stupidity of getting tired, drop the magma filled mine cart, and a moron decides to haul the cart to a stockpile instead of its destination (sometime the "place minecart" job beats the "haul to stockpile" one, and sometimes not)? In that case, the "haul to track stop" job picks it up from the stockpile (which may well be just beside the magma loading station, or further away from the destination).

Anyway, nice to hear you've got something to work with.

[Gag Halfrunt]

I assume you're not confusing an error with the dwarven stupidity of getting tired, drop the magma filled mine cart, and a moron decides to haul the cart to a stockpile instead of its destination (sometime the "place minecart" job beats the "haul to stockpile" one, and sometimes not)? In that case, the "haul to track stop" job picks it up from the stockpile (which may well be just beside the magma loading station, or further away from the destination).

No, I'm sure it was a hauling routes error, and I'm pretty sure it wasn't entirely mine.  Dwarves were perpetually reloading dumped iron minecarts back into the bronze minecart on the autodumping trackstop at a route stop with no loading instruction; intent was for the bronze minecart to deliver the iron minecarts QSP-style to be filled with magma or deliver their magma loads by unrelated routes.  The offending routes and stops were never intended to load anything; I had sister routes at each end (without track stops) to load the iron minecarts into the (reassigned) bronze minecart, to be taken on unassignment when loaded to a nearby bronze minecart stockpile, from which another bronze minecart stockpile at the far end could take with a wheelbarrow to speed the long commute between the shallow magma consuming level and the deep magma loading facility.

I suspect some sort of indexing error because I did make an erroneous hauling route stop designation.  I caught and corrected my error long before any minecarts were applied, but not before I'd designated a few more of the routes necessary to my scheme.  Somehow the loading instruction for the non-dumping route stop got applied to the non-loading route stop on the autodumping track stop.  It didn't show up on review of the hauling routes interface, though, and various combinations of respecifying route stop loading instructions didn't help (including adding the one I didn't want in hopes that it could be turned off for effect).

Anyway, nice to hear you've got something to work with.

I'm really embarassed that I needed your hint to realize DFHack could do make a trackstop do what I wanted by dumping liquid onto a pressure switch, with mind-numbing simplicity for a single-shot implementation.  Resetting such a simple system to fire again, though, seems to need (what I consider) too much tedious designating things for dwarves to do in their own sweet time, and keeping an eye on their progress to designate their next round of necessary tasks (e.g. refilling minecarts with water and getting them back on the trackstops).

I finally did figure out a not-too-complicated system for an automatically regenerating prompt trigger, with complementary make-before-break outputs, activated by DFHack turning on autodumping for one of a pair of portable drains.  When one portable drain draws down the level on its pressure switch, it activates a retracting+drawbridge pair to drop a measured aliquot of water to refill and reset the other.  With a little care to volume management its possible to keep the switches accessible to add new connections when in the ON or OFF state (basically, the drains live in 3-tile reservoirs beneath their 0-0 pressure switches; drainage leaves 3*2/7 space and 0/0 on the switch ON, and dropping measured 7/7 water fills to 1/7 on the switch OFF).

This system is a little exploity, relying on the portable drain trackstop exploit and the DFHack facility to change autodump behavior of a trackstop (including one in a portable drain).

I have no expertise with posting graphics here, so I'll just offer this crude elevation view of one cell of the needed pair:


   wDBd
     Sd
    GPGd


w water source (beside or above D)
D Drawbridge, on floor, linked to *other* cell pressure switch S
B retracting Bridge, on downstair or open space, linked to *other* cell pressure switch S
S pressure Switch, water level 0-0, on a carved down stair (dig stair, construct floor, build switch, remove floor)
P Portable drain (trackstop+minecart), built with autodump behavior off
G Wall grate (keeps falling water from shoving minecart off trackstop, maybe unnecessary)
d access door for maintenance or connections (adjacent P for easiest use, but this is 2D diagram)

Not shown:  levers linked to B,D to prime at startup (or after user error), water supply cutoff, the second cell (same as shown above)

After construction, toggle the priming levers a few times until water stands above both switches S.  NOTE that the switches will toggle OFF when their water level rises; if that matters, defer connection to target devices until later.

Then enable autodumping (any direction) on one portable drain P to lower water below its switch S.  That switch will toggle ON (again, if that matters to your target controlled device defer its connection until later.  That will also flip the other cell's bridges to drop more water onto its other switch S, but that won't hurt anything because it's already wet and OFF.  You can disable autodumping as soon as the bottom water level drops to its minimum 5/5.

Then, with first cell drain P autodumping disabled, enable autodumping on the other portable drain P to lower water below its switch S.  That switch will toggle ON (target device connections still deferred if it matters), and the first cell's bridges will drop 7 units of water to put 1/7 water above the first cell's switch S, toggling it OFF.

Now it's safe to connect target devices to either switch S; which depends on whether you want the first effective signal that device receives to be ON or OFF.  The downstairs allow connection access to switches S; 1/7 water won't stop dwarves from making connections, won't leak out when they come through the door, and won't evaporate while supported by 7/7 water in the tile below.

To toggle both outputs, deactivate (turn autodumping off) the portable drain P under 5/7 water and activate (turn autodumping on) the portable drain P under 7/7 water.  The activated drain will quickly suck the water off its switch S, toggling it from OFF to ON, and lower the level in the bottom reservoir to 3*5/7.  After a brief delay to flip the other cell's bridges, 7 units of water will fall to fill the 6 units of empty space in its bottom reservoir and leave 1/7 water atop that other switch S, toggling it from ON to OFF and automatically preparing the system for the overseer to toggle back at whim.

[Fleeting Frames]

There are couple of possible overseer-triggers, simplest that I know being cat under a hatch with pressure plate immediatelly out of it, but none are quite instant (without involving dfhack, anyhow).

In any case, I prefer ones that rely on the exploit where a raised bridge marked momentarily for deconstruction becomes statue-like for the purpose of letting objects pass.

This naturally suggest the simple cart on roller → bridge → pressure plate system for one-time triggers. I've used this with my repeaters to make them loop on season turn exactly by replacing the pressure plate with downramp for final cart, using medium speed rollers, and waiting exactly 8 steps after season change.

However, my favourite of the bunch can be diagrammed with single line: ╔╣╬╠=╣╬╠╝ - red and blue being both raising bridges with one raised while other is lowered, both linked to central plate. Not the most compact or efficient with walls considered, but relatively consistent 4-22 step reaction to start, while more compact ones I can do have up to 46 step wait. As a bonus, the central tile can also be L-corner if you need to turn part of it by 90⁰.

For your schematics, my preferred way to keep minecart on trackstop is to make all the tiles it can be moved to by fluid track/ramps that push it back on trackstop. Of course, it wont work for your pressure switch...

But the schematic is pretty clever.

Also, it might be that you could replace 1x1 retracting+raising bridge with 2x1 raising bridge, if the water being atomsmashed on retracting bridge tile doesn't harm the operation (it functions as drain, so...).

[Gag Halfrunt]

There are couple of possible overseer-triggers, simplest that I know being cat under a hatch with pressure plate immediatelly out of it, but none are quite instant (without involving dfhack, anyhow).

Yeah, DFHack really does uncork the bottle.  I guess one could just use teleport to move any critter onto or off a pressure plate.

In any case, I prefer ones that rely on the exploit where a raised bridge marked momentarily for deconstruction becomes statue-like for the purpose of letting objects pass.

I did not know that effect.  Presumably the actual in-universe switching gets done by redirecting a minecart that will be along promptly because it's running in a repeating circuit?

Also, it might be that you could replace 1x1 retracting+raising bridge with 2x1 raising bridge, if the water being atomsmashed on retracting bridge tile doesn't harm the operation (it functions as drain, so...).

Yes, that does work and would save two blocks and four mechanisms for the pressure plate linkages (plus more mechanisms for arming lever linkages).  I couldn't remember whether a raising drawbridge destroyed water above the whole bridge or just its hinged edge, the wiki didn't make it clear, and I just didn't feel like testing it when I knew the two-bridge implementation would give the measured aliquot I needed.

This sort of thing walks along the boundary between honest play and exploitive cheating.  One's personal palate determines how much exploit can be swallowed.

[Urist9876]

DFhack has a command to operate https://docs.dfhack.org/en/0.44.09-r1/docs/_auto/base.html#lever, no need to teleport.