Print

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

[Sphalerite]

Was it this one?

http://www.bay12forums.com/smf/index.php?topic=42111.msg769338#msg769338

[Kanddak]

See Sphalerite's bridge research thread at: http://www.bay12forums.com/smf/index.php?topic=42111.0 (beaten to it while typing)

Rayc, you sound a little confused about the difference between retracting bridges and drawbridges. Your original stone crusher flung stones instead of crushing them because you built a retracting bridge, but you talked about "how an open bridge turns into a wall" which is a drawbridge rule.

[Sphalerite]

The challenge with trying to use bridges as a conveyor is that the direction which objects are thrown is completely random.  Objects which are on a retracting bridge when it retracts, or which are resting on the space the bridge extends into when it extends, will become airborne and will move until they either hit a solid object or have moved some distance away.  Objects can be thrown up to 3 tiles away X,Y, and Z, in any direction.  The direction they travel seems to have nothing whatsoever to do with the shape or size of the bridge.  You can use walls or buildings around the bridges to stop them from moving in directions you don't want them to, but you can't really channel them as such.  Raising drawbridges throw objects randomly up to 11 tiles away, except for objects which are on the side of the bridge that turns into a wall, which are atomsmashed.  Lowering drawbridges of course atomsmash everything in the area they lower into.

In my 40d fortress Pagedslipped I built a conveyor belt out of retracting bridges that looked as follows from the side:

Code: [Select]

................................
.......B.......B.......B.......B
......BW......BW......BW......BW
.....BWW.....BWW.....BWW.....BWW
....BWWW....BWWW....BWWW....BWWW
BBBBWWWWBBBBWWWWBBBBWWWWBBBBWWWW
-> objects move left to right ->

where every . is open space, W is a wall, and B is a retracting bridge on solid floor attached to a water-powered fast repeater.  Every 100 ticks every bridge in the device would retract or extend.  Invaders would fall onto the array from a great height, splattering body parts and invader gear on the bridges.  Each time the bridges extended or retracted all the objects would fly around randomly.   Objects in the array would mostly bounce around in the flat parts, but eventually after enough random movement some would walk up the slope to the right of each section, and fall over the peaks into the next flat section.  Because of the way the array was built, objects could not move backwards towards the left, and gradually would all be moved towards the right, to a safe collection area inside the fortress.

This conveyor belt mechanism worked.  It also took forever to build, was very slow (objects could bounce around inside it for years before reaching the end) and causes a massive FPS hit every 100 cycles from all the objects flying around.

There is a trick I considered but haven't tried yet that could be used to make it more efficient.  It turns out that it is actually possible to build doors floating in empty space.  Well, you can't actually build a door over empty space, but what you can do is construct a wall, then build a door on top of that wall, and then remove the wall.  This will leave the door floating in empty space.  At least, it did in 40d.  I haven't tried it in DF2010 yet.

So in theory you could build a mechanism as such:

Code: [Select]

WWWDB
WWDBW
WDBWW
DBWWW

where each D is a door floating over an open space, and each B is a retracting bridge.  If you open and close the doors and trigger the bridges in the right sequence, you'd get a system that pumps objects up the steps and doesn't let them fall backwards.  Objects can't get stuck in the doors, because each door is built over open space so any objects that would be in the door just fall onto the bridge below.  The water logic to run the sequence automatically will be complicated.  I'm not sure if there's any actual benefit from the device, either - I suspect that once you've got it running it would have been less work just to use an army of haulers - but the same can be said for many things I install in my fortresses.

[expwnent]

Why have them go up so many z-levels before the fall? Why not just use 2 z-levels and have more bridgeapult ramps? Something like

Code: [Select]

.......
.......
.B.B.B.
BWBWBW.
-> objects move left to right ->

My main idea is that if you have more places where the stuff is prevented from going backwards, it'll go forward faster.

[numerobis]

Brilliant!

You'll need at least 3 levels to get a ratcheting effect.

Code: [Select]

......
..B..B
.BW.BW
BWWBWWOtherwise the setup is symmetric, so there won't be a preferred direction of travel.

[expwnent]

Oh, ok. But 3 is still less than 4. And under the random walk model, it'll take exponentially more time the longer the ramp sections are, so 3 instead of 4 might help speed considerably.

Furthermore, if you really wanted to, you could set up independent clocks for different bridges to spread out the framerate drain.

[Rayc]

I did not know the difference between the bridge and the drawbridge, that link will be of help.

The difference it seems between some of these ratchet traps and the pump is the open space above.  The main thing I seem to be missing is something to put directly above the bridge that is open when rocks are going up, and a wall when the rocks try to go down.

A minor thing on the deadly-ness of the trap: After the dog was pelted with many rocks I noticed a mason coming to dump a rock.  Upon him reaching the square that the dog was on, he immediately died of thirst.  I'm not even sure how to repeat this bug.

[Lord Urist]

I think with the whole ratchet-thing, the smallest one you can have is:

Code: [Select]

...B...B
..BW..BW
.BWW.BWW
BWWWBWWW
Which is one smaller than the one that Sphalerite used, but one bigger than the one numerobis used. This is because:

Objects can be thrown up to 3 tiles away X,Y, and Z, in any direction.

with numerobis's system, then an object on the lowest bridge can travel up 2 and left 1 (3 tiles), which then places it at the top of the previous ratchet, so it would allow backflow. (In fact, it can go from any of the bridges to get to the top of the previous ratchet)
Having said that, the smaller amount of time to cross between ratchets may ofset the chance of it travelling backwards, so testing would be needed to determine the best ratchet. Then again, if Sphalerite's floating-door system works, then it wouldn't matter, and in fact wouldn't need the ratchet system at all. Just have it like:

Code: [Select]

WWWWWWWW
DDDDDDDD
BBBBBBBB
with the correct doors and bridges activating to move objects along (don't forget that in this system, objects won't clog the doors - they won't sit on top of the bridges, but fall down onto them, to be in the same square)

[hailthefish]

I'd like to see actual constructible conveyor belts added but in the mean time, this is pretty cool.

[Sphalerite]

The design I picked is the smallest one that prevents any backflow in the system.  Objects can be thrown up to 3 tiles in each of the three directions independently, which means that in the ratchet conveyor an object can be thrown 3 tiles up and 3 tiles backwards at the same time.  Once I worked out the physics of how objects are thrown by bridges I wrote a Python script to run simulations of bridge-based conveyors in order to work out the fastest design.

According to my simulations, this design:

Code: [Select]

......B......B......B......B
.....BW.....BW.....BW.....BW
....BWW....BWW....BWW....BWW
...BWWW...BWWW...BWWW...BWWW
BBBWWWWBBBWWWWBBBWWWWBBBWWWW

transports objects at a average rate of about 0.037 steps forward per bridge cycle, when considered in long durations and long distances.  This is noticeably faster than this design:

Code: [Select]

...B...B...B...B
..BW..BW..BW..BW
.BWW.BWW.BWW.BWW
BWWWBWWWBWWWBWWW

which due to the inability to prevent objects from traveling backwards through the ratchet averages below 0.02 steps per bridge cycle over long distances and time periods.

[thijser]

perhaps you could make something like this

(side view)
BBBB
BBBB
BBBB
BBBB

now when in action
BBBB
.....
..D.
.....
next frame
BBBB
BBBB
..D.
BBBB

D=dwarf
B=bridge(closed)
.=open bridge

Well in words (if the pictures aren't very clear)
the moment the system is turned the lowest bridge trows up the dwarf which then hits bridge 2 levels higher and thus stops going up (to prevent falling damage/reduce it) then the Z bridge on the level under it moves down and the dwarf in question is standing on a new bridge the system repeats itself until a lever is pulled. this might take a lot of logic gates.

[Sphalerite]

Bridges don't throw creatures upwards.  They throw objects upwards, but creatures thrown by bridges stay on the same Z level.

[Quatch]

Was it this one?

http://www.bay12forums.com/smf/index.php?topic=42111.msg769338#msg769338

It was, I bow to your bridge-flinging mastery.

[Zebra2]

water-powered fast repeater.

How can I make one of these?

[Sphalerite]

water-powered fast repeater.

How can I make one of these?

I did not invent this design, I don't recall who did, but I've built dozens of them in my fortresses:

Code: [Select]

WWWWW
WX^b+
WWWWW

where W is wall, X is a floodgate, ^ is a pressure plate set to trigger at water of depth 5 or greater, b is a single-tile raising bridge, and + is open space.

Connect the pressure plate to the bridge, the floodgate, and whatever you want the repeater to drive.Connect the left side of the machine to an infinite source of water.  Optionally use another floodgate or something if you want to be able to turn it off.

When you connect the repeater to a source of water, the water will rush in and trigger the pressure plate.  This will cause the bridge to rise, blocking the water inlet, and the floodgate to open.  When the floodgate opens, it will cause the water level on the pressure plate to drop below 5.  This will cause the pressure plate to untrigger, causing the floodgate to close and the bridge to raise.  The cycle will repeat.  This will cause bridges, doors, floor hatches, or whatever else you connect it to toggle on/off every 100 steps forever.  It will also consume water, which is why you need to hook it up to a river or aquifer or something to keep it running.