Print

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

[Larix]

Absolutely. When building a contraption to _quickly_ shut a door, a degree of urgency is required. Other players may create urgency by murdering a dozen children and then trying to quickly atomsmash Urist McTantrumpants so she can't go berserk, i put adorable cats in danger of getting wet. Yes, i am a monster.

[Dorsidwarf]

I fear that the RSPCA might soon be surveying the OP's home for evidence of cat-based minecart atomic smashing machines.

[Mishrak]

Hopefully the OP has an atom smasher built to prevent just such an occasion.

And cats are always necessary.

[Scruffy]

And cats are always necessary.

No complex dwarven machinery is complete without atleast one cat (or potashmaker) getting injured during its activation.

[CapnUrist]

Dwarf Fortress: where the simplest answer is NEVER the answer.

[Larix]

I'm afraid that this probably _is_ the simplest way to produce a fast on-demand close signal.

Okay, the more appropriate approach would be to never really _need_ a fast on-demand close signal. Fair enough.

[Halceon]

Dwarf Fortress: where the simplest answer is NEVER the answer.

Well, you know. Picking the simplest answer is called Occam's Razor. Dwarves and razors get along notoriously poorly.

[Larix]

Shameless meganecro ahoy.

Stupid little tricks, Summer edition

Single-use latches

   

a) gear assembly that picks up a full windmill's worth of power after one off/on cycle.
- a pretty simple trick: if a windmill is built on unbroken floor above a pre-existing gear assembly, the assembly will not receive power from the mill. However, when the assembly is disengaged and re-engaged, power is transferred from the mill to the gearbox. The main downside is that it's almost certainly entirely useless, because further signals will still be able to disengage the gear assembly.

It's the thing in the middle, the gear assembly to the right.

Code: [Select]

-o-
___
_*_

windmill above, standing on solid floor (___), gear assembly underneath. If the assembly is built after the mill, it's powered from the start; if the assembly was built first, it will be unpowered initially, but becomes powered when it's disengaged/re-engaged once.

EDIT: well, it could be used as a "trigger once, always on" latch by putting up that gear as load to a powered machinery: upon building, it puts the machine over power limit and shuts it down. When the gear is disengaged, it no longer constitutes a load and the machinery works. When it re-engages, it now takes power from above - more than enough to compensate for its load, so the machine still works.

b) power trunk that can be perpetually _disabled_ with a single signal.
- potentially more interesting: the pump to the north is powered through a roller, transmitting power lengthwise (through the ends of the roller in line with the push direction). If the gear assembly powering that roller from the south is disengaged, the roller/pump assembly loses power, and power will not come back when the gear assembly re-engages. It's a "trigger once, forever off" switch.

Why does it work?

Rollers _can_ transmit power through their front and back ends, but only if they were _built_ to touch a proper machine component - axle, millstone, pump etc. If there was nothing at the end of the roller when it was built, that face of the roller won't transmit power. Removing a machine component that was touching the roller will also render the affected face non-transmissive. The tricky thing is that _engaged_ gear assemblies count as proper machine components, while _disengaged_ ones don't. Thus, a roller taking power from the lengthwise connected gear assembly will not only lose power when the gear assembly is disengaged, it'll lose transmissiveness on the face it was getting power from. When the gear assembly turns back on, it's touching an unreceptive roller face and can't provide power to it.

As a counter-example, there's another roller pointing west, taking power from the same gear assembly, also lengthwise, but with a one-tile axle between gearbox and roller face. That one can be switched on and off freely, because its "enabling" building is the axle, which remains a legitimate machine part and keeps the roller face receptive.

Code: [Select]

*RRRR - switches off when gearbox disengages, and stays off

*=RRR - switches off when gearbox disengages, switches on when it re-engages

c) minimal manual-reset minecart latch

A hatch.

O.k., it's a signal-operated hatch over an empty tile. On that hatch sits a minecart.
When the hatch opens, the cart falls through and lands on a cart-sensing pressure plate (on a tile of track). The plate switches on and output remains on indefinitely, no matter what happens to the input afterwards. To reset the latch, a dwarf must put the cart back on the hatch. Obviously, the cart should be forbidden when you want the output properly latched, otherwise dwarfs will autonomously return the cart to the hatch, or drag it to some stockpile, or decorate it.

d,e,f) power-on latch, power-off latch, power-to-signal converter without visibly moving carts

Conceptually, those are hilariously trivial, especially when made as manual-reset latches (i.e. need a dwarf to reset).

Code: [Select]

R^#

R = roller pushing east
^ = cart-sensing pressure plate
# = wall

That's a power-on latch. Power turns on, roller pushes cart east, cart stops on pressure plate. Power can turn back off again, output remains activated.

Code: [Select]

#^▲#     #══#     #^R#

▲ = ramp under closed ceiling, EW track
R = Roller pushing east

This is the power-off latch. As long as power remains on, the roller holds the cart on the ramp. When power turns off, the cart rolls down the ramp, onto the pressure plate, and stays there, regardless of later power on/off events. To build a roller on a ramp, you must first build an adjacent machine component that "supports" it (other roller, axle, gear assembly). Since a roller won't do you any good without something to provide power to it, that's no real issue, you just have to designate the buildings in the proper order.

And combining the two, what's seen on the picture in the centre-south, a power-to-signal converter:

Code: [Select]

#R^R#     #═^▲#

Both rollers are driven by the same power source, the only input consists of the presence or absence of power. When power is on, one cart is held up on the ramp, the other is right next to it, on top of the pressure plate. When power turns off, the cart from the ramp pushes the previous occupant off the pressure plate, onto the roller on flat track. The cart from the ramp now sits on the plate. When power turns back on again, the cart on the flat-track roller first pushes the other cart off the plate and onto the ramp (where it's held by the ramp roller), then settles onto the plate.  The carts must be of different weight and the pressure plate must be calibrated to respond to one cart but not the other.

I'm using a silver cart on the flat-track roller and a lead cart on the ramp, with a pressure plate responding to 450+ weight, i.e. the lead cart. Output is on when power is off, off when power is on. Which makes it a power-to-signal _inverter_, if you will; something that's not exactly easy to do with minecarts. Using more flat track between the two rollers, it could have both a "power-on" and "power-off" positive signal, it could even be made to send a complete signal _cycle_ everytime power status changes.

Single-use simple blast door

This is based on a little but important note on the wiki, regarding floodgates. Paraphrased, when an obstacle is in a floodgate's tile when it tries to close, it cannot shut, but the "close" signal is preserved and the floodgate instantly shuts when the obstacle is gone.

What's the easiest way to get a controllable obstacle into a floodgate that can also be removed on demand? Minecarts, of course.

     

Two minecarts, next to each other. The right one sits in a floodgate that has received a close signal (days ago), the left one sits on top of an east-pushing roller. The gearbox powering the roller is controlled by a water-sensing plate. The plate is visible in the right-hand picture.



Sevens steps after water touched the pressure plate, both carts have been pushed through the floodgate's tile and the gate has shut. The obvious weakness is that both carts are basically lost (caught in a soon-to-be-flooded corridor). There was actually a surprising little misfunction - i've had directly adjacent carts push the gate-blocking carts _and_ have the gate slam shut before the pushing cart got into the door. This time, the pushing cart managed to sneak into the floodgate's tile before it could shut. Thus, a safer and less cart-consuming setup would have one tile of "buffer" between the roller and the floodgate, so the pushing cart would stop on the tile before the gate and wouldn't be caught behind the shut gate. Slightly slower than the two-step shutting possible with adjacent carts, but a floodgate shutting five steps after the input signal triggers should be sufficient for most cases.

Single-use (or few-use) magma valves



Magma has flown in, but is not yet admitted to the northern channels. The doors that block advancement are made from gypsum (right), diorite (middle) and ... birch wood (left). Yes, a wooden door can hold back magma. After a few hundred steps of keeping the doors open (and then sending a close signal again) things look a bit differently:



A loose (and soon melting) mechanism and some smoke to the left, nothing visible to the right, a still intact diorite door in the middle. I'm not sure, but doors seem to cool down very slowly. The wooden door eventually burst into flames but was mostly destroyed by that point already - heat damage strikes long before the ignition point. The gypsum door just melted after a few hundred steps. The diorite door itself stayed intact for quite a while, but eventually the claystone mechanism operating it melted and the door turned into a puddle soon after. It took several days.

I mainly use these things when i'm expanding magma reservoirs and don't care about later re-partitioning - just lever the door open when ready to take on more magma, the heat will cleanly remove door and mechanism.

Possibly fastest safe up/down travel

I had fiddled with checkpoint effects to get carts up/down z-levels. I've taken to regularly using ramps that move carts up at a rate of one z-level per step. But with sufficient speed, two z-levels per step are possible. Template design:

Code: [Select]

###     ###     ###     ###     ###     ###     #.#     #.#
▼▲#     ▼▲#     ▼▲#     ▼▲#     ▼▲#     ▼▲#     ▼▲#     ▼▲#
###     ###     #.#     #.#     ###     ###     ###     ###
z+0     z+1     z+2     z+3     z+4     z+5     z+6     z+7
###     ###     ###     ###     ###     ###     #.#     #.#
▼═#     ▼═#     ▼╔#     ▼╔#     ▼═#     ▼═#     ▼╚#     ▼╚#
###     ###     #.#     #.#     ###     ###     ###     ###


Carts going up at sufficient speed (substantial speed, something like 160 000 at the very least) are on a checkpoint on tile/level z+2, z+4 and z+6, because ramp slant changes from w to s on z+2, from s to w on z+4 and from w to n on z+6. On those tiles, the cart spends exactly one step and gets teleported to the very end of the tile upon entering. On the next step, the cart moves through the following same-slant ramp tile. Since its speed is over 140 000, it moves just more than one full ramp tile, so gets directly to the next checkpoint (and again only stops at the very end of that tile, thanks to the checkpoint effect).

The result is that a sufficiently fast cart can move _two_ tiles every step, which means two z-levels per step on actual up/down ramps. Since it's just jumping from one checkpoint to the next all the time, speed remains largely unchanged, and the actual distance covered is higher than the standard max speed reachable by ramps - at a limit of 270 000, that's "only" about 1,93 tiles/zlevels per step, and only sustainable when going down. On my test rig, i have a pair of long ramps without bends going down 64 zlevels. One of them plain ramps, the other 20 levels of straight ramps (to pick up sufficient speed) and then 44 zlevels of double-spaced checkpoint ramps. Both carts get dropped from hatches by the same signal and remain in lockstep on the first 22 ramps. The checkpoint cart takes 66 steps to reach the bottom, the straight-ramp cart 73. With a slightly untidy setup, i also spliced off a path at the point of change from straight ramps to checkpoints and put that through some more double-spaced checkpoints. That gives a not properly optimised upwards path, covering 69 zlevels, but with three single-z moves. After speeding the cart up to ~200 000, it goes up the 69 zlevels in 36 steps, losing almost no speed. I've certified it as ride-safe on the upward path, making my herbalist probably the fastest-rising dwarf to date.

PS: i cleaned up the upward path to be up to spec and it works perfectly - counting the upward journey only (i.e. from the moment z+21 is left to the moment z+91 is reached), the cart now takes exactly 35 steps to travel up 70 zlevels, a flat two levels per step. The record for fastest-rising dwarf is now held by Meng Datanrur, beekeeper.
PPS: i haven't tried it, but even faster up/down speeds should be possible with transterminal/supersonic carts - 15 flat tiles per step should translate to 10-11 ramps and thus 10-11 zlevels traversible per step. That's significantly faster than the upward speed reachable by a ballistic shot, where the vertical component appears to be 1/2 "floor speed", i.e. 7-8 zlevels per step.
PPPS: a quick test in 0.34.11 says double-spaced checkpoint ramps and straight ramps both allow a faster vertical movement than free fall. Strange but true - free fall appears to max out at a speed of 9/5 z per step, while straight ramps can achieve a bit over 1,9 and double-step checkpoints precisely 2. The dropped cart fell 126 levels in 98 steps, and from step 55/level 48 all the way to step 98/level 126 the movement pattern stayed the same - four steps falling two z per step, one step falling only one z. That wasn't enough speed to cause more than a broken leg and bruised spleen to the wild boar on which it landed (but it was only a wooden cart). Oh, and free fall isn't safe for riders and only works in one direction
Incidentally, this demonstrates that the basic game tile is internally really handled as being 2x2x3 metres, i.e. 3 high and 2 long/wide. In game units, that means it's 100.000 units wide/long and 150.000 high: terminal velocity is 270.000, which computes to 2,7 tiles lenghtwise but only 1,8 by height. Falling items should thus experience the same acceleration as carts on ramps, namely 4900 speed per step. In the same vein, carts on a ballistic trajectory should have the same vertical as horizontal speed. Lower effective vertical speed (measured in zlvl/step) is due to uneven side lengths of the basic map cell.

[hops]

Here I am, about to descend upon the poor fool who hath defiled this thread, only to find that it is an update.

[Loud Whispers]

The more I read this thread the better it gets.