Print

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

[geail]

Is the problem with the stockpiles. Do you have them set to give and take

I have it set up to take drinks and prepared meals from a general food stockpile which receives from everywhere and gives to some farming workshops.  My cart is full so I assume this point is working.
At the end, I want a quantum dump onto a single tile prepared meal and drink stockpile.  I have a track stop set up there to cause the immediate dump when the cart reaches the stop.  The cart is set to keep no items and leave immediately after being emptied.

The cart is full but has yet to leave the first station.

[cvar]

Was the guided cart being pushed up or down ramps? Ramps seem to behave weirdly with hauled stuffs in my fortresses, particularly going down it.

And did you set your dumping stop in the right direction? Sounds like it's not set to dump!

It's the ramp
Just had one of my marksdwarves get run over.  Only light bruising because his pet goose took the majority of the impact (broken leg)

No idea on the dumping stop, can't find a way to see what it's set too, I'll just dismantle it and rebuild it.  I do forget to set the dump direction a lot though, so probably it.

[AutomataKittay]

Was the guided cart being pushed up or down ramps? Ramps seem to behave weirdly with hauled stuffs in my fortresses, particularly going down it.

And did you set your dumping stop in the right direction? Sounds like it's not set to dump!

It's the ramp
Just had one of my marksdwarves get run over.  Only light bruising because his pet goose took the majority of the impact (broken leg)

No idea on the dumping stop, can't find a way to see what it's set too, I'll just dismantle it and rebuild it.  I do forget to set the dump direction a lot though, so probably it.

Glad you found it before someone got killed! Yeah, I've had a few dwarves get killed going down ramp with heavy stone being hauled somehow, I should try a few fortresses to work out how to reduce that, otherwise you could try to put restricted traffic on the ramp track.

And yeah, unfortunately, I don't know how to check dumping direction after it's built, it is pretty easily missed. I've had to rebuild a lot of track stops because I didn't noticed

[TBeholder]

Pressure plates can react on the weight of a minecart with everything inside. This allows to build a very simple "monkey trap".
Set the triggering threshold just below the minecart's full weight. When a thief takes an item from a cart (they'll rather steal the whole cart, but why not), the plate reacts, the room gets sealed. The critter can be fast, flying, weightless, trapavoid... if the trap is activated by the act of thievery itself, it remains reliable as long as the bait can't be instantly swapped for something else.

[cyberTripping]

Holy thread necro, Batman!

[Aseaheru]

Over a year...

[Larix]

It's appropriate to the topic and contributing something new to a mixed-bag collection thread, so no big deal.

Weight-sensitive plates with minecarts can be used in dwarven computing, and more practically are applicable in an automatic "launch when full enough" system: http://www.bay12forums.com/smf/index.php?topic=15096.msg4580050#msg4580050 , second half of the post.

To catch kobolds and other trapavoiders, i prefer the simple reverse water switch, simplified:

Code: [Select]

###
DWD
###
# = Wall
D = Door, unlocked and animal-passable
W = Water on water-sensitive pressure plate, set up so that the plate changes state when one or more units of water flow off the plate. This can easily be filled through a pond zone from above, although that may need added security against flyers.

_Anything_ that opens one of the doors will cause water to flow off the plate and trigger a change state - either switching the plate off when falling under the minimum setting (e.g. plate set to 6-7) or switching it on when falling under the maximum setting (e.g. plate set to 0-5). This catches absolutely everything apart from ghosts.

Of course, you could make a more immediate trigger-free minecart trap by putting a minecart on a roller directly behind a door. Units will not take account of the minecart when trying to path through it and will readily open the door and take a minecart to the face.

[4maskwolf]

I used to be a petty thief like you... but then I took a minecart to the face.

Sorry, I had to.

[TBeholder]

Weight-sensitive plates with minecarts [...] more practically are applicable in an automatic "launch when full enough" system:

To think about it, absolute weight threshold allows at least some fine-tuning simply via choosing the minecart by material density (oak 28 Urists, willow 16, etc).
A mechanical launch may need extra safety measures, though - dwarves doing "store item in a vehicle" visit the track tile itself.

To catch kobolds and other trapavoiders, i prefer the simple reverse water switch [...]
water-sensitive pressure plate, set up so that the plate changes state when one or more units of water flow off the plate. This can easily be filled through a pond zone from above, although that may need added security against flyers.

Security against flyers is 1 floor grate, but BUILDINGDESTROYER, of course, would need a water lock or a fortification under floor grate on the adjacent tile (hmm... "Dwarven Sink"  ?) - though greater water capacity would increase latency.

Of course, you could make a more immediate trigger-free minecart trap by putting a minecart on a roller directly behind a door. Units will not take account of the minecart when trying to path through it and will readily open the door and take a minecart to the face.

Simple and good. Needs testing for latency and whether the door can be closed again before the cart atually moved.
So what we have so far...

Trigger type	Trigger medium	Target's traits	Latency
basic	direct	no TRAPAVOID (or implied equivalents)	99
obstacle removal	minecart, liquid	BUILDINGDESTROYER CANOPENDOORS	99+?
tray weight	minecart	CURIOUSBEAST_EATER CURIOUSBEAST_GUZZLER CURIOUSBEAST_ITEM entity ITEM_THIEF	99?

Of course, if the locking mechanism is RS-trigger type rather than self-reversible, any of these can be combined with a lever for letting MISCHIEVOUS critters kindly trap themselves.

[TBeholder]

In other news: the derail-based speed limiter can be easily improved to 2x density.
On the left side is the original design. It's obvious that both crossings can be used for derailing check and you could inject minecarts counterclockwise from any place in "8", as long as carts are allowed to avoid the first stop if they don't derail. But then, if the north arc is not used before the first check, no reason to not have another stop there:

Code: [Select]

                 ↓            ↓
     OOOO     OOO║O        OOO║O
in →═╔═╗O     O╔S╗O        O╔S╗O
out←═╬═╝O    ←═╗═╝O       ←═╗═╝O
    O╚S╝O     O╚═╝═←       O╚S╝O
    OOOOO     O║OO         O║OOO
               ↑            ↑
It's faster and more precise, because it got less turns after the last stop than the classic system, which means less risk that a minecart's speed will be just within the narrow band allowing it to stop somewhere inside the 8-loop. Though if you really worry about this, it's probably better to either put rollers instead of corner tracks after each stop, or use the one-stop version with "lowest" roller in the other arc, depending on how much you're willing to bother with power transfer.

[Larix]

A very limited-use variant speed reduction method - the difference brake:

Code: [Select]

  ####  ####
  #╔╗#  #╔╗#
in=╬╝#  =╬M#
  #║##  #║##
  out

The "regulator" minecart sits on the NW track corner, spot marked 'M' to the right. A high-speed minecart enters the loop, collides with the regulator cart, the regulator cart goes around the loop and collides with the input minecart, pushing it off to the south.

The clincher is that the regulator cart is of a significantly different weight from the input cart. Heavier or lighter doesn't matter, only that there's a big difference in weight. An iron cart brakes an aluminium cart just as well as an aluminium cart brakes an iron cart.

You see, if carts of different weight collide, the output speed is reduced if a lighter cart bumps into a heavier one, but a heavy cart bumping into a light cart doesn't result in an increase in speed. So if you put two different-weight carts through a simple back-and-forth of collisions, the result is always a speed reduction.

Obviously, if both carts are of the same weight, the output speed will not be significantly reduced.

On the flip side, the whole thing is largely useless, because a derail-speed cart colliding with pretty much anything shotguns all of its contents. So this brake is only useful to reduce the speed of empty carts, unless you want to shotgun all your cargo into the speed regulator chamber for some reason.

PS: self-resetting design:

Code: [Select]

.#####
 #╔╗╗#
 #▲║║#
==╬=╝#
 #║###

The track ramp is NW, so probably an impulse ramp or somesuch. This setup requires the regulator cart to be the lighter one, because it needs to be fast enough to derail over the ramp to bump the input cart. It's then re-accelerated by the ramp and returns to its starting position.

PPS:

Well, i actually started thinking about this when considering a way to sort incoming minecarts into automatic launch pads, in such a way that the cart would enter the first "free" location and pass by occupied ones. To be launch-able, the pad must be either a roller or hatch cover (or bridge, if you like your automatic launches via haphazard cart-slinging), so cannot directly contain a pressure plate. Of course, a return path with pressure plate can still be built, or a return mechanism rigged to get a cart back on the move if it unsuccessfully tries to enter an already-occupied pad.

Fast response, complicated:

Code: [Select]

.   ║####        ║####
in==╚=║╗#    in==<<▼^#
    #╔╝║#        #╔╝║#
    #║╚╝#        #║╚╝#
    #║###        #║####

To the left, the pathing, to the right:
<< = 2 long roller pushing west, rerouting incoming cart when pad occupied
▼ = 1x1 roller pushing south, actual launch roller
^ = pressure plate linked to activate the rerouting roller

An incoming cart will either find a vacant slot, goes through the loop and sorts itself into the launch spot. Or it will find the slot occupied, in which case it will bump the cart found forward, through the loop. The occupancy cart will pass over the pressure plate, activating the reroute roller and sending the incoming cart off through the reroute branch to the north, while the occupancy cart returns to the launch pad. The actual launcher needs an initial crooked path like here to allow a proper bump-loop onto itself. The reroute roller must be at least two tiles long - 1x1 rollers cardinally adjacent will power each other, so activating a 1x1 reroute roller would _also_ activate the launch roller. This design has the advantage of automatically redirecting additional incoming carts and should be safe from misfunctions when carts try to enter in quick succession.

Slower, easier:

Code: [Select]

.   ║###        ║###
in==╚=║#    in=^<<▼#
     #║#         #║#

^ Pressure plate linked to _deactivate_ the reroute roller
<< reroute roller pushing west
▼ launch roller pushing south

This pretty much explains itself. The incoming cart deactivates the reroute roller upon arrival. If the slot is free, it passes over the inactive reroute roller and comes to rest in the launch slot. If the slot is occupied, the cart stops on the last tile of the reroute roller and stays there until the roller re-activates, sending it off to the next slot. If additional incoming carts arrive during the 100-step recovery period of the pressure plate, they'll expand the delay and may "clog up" the system by stacking themselves back until a cart permanently sits on the pressure plate and keeps the roller deactivated until you manually intervene and fix it.

If a level switch is acceptable, some rollers could be replaced with hatch covers (notably in the first case - instant reaction equals fast rerouting) or grates (second case - delayed opening of the grate agrees with the delay-dependent nature of that design).

[Larix]

Sort of necro to put it in an appropriate place:

I built the "reusable" regulator much too complicated - this track loop is totally adequate:

Code: [Select]


  ####
  #╔╗#
in═╬╝#
  #║##
  out

all that's needed is to use three instead of one regulator minecart:

Code: [Select]

  ####
  #MM#
in═╬M#
  #║##
  out

The to-regulate cart travels in on an eastern heading, bounces into the southeastern regulator minecart, the impulse passes through all three stationary minecarts in good Newton's cradle fashion and is passed back to the moving cart from the north, pushing it out to the south.

As mentioned earlier, an impulse passed from a lighter to a heavier cart results in reduced speed, but an impulse going from a heavier to a lighter cart only passes on the unchanged speed. Thus, if there are weight differences between moving and stationary cart, the result will always be reduced speed, and the reduction depends on the relative weights of the carts. I tried it out and a regulator loop loaded with three willow minecarts (15kg) results in distinctly different flight lengths when wooden carts of different weight are shot into it at extreme speeds. With very little effort, i could force different outputs for willow, highwood and tower-cap carts, i.e. three wooden carts that'd be indistinguishable by pressure plate could be sent on different paths.

[Larix]

Digging it up again:

quite early in the thread, there was a lot of speculation about how track ramps really work, and someone (i must be missing the proper search words, so can't find it) commented that a sort of elevator was possible by creating a line of one-direction track ramps, only connected "up". I finally went and tried this out, and the bug's still alive and well:

Code: [Select]


z123456     
 ▲▲▲▲▲▲          /# 6
 ╠╠╠╠╠╠         /#  5
               /#   4
              /#    3
             /#     2
            /#      1

There's wall to the north and south of the track. Each ramp is one level higher, going up towards the east. East-pointing dead ends work just as well, and will be required if there's no wall to the side of the track. A cart propelled by dwarven push will travel up (or down) all six levels, without notably changing speed. Curiously, enhancing the cart's speed via an impulse ramp before entering the slope breaks the upward capability, the cart will hiccup and stop three levels up, while a descending cart will go down just fine.

NB: a cart going _down_ such a track will not accelerate.

This suggests that the track here is not considered to be on ramp and thus applies no acceleration/deceleration. The reason is quite simple: the carved track has no downward connection. I've previously only observed it when looking for acceleration, but since deceleration is practically acceleration in the opposite direction, it makes sense that improper connections nix deceleration, too.

The case of the stopping enhanced-speed cart suggests that cart movement across such a slope is irregular and can fail. I have no good idea what governs it and at which speeds passage should be possible (and why). It's pretty slow but apparently very low-tech and reliable, not to mention that it's remarkably safe: dwarfs kept walking right over the moving cart without being harmed, thanks to its low speed.

[Larix]

Alternative (built and tested) design for a speed limiter - impulse ramp based.

?? Impulse ramps to _limit_ speed?? Yes, of course - ramps accelerate towards their down direction; if a cart moves over a ramp toward the "up" direction, that downward acceleration translates into deceleration. So what you do is take a plain old impulse ramp and install it _against_ the cart's movement direction:

Code: [Select]

  in
.║.
.║#
#╔╗        ╔╗
#▲╚═out   #╝╚
.╚╝#       ╚╝
.#..
          track

As long as the cart moves at above-derail speed, it derails over the impulse ramp, but loses ~5000 speed for every step it spends on the ramp (and another 4000 for every full cycle, due to the four corners). Once speed drops below the derail threshold, the cart tries to follow the track corner of the impulse ramp. If it's a usable ramp (with connected track on the level above), it leaves to the upper z-level; if the ramp exit is blocked, the cart bounces back, starts moving in reverse and leaves the circuit towards the east.

This is the smallest conceivable impulse-ramp-based speed limiter; for the proper effect, the ramp must replace a straight track tile.

PS: i tried out a design with two reverse ramps, using connected track on the level above to remove the sufficiently decelerated cart; that design is ride-safe. A dwarf rode a minecart at maximum ramp speed, and three maximum-friction track stops and seven rounds in the limiter loop got him to a safe movement speed, so he came to a soft stop at the end of the route.

[Sadrice]

for the proper effect, the ramp must replace a straight track tile.

What do you mean by this?  Do you mean that you must carve a NS track in the tile first before constructing the NW ramp?