Print

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

[Larix]

Since i accidentally discovered the awesome cheaty potential of the humble double ramp (automatically provides acceleration to minecarts, up to derail speed if one ramp has an impulse effect) i wondered about its possible applications. Self-derailing cells take a minecart, cycle it through a mere 3x2 tiles and shoot it out its 'exit' after a number of ticks. Depending on the parameters and direction of the minecart going in, that interval ranges from 90 to 200 ticks. Chaining several of these after one another has a nasty habit of imparting very unusual start parameters for different cells, so a long cycle may have highly unexpected return times.

1. The Oscillator

So, to get started, i carved a nice long track of self-derailer cells into a pristine level of stone:



Main loop to the right. As you can see, i engraved twelve chained-up self-derailers, but in the end blocked the twelfth - the one in the upper right corner - because the return time was too long. With only eleven, the cart makes the full cycle in almost exactly two days. Yes, an array of 35 by seven tiles, over two levels, and a cart takes a full two days (~2400 ticks) to get around _once_.

The self-derailer is the simple three high by two wide array you see here so often - the tracks engraved on the upper level are clearly visible. The arrays on the far right all receive the cart from the south (coming up a ramp) and send it out to the north. Here, the ramps all have a 'hanging loop' engraved consisting of a W->N and a S->W track corner. The cart always enters the pit from the south, getting down ramp and apparently impulse acceleration. If it's under derail speed, it leaves the pit to the west and cycles back to the south. Once it reaches derail speed, it leaves the cell to the north. Sometimes, the cart jumps off the ramp and slams into the far wall, landing on the northern ramp in the pit and climbing out via double-ramp shenanigans. It _can_ exit onto the 'middle' tile, thus that track corner on the upper level is necessary.

The bottom level is just a mess of up ramps and very short track bits, so i won't show it. There are two track-operated pressure plates down here, one to pick up the two-day full return signal and send it to the counter arrays, the other to send an extra tick to flip the daily counter. I had linked up the 'week' counter before the first testing run, so didn't want to establish another seven hatch links.

2. Counting the days

Now we got our regular tick, but how to turn that into an actual readout?
Turning a single tick into a regular signal is possible in many ways, but the next step is of course a machine that turns a single tick and _advances_ from one regular signal to another. I had messed around with powered systems relying on hatch covers, but the double ramp glitch allows for much more reliable and compact hatch-switched counters. I'm sure there are other, much more elegant and probably less convoluted and spacious counting systems, but i guess i'm kind of stupid and can't think on the necessary abstract level to even understand. So i came up with my own counter. You see the first one i ever built to the left, and of course, it's an unholy mess. To make it hopefully somewhat understandable, let's look at the array that counts the fortnights and cycles once per season:



So, what do we see? A bunch of self-derailers, that's right, but here they only serve to introduce a delay to the actual counting mechanism: a simple double ramp which bounces a cart against a ramp on a wall, over a pressure plate to give a permanent signal. The ramp away from the pressure plate is covered by a hatch, and once the hatch opens, the cart barrels out the other end and makes a beeline for the next pressure plate. If i let it run just like that, it'd arrive long before the hundred ticks recover time of the original signal were up and the hatch at the new place closed. The cart would just zoom through it. But with the derailer, we can delay the cart's arrival - it's occupied long enough that it'll arrive only when the hatch cover is already closed and will be caught in the new 'holding cell' until the next input arrives and opens the hatch again.
A hatch cover could _also_ be used to block a cart's escape from a derailer - put it over the 'exit' ramp, and it will keep bouncing out on the middle tile without ever reaching derail speed. However, if you open the hatch, the cart takes significantly longer than one hundred turns (180 or so) to escape, by which time a single-tick signal would already have expired and the hatch would be closed again. I haven't tried yet what happens if you cover the 'back' ramp with a hatch.

So, by combining those two devices - 'latch'/holding cell and derailer/delayer - i got a device that, upon receiving a 'one-pulse' signal which times out after the customary one hundred ticks (like from a cart passing over a pressure plate on a long cycle) moves the cart from one location to the next and _only_ the next, reliably.

Of course, there are too many days (or pairs of days, what my oscillator counts) in a year to reasonably handle with a single counting loop of 336 or 168 counter arrays, but that's easily rectified. All that's needed is a circular counting array that has another plate which the cart only passes once per full counting cycle. The signal of that plate is then sent to another counting loop counting the next larger units (here of time). This also saves a lot of expense on hatch covers and mechanisms and time, because in this setup, the pressure plate giving a signal to the counting loop must be linked to _every_ hatch cover in the loop, taking two mechanisms and quite a bit of time for each job.

So, to count the pairs of days and put out a signal every fortnight, i built the seven-counter mess seen in the first picture. Fortnights are counted by the loop above and seasonal signals sent to what's seen on the right here:



On the left, there's a simple two-counter activated twice per full cycle of the oscillator, so i can count days. It has no outputs apart from the readout.

On the right, there's the season counter. The dark pressure plate is held down by the cart, which is currently in the pit. And this is plate number one, corresponding to spring (of the third year in this fort). The basic counter is probably easiest to explain here: on the top right, we have from left to right an EW up ramp against a wall, straight EW track with a pressure plate, a double-ramp pit (still plain EW track) with a hatch cover over the eastern ramp to keep the cart contained, yet another bit of flat track for when the cart is allowed out. It will then enter the self-derailer, spend ~100 ticks there and eventually escape to the east, along a short track leading south and turning back west, where it then emerges from the ramp and falls into another double-ramp pit. By the time it arrives, the hatch will be closed again and it will bounce against the wall and keep the pressure plate active.

All the pressure plates within the holding cells are completely unnecessary for the operation of the device, they only provide readable output if you don't want to look into the counting machine itself and check where the carts currently are. For the actual counter operation, you just need the one pressure plate which sends its signal to the next counting loop.

It's not as if the readable output i've devised were all that much to look at, mind:

From left to right: day, pair of days, fortnights, seasons. Counting from 'top' to 'bottom', the niches for the year counter are already mined. Each 'display' is just a hatch cover on top of an engraved floor which opens as long as the related pressure plate is held down.

Allowing no migrants past the hardcoded waves and without invaders, i started the first mining designations at the end of the first year, primed the day, double-day and fortnight counters in Obsidian of the second, kicked the cart into the oscillator on the first of granite of the third year and put the season counter online about two months later. The year counter should be build- and activatable without switching any part of the clock off. And counting years is not the limit, by stacking two five-counters and one four-counters on top of what you have, you can always multiply your counted units by a hundred; three such steps would give you a clock that would only switch back to start after a million years.

On a less momentous note, have a double-ramp based binary randomiser:



and without the hatches and pressure plates:



Takes any input, opening both hatches and ouputs one of two possible signals. Once input ceases and the hatches close again, the cart returns to the no-signal middle stretch, awaiting new input. If the input is random(ish), the output should be as well. An easy example would be the popular citizen-triggered pressure plate in front of the dining room.

And because i promised useless pictures of nothing but ramps, have a look at those ramps:

[Sergarr]

PTW, this is awesome.

[Button]

And because i promised useless pictures of nothing but ramps, have a look at those ramps:

Liar! I can clearly see track in that picture!

(Seriously though this is a new level of awesome)

[Thuellai]

Alright, so, it's a calendar.

Can you attach things to the counter to use that as a state for something else?  (maybe a system which activates every fortnight that does...  a thing, I don't know a lot about dwarfputing)

[Drazinononda]

Alright, so, it's a calendar.

Can you attach things to the counter to use that as a state for something else?  (maybe a system which activates every fortnight that does...  a thing, I don't know a lot about dwarfputing)

Well, two fortnights is a month, which is the time between werebeast transformations... and IIRC in fort mode the transformations last for two days (one day before and one day after the night of the full moon?) so with the right output systems you could automate a quarantine system for any affected residents. Something like a separate mini-fort, including a burrow for the weredwarves, that automatically locks closed for four days around the full moon. And Armok help any haulers trapped inside when it happens.

[Larix]

Well, the contacts are all there - currently, there are one-pulse signals every day, every second day, every fortnight, every season and every year. If you're looking at the longer-lasting activations, you can even be more specific and choose the third fortnight of a season, or summer or somesuch. Just link up your devices to the appropriate pressure plate and then turn the clock back on. If you wanted something much more specific like the last two days of one month and the first two of the next, you'd have to build some extra processing machinery, because that's not something the calendar directly counts, but you would only need to combine signals already provided - first or third or fifth fortnight _and_ first pair of days, or second or fourth or sixth fortnight _and_ last (seventh) pair of days.

[Drazinononda]

Well, the contacts are all there - currently, there are one-pulse signals every day, every second day, every fortnight, every season and every year. If you're looking at the longer-lasting activations, you can even be more specific and choose the third fortnight of a season, or summer or somesuch. Just link up your devices to the appropriate pressure plate and then turn the clock back on. If you wanted something much more specific like the last two days of one month and the first two of the next, you'd have to build some extra processing machinery, because that's not something the calendar directly counts, but you would only need to combine signals already provided - first or third or fifth fortnight _and_ first pair of days, or second or fourth or sixth fortnight _and_ last (seventh) pair of days.

That should be fairly simple to achieve with small "counting" loops triggered by various combinations of inputs from the calendar, right? If I understand correctly, the setup for progressing a minecart from one cell to another based on inputs could also be used to control, say, a system of bridges or doors that are always accessible except for during a period where they receive a specific set of inputs -- for example, during the first two and last two days of each month.

I'm a complete noob at dwarfputing though (really, my only "experience" with it is reading about stuff on the forums) so I may be missing another necessary component, such as a fluid logic switch or something.

[Larix]

Even easier, you link two specific inputs - e.g. the pressure plate constantly held down during the 'sixth pair of days' - the sixth cell of the counter that makes a full turn in a fortnight - and the one held down during the 'fourth fortnight' - fourth cell in the counter that cycles once per season - to two different input-acceptors like hatch covers in an 'and gate': a logic circuit that sends a signal if two inputs are both on, and no signal if at least one of them is off.

Hatch covers are closed when off, open when on. An easily built AND gate based on perpetual-motion minecart would be a self-derailer with its ramps hatched over:



Just put hatches over the ramps, link each to one of your 'to combine' pressure plates and set up the level below properly:



The up-ramp pairs you see to the south are the 'output/acceleration' ramps of derailers, seen from below. When both of those ramps are open on the level above, and _only_ then, the minecart will reach derail speed and leave the array to the north. If you bounce the 'output' minecart against a wall - with ramp, so it actually returns into the derailer, but with no actual floor above to escape to - the cart will bounce into the wall every 90ish ticks or so, enough to keep a plate permanently active. If you add flat track for the cart to pass over before it hits the wall and returns, you can lengthen the interval - the array to the right sends an actual repeating signal every 115 ticks or so, the plate has enough time to recover and send an off signal. The two 'bounce track' lengths seen to the left will send a continuous signal when you put a pressure plate on one of the flat track tiles. The disadvantage of this design is that it takes a while to 'warm up' - almost two hundred ticks.

If either of the ramps is closed (via hatch cover), the cart will keep going around within the derailer and never pick up enough speed to derail and send a signal. If both ramps are closed, the cart will bounce from one ramp to the other constantly (they have a 'hanging loop' track engraved, going W->N and S->W here) or come to a standstill on the northern hatch until it opens again. Once you've built this or another 'AND gate', you install a pressure plate to take its signal and link that to whatever you want triggered, e.g. the bridge you want raised or the pump you want to be active for two weeks per season.

Of course, nothing prevents you from mixing perpetual motion logic with mechanical or liquid logic. It'd probably even be a good idea, since perpetual motion minecarts always have delays between received and sent signal and minor alterations of track layout can have large and unexpected effects. It doesn't help much that i'm not aware of any in-depth previous exploration of their possibilities and that i lack the first idea about computing (a few weeks ago i didn't know what an AND gate is; i hope what i said about one isn't complete nonsense). The calendar/clock is my first attempt to put the various tinkering and designing of perpetual-motion 'circuits' together and make something vaguely recognisable of it.

[ChuckWeiss]

PWT. And praise. Lot's of praise.

[Loud Whispers]

And here I am still without a clue on how to get minecarts from tile A to B. Bravo.

[Larix]

Thanks for the replies. It's a lot of fun to mess around with this sort of stuff, and not the least because double-ramps do produce very odd effects. The effects are regular and reliable within a completed circuit, but when constructing a new course, you can have the weirdest surprises when a cart picks up too much speed sending it on spontaneous circles or lets it bump into the ceiling at the oddest times.

Nonetheless, i've come up with results:

simple NOT gate - sends a signal when input is off, turns off when input is on:



From left to right - EW Track ramp, EW track with pressure plate, double-ramp pit with EW track, hatch activated by signal over the eastern ramp. Once the hatch opens, the cart cycles around the short loop; it will never ascend on the left as long as the hatch is open. Of course, you can also put another pressure plate on the loop and use this device as a sort of relay to offer easy access to a signal sent by a far-away or unsafe signal provider, e.g. a plate in a central repeater or clock which you don't want to stop and start again when connecting new machinery.

Simple, quick-response AND gate:



Two EW-ramp pits side by side, eastern exits can be blocked by hatch covers. If both hatches are open, then and only then will the cart make it to the eastern side and hold down a pressure plate over there. I had wanted to check if the two ramps were enough to make the cart derail, but since it always takes a cart bounced off a wall for input, that's not enough. It works like this (i didn't bother to install the pressure plate on the W->N track corner, but that's where it'd go), but of course you could simply take a straight bit of track in the east. Still, easy to build, quick response, the cart gets away from the pressure plate very quickly when either hatch cover closes.

And what i'm proudest of, not least because i kept running into excessive speed problems over and over again: a combined equality/difference gate, this one is the fruit of several hours of toil, debugging and re-designing:

without buildings:

The (masterwork nethercap) minecart circles counter-clockwise. Both 'operating' pits are straight N-S track. If the first signal is off and the hatch of the western pit closed, the cart bounces back out to the north, is sent around three tight corners and passed across the northern ramp of the eastern pit. If the second signal is also off, the cart rolls over the closed hatch cover in a straight line, over the northern pressure plate and north into the return loop.
Signal 1 - off
Signal 2 - off
Northern pressure plate - on
Southern plate - off

If the first signal is off and the second on, the cart also is sent to the northern pit, but now it falls inside, emerges from the southern end of the pit, and is sent around the corner to the southeastern end of the array. It passes over the southern pressure plate, then continues east and there gets sent into a double-ramp EW pit. That's the down ramp visible in the southeastern corner, the other ramp is simply a mined-out square on the level below with a EW track ramp constructed there. The cart gains a respectable speed from bouncing into and out of this pit, which is important for the operation of the device, the cart would otherwise take about 300 ticks to make one round with this input combination. With the speed boost it keeps the plate constantly active.

Input One - off
Input Two - on
Northern plate - off
Southern plate -on

Now to what happens when the first signal is on:
The cart will go straight through the western pit, emerges at significant speed but not enough to derail, is cycled through the southern path and sent to the eastern pit from straight south. If the second signal is off and the hatch closed, the cart will return to the south, but now follows the track corner, across the 'difference' plate, into the booster pit in the southeastern corner and back onto the return loop.

Input one - on
Input two - off
Northern plate - off
Southern plate - on

If the second signal is also on and the hatch cover of the second pit open, the cart zooms through the eastern pit as well and comes out north. As a speed limiter, the cart now bounces against a wall, rolls back 'down' the NS track ramp, is funnelled over the northern pressure plate and around the return loop again. Without the wall, the cart would _probably_ get too fast and do something weird (not just derail, i've seen carts bounce against walls and _return_ or go on tiny loops with no corresponding rails); i haven't tried this design without the bounce ramp. I actually introduced a second 'speed limiter' of this type in the southwestern corner, but 'disconnected' it when it showed that the cart would go so slow that it couldn't keep the pressure plate constantly active.

First input - on
Second input - on
Northern pressure plate - on
Southern pressure plate - off

The exceptionally designed gabbro statue of a goblin being struck down by a dwarven guard is crucial to the smooth operation of this circuit. I am sure of it.

[Larix]

Double post because things were getting too long:

two more designs:

Yet another dual-function logic gate, i think this one's called OR and NOR:

and without buildings

If both hatches are closed (two off signals, NOR), the cart bounces between both ramps (straight EW and straight NS), if either hatch is opened (at least one on signal, OR), it goes on the longer round. There's a speed limiter in the southeastern corner (wall and 'unusable' EW track ramp), if the upper left hatch is open, the cart otherwise goes ballistic.

And a practical (?) application, the 'wooden curtain', a super-simple minecart grinder:



Six 'barrels', each consisting of nothing but EW track, bounded by EW double-ramp pits. Put hatches over one pit, and you can start and stop the machine with a single lever flip. For extra safety (e.g. from building destroyers targetting the hatches) you can make a trench between the pits and the business zone, carts jump a single-tile pit without trouble. The return time of this setup is under 60 ticks for a full pass, consisting of two 'wipes', one from left to right and one right to left. Three in a row should be hard to dodge already.

EDIT: and as a postscriptum to finish the canonical logic gates, a combination AND/NAND one:
and without buildings:

Cart goes into the ramp stretch from right to left.

At heart just the AND gate shown earlier, just with alternative 'return' paths depending on whether the cart made it to the end of the two-ramp stretch (both straight EW) or not. Bounce ramp at the western end to keep speed sane, you can get different outputs depending on which of the two hatches is closed if you re-engrave the single tile between the ramps to be a W->N connection instead of a straight (or T-junction) bit. For the basic logic function, the branch off the western ramp's 'intake/return exit' isn't needed.

So that's the seven basic logic gates done with. Perhaps i'll even get an idea sometime to build something that actually needs them.

Edit:
And some more stuff. I heard people like repeaters, especially when they have a repeat time of 200 steps or slightly above and decently distinct on/off signals (so the signals don't get entangled and prevent the bridge from processing one of them). Of course, that's also possible with PMlogic (perpetual motion), and it shouldn't be a big surprise that it can get quite compact:

, paths:

I had actually set out for a 140-tick repeater, but the cart comes out of the pit so slowly and moves so _immensely_ slowly after hitting the bounce ramp that after some careful tick counting i hooked it up to a bridge. The cart goes clockwise here, passes over the hatch when it's closed, hits the ramp and bounces off it, goes south, falls into a booster pit, comes back out and passes the pressure plate linked to both the output and the hatch cover, falls into the now open double-ramp pit and keeps cycling in and out (W->N and S->W track engraved on the ramps) until the plate resets and closes the hatch again. The counted return time is 206 steps and the cart spends only one step on the plate, so it _should_ work o.k. for a bridge. I tried keeping track of the bridge itself and it _looked_ like it was working alright, but i couldn't properly count it because every time the bridge changes state, the game automatically leaves paused mode.

And something actually useful for my dwarfputing ambitions, a signal-to-pulse converter:



Takes a signal of any length (can be continuous) and converts it into a single once-on pulse that turns off after a hundred steps: when input turns on, both hatch covers open, the cart on the western hatch cover falls into an E-W ramp pit, bounces against the far wall and out to the east, potentially sending a pulse signal if a pressure plate is positioned on the single flat EW track, then falls into the northern tile of the NS-ramp pit and is sent out to the south, bounced into a NS pit (second ramp underground) to keep the cart under derail velocity and then sent around the course until the signal turns off again. That lets the cart bounce out of the eastern hatch-switched pit, and around the return track where it comes to rest on the hatch cover over the western pit, ready to take new input.

This can convert long-lasting input like from a pulled lever or calendar signals lasting for weeks or months and output a single pulse signal. The switch will also accept no new input until the signal operating the second hatch has sent an off signal. Obviously, the two hatches could be operated by different signals, e.g. to allow a 'reset' condition independent of the 'activation' signal.

[Larix]

And my final entry for what has become my repository of PML circuits:

The improved counter:

With buildings: Without:

Yeah, not easy to see what's actually going on. Paths in the ramps are: coming in from the southwestern corner - EW ramp, NES t-junction ramp (!), north of it a NS ramp. In the southeastern corner an EW ramp with another EW ramp on the level below ('underground'). The 'up' ramp seen to the east is a simple EW ramp with solid floor/ceiling above, it's only there to bounce the cart against. The pressure plate is located so that it sends a signal if the cart is ready to accept a new input, it could be positioned on the crossing to always send a signal as long as the cart is inside the cell instead. If the hatch is open, a cart will pass straight through the pit, if the hatch is closed, a cart entering from north _or_ west will only emerge to the north. Of crucial importance is the correct orientation of the hatched-over ramp. No other design will work for our purpose, others will have completely different effects or are completely dysfunctional. The cart will actually come to a stop on a cross track ramp when bouncing against the hatch: it takes its next move at zero speed and with no preset direction, and since two 'down' directions are available, it picks neither.

When a cart arrives in the circuit while the input signal is on, the hatch will be open and the cart will simply pass from west to east through the pit, bleed off excess speed in the underground booster and cycle around for another pass. Once the signal turns off, the cart switches to 'ready' status, bouncing between the up ramp and the closed hatch cover. Once the next 'on' signal arrives, the cart passes through the pit from north to south and leaves the array, e.g. to enter the next one, where it'll once again cycle around, waiting for the next off signal to prime it. This way, single-pulse signals can be counted, but also longer-lasting signals like levers pulled by dwarfs, without the counter just ticking on when the signal stays on for too long. Ticks of a clock could thus be counted very reliably, as long as there is enough 'cooldown' time between ticks and sufficiently long off signals - a clock with a base 'frequency' of 1/150+ ticks should be slow enough to be counted without missing pulses.