Print

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

[Sutremaine]

The repeater, 2-step:


First pic is with everything unhidden, second is with everything but the track itself hidden. The ramp direction isn't shown in this one, but I believe it's NW for both. The southernmost plate, p0, is linked to the lower bridge, b1 (this plate is used once only, though it is not a one-use plate). The middle plate, p1, is linked to the upper bridge, b2 (the bridge of the next cell in line). The northernmost plate, p3, is linked to the lower bridge (the bridge of the next cell in line).

The southernmost pressure plate (p0) primes the system, retracting the bridge in the first 2x2 cell (b1). I've had some issues with this 'taking', so you may need to push the minecart into a harmless wall a couple of times and replace it until the retraction happens. Once you push the minecart in, it'll move within and between cells indefinitely and not touch this plate again.

The bridge in the first cell (b1) is retracted due to the priming plate the minecart has been placed on (p0), and so the minecart takes the corner beneath. It rolls continually over the pressure plate (p1), blocking the exit from the next cell (retracting b2), and continues to do this until the priming plate (p0) deactivates and replaces the bridge (b1). The minecart now goes straight across the bridge and into the second cell, where it is held there by the action of the previous cell's pressure plate (p1) and continually rolls over the second cell's pressure plate (p2). About 200 ticks after the minecart leaves the first cell, the bridge in the second cell (b2) retracts, allowing the minecart back into the first cell. It is held there by the action of the previous cell's pressure plate (p2), and continually rolls over the first cell's pressure plate (p1)... And so on.

You may be able to do without the priming plate depending on the placement of the ramps and other plates. Pushing a minecart straight into a route that avoids any pressure plates but the one in the first cell will do the priming plate's job, because the minecart will be entering the first cell while its plate is activated and no other one is, in theory at least.

The latch, or the potential for one -- this is just a lever-operated pressure plate, and the more I think about it the less useful it becomes:


This one's simpler. You have a small loop with no pressure plate, and overlapping it is a larger loop with a pressure plate, and you just push the minecart in. If the bridge is retracted, the minecart turns the corner and remains in the small loop away from the plate. If the bridge is out, the minecart jumps to the section of track with the pressure plate, taking the larger loop and keeping the plate active.

[laularukyrumo]

I'm not nearly as dwarfy as required to totally understand what's going on in these diagrams... but if the construction works as advertised, holy. Shit. You have just revolutionized dwarfputing.

This needs to get wiki'd.

[Sutremaine]

Movie for the second: http://mkv25.net/dfma/movie-2547-leverpressureplate

Movie for the first, sort of: http://mkv25.net/dfma/movie-2548-minecartgrinderrepeater

As stated in the movie description, that one was the prototype (the bridges work at 1x1, but you can't see what they're doing. Doors might have worked here). The linkages are the same, but the bridges are separate from the cells. The main difference is the speed of the cart. The 3x2 version needs pressure plates to block movement, the 2x2 version needs them to allow movement.

I don't have a recording for the 2x2 shown in the screenshot, because the game crashed before I could record it. Nothing to do with minecarts, just some destabilising modding of the metals file.

[backora900]

If you just need a repeater you can use one of my designs.
http://www.bay12forums.com/smf/index.php?topic=114695.0
To create a latch you just need to shorten the circuit, I guess.
Also, if I remember correctly you can use the door for stoping the minecart and the dwarves wouldn't have to restart the contraption by pushing the cart again. Simply opening the door should do.

I wanted to ask you about your first repeater. Because I have noticed with my design that the bridges causes some sort of lag (brief-freeze hard to describe) when switching positions. Have you noticed anything like that?

[Button]

I placed links to both of your threads on the 'Repeaters' page of the wiki.

[laularukyrumo]

I wanted to ask you about your first repeater. Because I have noticed with my design that the bridges causes some sort of lag (brief-freeze hard to describe) when switching positions. Have you noticed anything like that?

Bridges have a 99-tick delay between when the signal (open or close) is received and when they actually change states.

[backora900]

I wanted to ask you about your first repeater. Because I have noticed with my design that the bridges causes some sort of lag (brief-freeze hard to describe) when switching positions. Have you noticed anything like that?

Bridges have a 99-tick delay between when the signal (open or close) is received and when they actually change states.

Yes, thats why is my repeater optimized to 200-ish ticks. But those freezes I was talking about are ment for the whole game. It takes splits of a second but it is really annoying. Maybe it's nothing and it's just caused by my computer.
(when the bridge graphicly changes to a different state it freezes game)

[Sutremaine]

I get that with raising bridges, even if they don't change graphically. The delay is noticeable enough that it can be used as confirmation the the bridge has changed states.

Thanks for the wiki link, Button.

[Telgin]

Supposedly the game freezing for a moment when a bridge changes state is because it has to recalculate the reachability map for path finding.  Has anyone tried isolating the moving drawbridges behind constructions or other raised drawbridges?  Theoretically that would allow the game to quickly recognize that the reachability map has only changed for a small subset of the map / graph and avoid having to redo large portions of it.  Theoretically.  If it's coded to recognize that.

[laularukyrumo]

Something that just dawned on me. Does it matter which of the pressure plates is linked to whatever it is that you're sending the repeating signal to? Or should they both be linked? Or neither, and there's a secret invisible pressure plate somewhere else handling this important piece of the puzzle? Or am I just totally crazy?

[i2amroy]

What's the repeater times on these? Or alternatively is it possible to create an adjustable length one through a track stop with friction?

[Sutremaine]

Does it matter which of the pressure plates is linked to whatever it is that you're sending the repeating signal to? Or should they both be linked? Or neither, and there's a secret invisible pressure plate somewhere else handling this important piece of the puzzle? Or am I just totally crazy?

If you just want something repeating and don't need it to go as fast as possible, linking to any pressure plate but the primer plate will be fine. The signal sent will be mostly 'on', so bridges will be mostly raised or retracted and doors and floodgates will be mostly open. Gears can be inverted before the repeater starts.

What's the repeater times on these? Or alternatively is it possible to create an adjustable length one through a track stop with friction?

With the 2x4 repeater, it's a little over 400 ticks for the minecart to get back where it was with the pressure plates and bridges the way they were. Altering the track length or putting track stops in should adjust the repeat time consistently.

To be honest, I've kind of forgotten how it works...

[gchristopher]

I've been trying various designs for things like this and I think I can understand some of the "works sometime" behaviors. Derailments and ramps can leave a cart with counterintuitive offsets. It can appear to be moving faster, but actually be losing momentum by teleporting to the far side of an impulse ramp and losing the chance to accelerate. I'm holding faith that it's deterministic, but sometimes the logic isn't straightforward. A dwarf picking the cart up resets the offsets to 0, at least. It's giving me a headache.

Do you know if there's a dfhack lua API command to advance the game by one tick?

Anyway, uh, I don't know if this is useful, but here's a 2x4 version of the second latch that lets you shut it on and off by controlling a hatch? That sounds like a good thing?

Code: [Select]

z = 0   
ramps    track    pressure plate and bridge
▒▒▒▒▒▒   ▒▒▒▒▒▒   ▒▒▒▒▒▒
▒▲▲▒▲▒   ▒╚═▒║▒   ▒  ▒ ▒
▒▲ ▲▲▒   ▒║═╚╗▒   ▒ ^╬ ▒
▒▒▒▒▒▒   ▒▒▒▒▒▒   ▒▒▒▒▒▒

z = +1
▒▒▒▒▒▒
▒▒▼╔¢▒
▒▒▒▼▒▒
▒▒▒▒▒▒
The pulse generation works the same as your example. The pressure plate controls the bridge and toggles which path the cart takes. It goes up one z-level to add a lever-controller on/off hatch and is one tile larger on the left to add a couple impulse ramps to get it up the ramp.

[Sutremaine]

Why not advance the game one tick in-game? (I'm sure it can be done via DFHack though.)

The shutoff is useful, and incidentally answers a question I had about converting the layout to use the faster-responding hatches.

[gchristopher]

Why not advance the game one tick in-game? (I'm sure it can be done via DFHack though.)

I was trying to determine game cart logic by tabulating cart offsets one tick at a time as they encountered a variety of track/ramp/derailment combinations. It requires switching to the DF window, pressing period, then switching back to dfhack, recording the state, back and forth for every tick.

It'd be a lot nicer if there was a lua command to advance a tick, so I could just kick off a "record 100 ticks" program with one command.