Print

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

[Larix]

I've been messing around with diagonally-moving minecarts. To my great pleasure, in spite of completely ignoring all engraved track directions, such carts still react to rollers they encounter and can thus still be directed and even caught in stable loops. So i built a large billard table in which to play with such carts in a reasonably safe fashion:



With the power supply (on the level above), this beast burns a bit above 1000 power. The primary testing took place in the left half of the table, so the return loop is better-secured here: there are rollers running around the outside of the whole contraption, grabbing the cart when it leaves the circuits and runs into the walls, safely conveying it back to the S->N roller at the bottom. Usually, the cart gets back to the start without the need for a vehicle hauling job, so i can just order another double lever pull to re-start it. On the straight S-N track, there are a handful of E->W and W->E rollers, to get the diagonal party started. I began with eight of them, but they don't interact in an interesting way. To the left, there are a bunch of loops, both large and small, including a genuine stable repeater with a period of 156 steps. To the right, there's the current highlight of the collection, a switchable memory device.



There are two basic kinds of closed loops, the larger one - the core of this array - a 3x3 diamond, and a smaller 2x2 diamond. The large one, put in a more readable fashion, looks like this:

Code: [Select]

..S..
.....
E...W
.....
..N..

And the smaller one:

Code: [Select]

.S.
E.W
.N.

Each roller noted with the direction in which it pushes. As should be clear, this device has no direction bias, a cart can circulate either clockwise and counter-clockwise, it depends entirely on the direction from which the cart entered.

So what i did was add a small redirection path to allow the cart to leave the main loop and re-enter it either in the same or the reversed direction. The reversal can be used as a "switch", the same-direction branch as a "read" branch.

The read is quite simple:

Code: [Select]

..s.
...S
e.....
.E....W

That's just the northwestern, "clockwise" branch. Capitals are the rollers of the actual loop. If roller E is switched off, the cart passes over it, gets redirected by e - to roller s and back into the loop.
With the low-speed rollers i used, this branch makes the orbit of the cart unstable, it will leave the circuit after ~200 steps. Sending the signal via a cart-activated pressure plate collects the read signal (between e and s) and returns to normal operation before the cart goes off course.

The "switch" is more complicated:

Code: [Select]

...s
..e.w
.e.n.
..w
.W

When roller W is switched off, the cart (going counter-clockwise) leaves the main loop going NE, gets reflected by roller w, reflected again by the southern e and then enters the eswn small diamond loop. Once n gets switched off, the cart leaves that loop to the southwest and returns, via w and W to the main loop, now going clockwise. I connected W and n to the same input, in opposite phase, so one cycle of the lever reliably reverts the cart's movement direction; it could be run by short-time inputs like pressure plates. There's an equivalent from-clockwise-to-widdershins reverter branch to the south.

I designed this thing a few days ago and only had to build it. Well, i also had to debug it for misbehaviour of the diagonal cart, but i got it to work much quicker than i had expected.
I'm rather doubtful of the practical use of a switchable memory device holding one bit and using twenty rollers and ten gears for the purpose. That's 108 power before including the power infrastructure on the level above. It stores information by sense of rotation, by 'spin value', if you will.

Second: Something a bit more practical (i think): the one byte memory.



These are two bits, the first (bottom) with the rollers and signal plate installed, above only the paths.

The cart enters from south and encounters a N->S roller linked to the signal plate itself. If the bit is on, the pressure plate is active and the roller is switched off. The cart will simply pass over it and keep the plate active. If the bit is off, the cart is diverted to the right and passes a second N->S roller. Now, if the bit has been ordered to be 'set', this roller will be active, so the cart is diverted to the left and activates the pressure plate (switching the southern roller off in the process).

Now, for the full installation, you'll want separate power supplies for the 'set' and 'bit' rollers, as well as an extra connection to the 'entrance' roller, to be switched on when a signal was received to turn the bit _off_. This way, the memory could be properly adressed (by switching power of the "set" logic on or off), preserving the content of the memory even when the set input changes (to set another memory cell).

So, this design, while nicely compact, isn't fully functional for actual dwarfputing:



I think it takes up to 200 power to gear up while all bits are set, around 150 during normal operation. An adressable version with set-to-zero functionality would take up about twice as much space and about a hundred extra power.

Third contraption: base seven counter/adder/thingy.

Pressure plates can detect every possible depth of fluid, so why not use it? The principle is quite simple: have seven tiles of storage, fill them entirely and get 49 units of fluid. Now destroying/removing the fluid from single tiles will leave you with an exact multiple of seven (in the remaining tiles).

"Dry" example: close three doors, 28 units of fluid (water in this case) would remain in the channel.



Spreading the remaining fluid over seven tiles again gives you fluid of the exact same depth as you had tiles remaining (would be four in the above case). So far, so easy. But how to measure it? - pressure plates are buildings and are mutually exclusive with all other buildings, to wit all which can destroy fluids (doors, floodgates, bridges). The solution is to use pumps - they will remove all fluid from a tile which contains at least two units of fluid.

Two channels feeding into pumps to measure remaining fluid:



Basically, the water in the seven-tile channel is pumped into a total of seven 'measuring chambers/tiles', each of which contains one pressure plate set to an exact water depth. Seven different water depths can be measured.

First design to the left - after the relevant doors have been closed, they are opened again and the remaining water spreads to equal depth inside the channel before the pumps are activated. Each pump delivers water to a single compartment and the depths in the compartments are reliably the same. The design is very unsatisfactory, since pumps don't pick up one deep water, so you cannot measure less than two and you can't add properly (if you add 4+4, all chambers will fill with seven water and one deep water will be left in the channel; once the measuring chambers have been emptied, the pumps still can't pick up the remaining water, so you won't know if the result of the addition was seven or eight).

Less screwy design to the right: the doors are _not_ opened again, so each tile of water that can be pumped is seven deep and is reliably picked up. The water level will even out in the measuring chamber (you get false signals from the initial sloshing, but those will time out normally). It reliably picks up and measures water from depth one to seven, and 'adding' a new channelful of water to an already-loaded pump array results in accurate addition. The downside is that you can't easily get one deep water out of your measuring channel.

For expediency, i simply smash the water to re-set the 'liquid memory':


The pumps draw water from the measure channels/chambers below when turned on. An on signal also opens the doors installed in the pump outlets, so the water can actually be placed there. Upon switching the pumps back off, the doors close and the water is gone. Since it relies on pumps, it cannot draw one deep water from the channel to the right; to clear such a memory, it'd be necessary to add another two depths of water (to compensate for possible evaporation) and pump+smash the resultant three-deep water.

EDIT: Hmm, i think i'm gonna retire this fort now. Getting somewhere with diagonal carts was the main project, the byte memory was just a thing that'd been buzzing around in my head for a while, and i'm reasonably satisfied with the current state of the fluid portioner. Better go and find a good place for the ... other project: midair minecart collisions.

[itg]

Good stuff, as always. How do you get a minecart moving on a diagonal in the first place? Derail it onto a perpendicular roller, maybe? It's not something I've messed with.

[Larix]

There's no pre-derailing necessary:
Say, we start with a S->N roller, then you simply lay out a plain straight S-N track (can be with crossings, doesn't matter) and put perpendicular (E->W or W->E) rollers on it. There are some weird edge cases where a cart _doesn't_ go off the tracks after hitting the perpendicular roller, but usually just those two rollers in succession are enough, you can build them directly adjacent and run them off a single gearbox. Movement angle and speed can be adjusted by selecting the speeds of the rollers (only when building them). It's also possible to cause diagonal movement with ramps - e.g. run a cart on an E->W track over a track ramp with an "exit" only to the north (typically S->N, wall to the south, so this one happens with track jumping). Once on the diagonal, it doesn't seem to react to other track ramps, though, you'll need to use rollers for further movement control.

The fun thing is that a diagonally-moving cart just doesn't re-rail again, to make it behave normally again, you'll have to smack it into a wall. Diagonal carts can be 'reflected' off rollers, but will bounce off at an angle. That's why a 'latch' loop requires four rollers, while a normal, straight-moving cart can be held with a single roller.

I'm still not sure if diagonal carts have any potential for serious applications, but at least i managed to prove they're controllable.

[smirk]

Question: When a diagonally-moving cart smacks into a wall, does it tend to stop or does it bounce off the wall at an angle?

I'm thinking - if they bounce off - then you could put a whole lot of rollers in a big room, aimed in varying directions and built at various speeds, and put enough minecarts in there that they would bounce around diagonally off the rollers and walls and each other to create a sort of limited brownian motion generator. Theoretically useful to generate random numbers or just reroute sieges through and bet on how long they last =D

Probably being too hopeful. Excellent research, nevertheless!

[Larix]

When running into a straight wall, the cart generally stops, although i've seen a few cases where it bounced off a pillar or other wall "edge". I found that completely impossible to design/plan, so went with the plain old return rollers. If two carts collide, it's also the norm that one of them will stop entirely (that's the case for both linear and diagonal minecarts, in case you wondered).

Diagonally moving carts in general are some kind of poorly implemented edge case, they ignore track directions entirely - including ramps, as far as i can tell - and in general are an order of magnitude harder to control; cf. 'orbital decay' when my memory device had the 'read' loop open too long. I also had to exchange my starting roller for one with lower speed and install two more 'regulator' rollers at the input corner so that the stable loop was established in the first place.

I'll definitely keep diagonal trajectories in mind - they offer additional options for logic switches and might actually be moderately useful as multi-value selectors. Although the main attraction is that a diagonally-rotating cart looks nice and gives some bragging rights