Print

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

[Larix]

One consideration which allows getting closer to the optimal speed:
In the four-plate design, you can assign different 'roles' to the different plates, i.e. two are only there to provide 'extend' and two only to provide 'retract' signals. I think that's already what happens anyway, but i suggest actually making use of it:

Thus, in the theoretical 160-step cycle, the plates would not be 40 steps apart, but rather be placed in the locations
0 - 20 - 80 - 100
(pretending an 'off' signal takes 100 steps to be triggered; i know that's not normally the case, let's assume we fiddled with build order)

The cart goes over the plate at 0 and a 'retract' signal is sent; forty steps later, the command is executed and at the same time, the 'extend' signal of the plate at 100 ('off' sent at step 200, i.e. 200-160=40 of the next cycle) is received. That one's executed at step eighty, and at the same time, the plate at 80 is passed and a new 'on' signal taken, which is executed at step 120, when the 'off' signal from the plate at 20 arrives. In my example circuit with an 84 spike cycle, the 'off' plates are 23 steps past the preceding 'on' plates (and 61 before the next 'on').

Keeping this off-set in mind, a four-plate cycle can be pushed to a spike repeat time of under 90 steps; it shouldn't fully work for a three-plate cycle, because the 'roles' of the individual plates would change (that'd happen in all circuits with an odd number of plates), so optimisation by plate offsets shouldn't work. A full cycle of ~95 should still be possible with equidistant plates, and a circuit with _two_ equidistant plates should be able to produce a cycle of just over 100 steps.

Edit: @ravendarksky - you have to somehow count the individual steps. The easiest, but very low-tech way is to simply hit 'space' in game and then proceed in single steps by hitting '.' (period), count how often you hit the key.
There might be less fiddly methods (macros and maybe some DFHack trick), but as long as you don't habitually mis-count, it's easy, reliable and accurate. As a compromise, you can also just count the steps which pass between the reset of a pressure plate (99 or 100 steps after its activation condition ceased) and its next activation; in the case of one-plate spike repeaters, you want to have no less than 40 steps between those two events, but also not much more.

[jcochran]

@Larix.  Yep, in the 4 plate prototype, two of the plates did issue the extend commands and two of 'em issued the retract commands. And your idea of using a rectangle instead of a square is a very good one. I suspect that it could reach the theoretical best speed. Very useful for getting the most bang from your buck when creating spike trap hallways where fast running kobolds might want to either sneak in or make their getaway through. Also quite useful for situations where you don't have many spike traps capable of inflicting damage, but wish to make the most of 'em (think right before the hatch in a goblin grinder that some troll or ogre is attempting to destroy. Only 1 trap capable of hitting 'em. Might as well hit 'em more frequently....

As for build order, it really doesn't matter if the spike traps are built before or after the repeater. The only thing critical about build order is that all of the pressure plates have to be constructed either before or after the spike traps. Mixing that up would result in a problem with close timing. Otherwise, it's not a problem and expected use case would be to have the repeater built prior to many if not all of the spike traps. (Tend to put in a few traps early, but keep adding more traps as time goes on. Those new traps are obviously built after the repeater....)

[jcochran]

Oh, okay, I think I get you.  So in theory if we had plates sending a signal every 70 tics, the timeline would go something like this (On/Off being a momentary touch of the plate, aka: minecart):

0 tics	On/Off sent
40 tics	Spikes Hide (0 tic)
70 tics	On/Off sent
110 tics	Spikes Hide again (70 tic)
140 tics	On/Off sent & spikes visible (0 tic)
180 tics	Spikes Hide (140 tic)
210 tics	On/Off sent & Spikes visible (70 tic)
250 tics	Spikes Hide (210 tic)
280 tics	On/Off Sent & Spikes visible (140 tic)
320 tics	Spikes Hide (280 tic)
350 tics	On/Off Sent & Spikes visible (210 tic)

Using a single repeater (if set JUST right) you could in theory double the number of pulses going through the system.  Neat.

Not quite. Consider the plates to send an "retract" message and an "extend" message for this example. If the spike trap gets a message indicating a state that it's already in, the message is ignored (You want me to extend? I'm already extended. Ppppbbbttt). If it gets a message that's opposite whatever state it's in, it will go to the new state in 40 ticks. A pressure plate always sends alternating messages. If the trigger condition happens again before the deactivate message went out, the sending of the deactivate message is cancelled and no activate message is sent either. When the trigger condition is once again not met, then the deactivate message will go out 100 ticks later.

[jcochran]

Well, I tried an 0-20-80-100 repeater and it looked promising initially (I planned on having two launchers aimed at each other. Each of 'em would be identical and handle 80 ticks out of the 160 for the entire loop. A nice simple symmetric design. In any case, my 2nd track route gave me a timing of 81 ticks for the half loop. I called it "good enough" and placed pressure plates on the assembly and gave it a try. No joy. The spike traps were cycling, but far slower than they ought to have been. Did a LOT of close examination and things just didn't make sense. I finally decided to take a look at how the first cycle after launch looked like. It wasn't easy. Turns out that when the retracting bridge retracts, df leaves pause mode and full speed ahead. But I finally managed to be able to single step through launch and saw what was happening. Unfortunately, the launch isn't stable and the minecart may be travelling at a slower than normal speed compared to its speed after the loop has stabilized. That throws off the roles of the pressure plates (issue retract, issue extend) and completely messes up the timing. So until I can find a stable launch such that the timing on the first loop is exactly the same as the timing on subsequent loops, I will stick to designs where every pressure plate has the same role. I think I'll see about a 3 plate version with 47 ticks between plates. Should be simple enough and a 94 tick cycle for a spike trap is pretty darn good. And it was an interesting exercise...

[Larix]

A likely culprit for the problems mentioned above is insufficient cart speed. When a cart spends more than one step on top of a pressure plate, it will be counted as present for more than one step, delaying the 'off' signal for its full lingering time. So if you have, say, a cart moving at 500 millitiles/step (or 0,5 tiles/step = 2 steps per tile), it will hold the plate down for a full two steps on each passage, and the 'off' signal from the resetting plate may arrive one step too late, resulting in the extending of the spikes delaying as well and colliding with the next 'retract' signal, which thus isn't processed.
It doesn't help at all that pressure plates seem to make their load checks _before_ carts get to move. If you have a cart spending only a single tick on top of the plate, it will look like this: plate inactive and cart one tile before the plate - cart moves onto the plate, plate is still inactive - plate activates and cart moves off it in the same step. I.e. first you see the cart sitting on the inactive plate, and the next turn you see an active plate without a cart on it. This signal processing can be quite misleading when you're looking for an 'off' signal that must be sent at a precise moment.

Another problem is that build order can probably mess up the routine - depending on which order the spikes and the pressure plates were built in, activation times might be one step longer or shorter. I've never understood those rules, so prefer to err on the side of caution when getting close to the reaction time limits.

Perhaps you could have more success starting 'small', say with a 90-step cycler (~35:55) and try to tighten it from there. It's not necessarily worth the effort, since, as you stated, a three-plate cycler should be able to get off three processed signals in a round of 141 steps, effectively increasing the frequency of the spikes by 50% over a single-plate repeater. A perfect four-plate repeater would take 160 steps for four processed signals, a further improvement of only ~17%.

[jcochran]

Well, I got a bit suspicious of how fast a spike trap can cycle given that a 140 tick repeater I made earlier didn't cycle the spikes at 140, but instead the spikes had a cycle of 280 ticks (this was on a single plate repeater). This morning I decided to bite the bullet and hook up a spike trap to a lever and then manually toggle the lever using the lever command in dfhack with the cheat option. When manually flipping the lever at 40 ticks, the spike trap only caught every 4th flip and toggled slowly... But when I manually toggled the lever every 41 ticks, it caught every toggle. So it looks like a spike trap will respond to a signal source either 40 or 41 ticks after the source sends it depending upon built order, but will at best only toggle every 41 ticks. With that said, here are the two repeaters I came up with last night and this morning ....



A three phase repeater with each pressure plate being activated exactly 47 ticks apart. A spike trap connected to all three plates will cycle every 94 ticks. The 4 track stops are all medium friction. The launcher at the bottom left corner isn't strictly part of the repeater and may be safely omitted if you wish to simply have a dwarf push a minecart instead.


A four phase repeater. A spike trap connected to all four plates will cycle every 82 ticks (the fastest possible speed). The impulse ramps at the top left, and bottom right corner are a N/S ramp where the cart enters the arrangement and then 2 N/E or S/W ramps. The two track stops are medium friction and once again, the launcher at the bottom left corner isn't strictly needed and you can instead have a dwarf push the minecart onto the repeater (if you do have a dwarf push a cart, I would suggest pushing towards the east onto the long E/W track segment at the very bottom, or pushing towards the west along the E/W segment at the very top. I'm injecting the minecart with my launcher further north than my suggestion because my launcher pushes a lot harder than a dwarf and by injecting further north, I take up less vertical space for the entire construction.) One word of warning on the four phase repeater. If you incorrectly introduce a minecart to it and it gets in the wrong phase with the spike trap, it will settle down into a steady state where the spike trap will cycle every  164 ticks. Definitely not what you want. I haven't personally seen that happen, but in any case, the pressure plate after either of the groups of impulse ramps must be the first plate triggered when starting the repeater. As a little puzzle, it turns out that there are nine different arrangements of four pressure plates that will work. Any other arrangement will not permit the spike trap to have a 41/41 cycle. Can you figure out the other eight arrangements?

Build order is not critical. As long as the spike trap you're connecting to has been built before any of the pressure plates, or after all of the pressure plates have been built, then it will work fine.

Now to mention a happy coincidence. On the three phase repeater, if you connect a spike trap to only one pressure plate, it will have a 141 tick cycle which just happens to be the fastest possible cycle time for a single plate repeater. So with the above two repeaters, you actually have the three fastest possible repeaters with cycle times of 141, 94, and 82 ticks. Now about that hypothetical kobold that needs to be introduced to a set of spikes and how much it would cost to do that....

Assuming you want at least one encounter with a spike trap for a creature taking 7 ticks to move each tile.
141 cycle trap - takes 21 traps (210 spears, 42 mechanisms, 252 total)
94 cycle trap - takes 14 traps (140 spears, 84 mechanisms, 224 total)
82 cycle trap - takes 12 traps (120 spears, 96 mechanisms, 216 total)

Given that mechanisms are generally cheaper than spears (rock vs metal), the 82 cycle trap wins even though is uses the most mechanisms. If you're targeting a slower creature, the balance shifts slightly. For instance, sometime that takes 8 ticks/tile to move would require 18, 12, or 11 traps depending upon speed resulting in 216, 192, or 198 objects giving the advantage to the 94 tick repeater. As the speed of the creature goes down, the difference between the 94 tick and 82 tick spike traps converges to almost nothing.

In conclusion, I would suggest using the three phase repeater. For spike traps that aren't critical (danger rooms and the like), connect the spike trap to one of the pressure plates giving you a nice 141 cycle trap. For those areas more critical (you wish to maximize damage to a creature, have a relatively short corridor, etc), then connect all three plates to those traps.

[WanderingKid]

On your 3 phase repeater, what friction are the 4 track stops and what's the + in the bottom left of the main circuit?

[jcochran]

Another problem is that build order can probably mess up the routine - depending on which order the spikes and the pressure plates were built in, activation times might be one step longer or shorter. I've never understood those rules, so prefer to err on the side of caution when getting close to the reaction time limits.

I suspect that Toady is using a singly linked list for all buildings (or at least all 'active' buildings such as switches, pressure plates, bridges, etc). For such a list it's easiest to add new entries to the beginning of the list and perform searches starting at the beginning as well. Finally, I suspect he's only storing a single state for each object instead of a current and next state. With that in mind, assume you have two items in the list. A pressure plate and a trap.

Case where plate built before trap. List looks like:
1. Trap
2. Plate

So a cycle of processing happens. The trap is processed, sees the state of the plate and takes action based upon the state of the plate as the trap sees it at that moment. Then the plate is processed and updates its state based upon what it sees.  Notice that anything that happened to change the state of the plate isn't see by the trap. It was using the state of the plate as it was at the end of the previous tick.

For the case where the trap was built before the plate. The list now looks like:
1. Plate
2. Trap

And in this case, the Plate is processed and updated before the trap is. And when the program gets around to handling the trap, the trap then sees the state of the plate as it will be at the end of the current tick

There really isn't any clean method of avoiding this dependency on build order except by having every object place their "new state" into a holding location that no other object looks at, then at the end of a tick, copy all of the state information from the holding area into the active area to get ready for the next tick. Doing so would result in build order independence. But it would also result in both increased memory usage (need room to hold the new state) and increased CPU time (have to work to copy the new state over the old) and as such reduce FPS and make the game even slower. 

[jcochran]

On your 3 phase repeater, what friction are the 4 track stops and what's the + in the bottom left of the main circuit?

All of the track stops are medium friction. The + symbol you see is I suspect a retracting bridge I use to start and stop the repeater via a lever. The launcher (the complex of 6 impulse ramps) when the repeater is off has a retracting bridge showing to hold the minecart in the extreme lower left corner and another retracting bridge allowing the minecart to escape the repeater and roll onto the launcher. When the repeater is turned on, both of those bridges vanish, the launcher pushes the minecart north where it derails and then rerails onto the repeater which then does its thing. The lever is connected to both bridges.

[jcochran]

Edit: who cares about theory, i just went and did it:



Bam, 168-step cycle, spikes repeat at 84 steps. 4x11 track area, two 2x1 boosters to provide speed, two medium-friction track stops (cart's too slow to clear the plates in time at the un-braked 82 step half-cycle).

If you want it easily start/stoppable, build a hatch cover over one of the ramps and hook it up to a lever.

What does the Z level below that image look like? And if the half-cycle is 82 tics, I suspect clever placement of the pressure plates will result in an optimum 41/41 cycle for the spike trap. To calculate when a plate signal is sent from a pressure plate, use the following.

Close signal - Happens at arrival tic + 1.
Open signal - Happens at arrival tic + 100 + number of ticks minecart sits on the tile.

So if you're counting ticks and the minecart lands on a tile at tick 123 and moves onto the next tile at tick 126, you get the following.
1. Arrival = 123
2. dwell  = 126-123, or simply 3 ticks.

So the active signal gets sent at tick 123. And the deactivate signal gets sent at 123 + 100 + 3 = 226.

On my own four plate repeater, I did quite a bit of trial and error until I managed to get a track layout where the half-cycle was exactly 82 ticks. I then noted how many ticks the minecart spent on each tile of the half-cycle and plugged those numbers into a simple spreadsheet that gave me for each tile assuming a pressure plate was placed on them
1. What tick an "on" signal would be sent by a plate on that tile.
2. What tick an "off" signal would be sent by a plate on that tile.
3. Assuming you use the plate for "on", what tick you would want an "off" to happen.
4. Assuming you use the plate for "off", what tick you would want an "on" to happen.
Of course all the tick numbers were modulo 164 (the total length of a full cycle).
I was hoping to put a pressure plate on the 1st tile after the impulse ramps. According to the spreadsheel, the "on" signal would happen at tick 1 (I used the moment that the mincart hit that tile as tick = 0). So the one was pretty obvious. It also told me that I desired an "off" at tick = 42. I looked down the column of numbers and didn't see a 42. So too bad, can't use that tile. I then looked at the next tile. For it, "on" would happen at tick = 2 and desired off was at tick = 43. Looking down the column of numbers, I happily saw a 43 on the other half loop. So there were my two plates, I then confirmed that the mirror plates also had compatible numbers and then built all 4 plates.

[Larix]

What does the Z level below that image look like?

There are two additional ramps, one directly north of the northeastern, the other directly south of the southwestern plate. All ramps are plain NS track ramps. All movement is provided by good old ramp glitches.

And if the half-cycle is 82 tics, I suspect clever placement of the pressure plates will result in an optimum 41/41 cycle for the spike trap.

Probably. I just eyeballed it for the 84-step repeater and when it worked, called it a day. If i wanted to try, i'd proceed roughly the way you described.

Nice work, anyway, to nail both the probable optimum for spikes _and_ to work out the three-part 141-step repeater - that one's particularly nice since, as you said, it's the optimum both for the single-plate and the 50% faster three-plate circuit.

Edit: Thanks for encouraging me to give it another look:



Ripped out the medium-friction track stops and shifted the pressure plates around until they fit. Test firing gives the proper two full cycles per 164-step round, the spikes make a full cycle in 82 steps. The retractions/extensions of the spikes take place the exact step before the pressure plates change state.

There's really nothing much to see on the level below:


I had first tried it with additional linear accelerators (the east/west ramps - EW track ramp engraved) but that was much too fast, so i floored them over with constructed EW flat track.

Oh, and i put a hatch cover, operated by lever, over the opening of the northern pit. Now it can be stopped and started with a single lever-pull, without any "warm-up" period: the cart cycles at the standard 164 steps per round from the very beginning and should be fully synchronised once it's ~3/4 through the first round.

[WanderingKid]

Larix,

In your design, is it dropping down into the pits, hitting the wall, then coming back out and rolling around the track again with the stop/accelerator doing speed controls?

[Larix]

Exactly - it falls or drives into the pit, bumps into the far wall, rolls 'down' the ramp and goes up the exit ramp (thanks to the ramp teleportation bug), round the corner and on the next leg of the circuit. The fact that it actually stops at the blocked tile and regains speed from a standstill regulates the speed - as far as i can tell, the cart will always emerge from this construction at a decent but limited speed (~32 000, estimated). The fixed speed is quite helpful when building minecart-operated logic devices, because carts can misbehave severely when going too fast or too slow.

Putting a "linear" accelerator (straight double-ramp pit which the cart can freely pass through, the built but later floored-over E-W pits in my design) shortly behind such a regulator increases the speed significantly, to an estimated 45 000 - speedy, but still clearly below derail velocity. This is quite handy for precision repeaters with multiple pick-ups, because the faster cart spends less time on each tile. In this example, however, the slower cart had just the right speed for the intended purpose, and in the end didn't even need the mid-friction track stops.

Edited/rewritten.

[Larix]

Quick highjack to toot my own horn: while messing around with stuff for this repeater project, i stumbled over the basis for a very compact clock-viable repeater:

Paths above Ramps below

The cart circulates counter-clockwise.

Every opening leads into a two-ramp pit, engraved with an 'outward' hanging loop: on the southern branch, the ramps are engraved with SE track below the opening, and SW track right next to it, covered by the NS track. On the northern branch, they're engraved NW under the opening and NE under the cover. The cart always falls into the pit from the not-engraved side (from north on the southern branch, from south on the northern branch), bumps into the closed ceiling and emerges from the opening to the outer loop and around to the next pit.

Without any further regulation, each sub-cycle has a return time of 35 steps, so the full six-segment cycle takes 210 steps.

But of course, we can regulate the repeat time, by slowing down the cart with track stops. The strongest effect possible without stopping the cart outright is a high-friction track stop, positioned on the tile touched upon emerging from a ramp (thanks to ramp teleport bugs, the cart only spends one step there). This alone extends the segment repeat time to 47 steps. Further fine-tuning is possible by adding medium- and low-friction track stops:



A high-friction track stop on each emergence tile, medium-friction track stops directly adjacent in the southwestern and northern central segments. In the eastmost segment (south-to-north switchover), there's a medium-friction track stop three steps after the high-friction one, and a low-friction stop on the tile before the cart's dropped into the next pit. The switchover behaves differently from the 'in-line' segments and thus required some additional fiddling, but with this setup, it works out.



And that's the whole installation, no power, no moving parts, just track stops and self-lifting ramps. The pressure plate on the south-to-north switchover branch fires 47 steps after the preceding one, the plate after it fires 53 steps later. All other plates are exactly 50 steps apart.

The entire circuit cycles once in 300 steps, 1/4 of a day. Expanding the design by two-segment steps should be perfectly doable, e.g. to a 12-segment cycle for a half-day; since such a design would be buildable without extra track stops on the switchover branches, it might be possible to calibrate it to the exact 50 steps per segment all around, for the perfect 'dwarf hour' count. The cart goes pretty slowly on the above-ground track, typically at speeds between five and nine steps per tile - 11 000 to 20 000, somewhere between a dwarven push and a lowest speed roller.