User:Larix/MPL/1

Foundations: intensely boring minecart physics

Be warned! This stuff was far too dry to inflict on the extremely dry and long-winded Minecart article.

Gaining Speed

Minecarts can receive speed from installations on a track in two ways, from rollers and from ramps. They can also get moved in the course of "route" handling, being pushed, ridden or guided by a dwarf, but guided carts largely ignore terrain and pushed/ridden carts require the presence of a dedicated labourer on the site for each such action, which is rarely desirable in dwarven computing. Moving a cart via "pushing" it is nevertheless useful to test small circuits without the need to build powered machinery or linking up levers for a starter mechanism.

Rollers are pretty straightforward: they increase a cart's speed to the roller's "operation speed", in the roller's movement direction. Operation speeds are:

lowest - 10.000
low - 20.000
medium - 30.000
high - 40.000
highest - 50.000

Minecart speeds are calculated in 1/100 000 tiles per game "step". A highest-speed roller will impart a speed of half a tile per step. Higher speeds can only be achieved through gravity (ramps, usually) but go all the way up to 270.000, between two and three tiles per step. That's over five times the speed imparted by a highest-speed roller.

There are a few not-so-obvious caveats concerning rollers:

Rollers only increase, never decrease speed. A cart moving in the roller's direction but faster than the roller's operation speed will be unaffected.
Direction is important. A cart moving "against" the roller's direction is effectively moving at negative speed in the roller's direction, so the roller will attempt to "increase" its speed in its operative direction. This is done by substantially reducing the cart's movement speed (apparently by 100.000), and if that lowers it below zero, movement will be reversed, sending the cart off in the roller's direction, at the roller's speed.
A cart encountering a roller working perpendicular to its movement direction will still have its movement speed increased in the roller's direction, while the cart's movement speed in its original direction will remain unaffected. The result is a diagonally-moving cart. This feature is easiest to imagine by assuming minecarts' movement is calculated separately on the three spatial axes. If a cart is moving with some speed on the x-axis and encounters a roller also working on the x-axis, the roller will only change the x-movement parameter and nothing peculiar will happen. If the cart encounters a roller working on the y-axis, the roller will "set" the cart's movement speed on the y-axis, without changing the x-movement parameter. The cart will now have non-zero speed on two axes. That's problematic, because minecart tracks only have entrance and exit connections in the four cardinal directions, and a cart will only follow the paths prescribed by track tiles it passes over if it entered the tile from one of the tile's "entrances"; tiles simply don't have diagonal entrances, so a diagonally-moving cart will never enter a track tile from a legal direction. The upshot of this is that as a rule, diagonally-moving carts will completely ignore engraved tracks (including track ramps, meaning that launching or accelerating them via ramps becomes almost or entirely impossible). Carts moving diagonally on an angle significally different from 45° can re-join normal tracks if they encounter a properly aligned track corner; this can be used for some rather esoteric minecart switches, but takes very carefully set-up tracks and rollers.

Ramps change carts' speeds by subjecting them to gravity. A cart going across a track ramp will be accelerated when moving down and decelerate when going up. So far, so obvious. However, the exact rules get rather complicated:

movement across ramps introduces movement on the z-axis. Effectively, it's a kind of diagonal movement, which makes the actual speed calculations and movement patterns on the ascent/descent branch rather strange. Incidentally, it's entirely possible to impart non-zero speed on all three axes to a cart, easiest (for rather peculiar values of "easy") by sending two high-speed carts across ramps to launch them so that they collide in mid-air.

a ramp will only provide acceleration if it has an actual "up" and an actual "down" connection - at least one "branch" must touch a wall, exactly one a "non-wall". A ramp not so connected will provide no acceleration (except for some peculiar cases with one-connection ramps). A cart will accelerate if it is moving towards the "down" connection of the ramp, regardless of where it came from.

This is the basis of "impulse ramps" - a cart moving to the north and passing over a track ramp connected to a wall to the east and with a proper "down" connection to floor to the north or west will accelerate, even though the cart clearly didn't enter from above. A cart set down on a legal ramp will roll "down" the ramp, gaining speed from a complete standstill.

To make matters even weirder, distance calculations when coming off ramps are strange and buggy. The cart will "teleport" through most of the next tile. Since acceleration/deceleration on ramps is calculated per game step, the resultant reduction of lingering time on "neighbouring" tiles will massively reduce the deceleration experienced on up ramps directly adjacent to down ramps, to the point that a cart standing inside a pit consisting of two adjacent track ramps will first gain speed by going down one of the ramps and lose so little speed on the up ramp (thanks to the teleportation bug) that it will lift itself out of the pit and move off at a substantial speed. As a minor adjunct, the cart will typically also spend next to no time on the tile just outside the pit after ascending.

By abusing those bugs, carts can be set in motion and kept moving, and their speed can be regulated to the desired range. Keep in mind that sequential ramp accelerators can accelerate carts past derail speed, causing the vehicle to jump out of the pit, potentially colliding with the ceiling or walls and refusing to enter later pits.

Basic pathing rules

Minecarts are completely deterministic. If two carts encounter an identical pathing situation with the exact same entrance parameters, they'll behave absolutely identically. There are no known components of chance involved. This doesn't mean carts cannot behave in unexpected ways - the fundamentally three-dimensional nature of minecart movement and a variety of behaviour possibilities like "derailing" or track-skipping can lead to very strange paths chosen that will reliably occur given identical starting conditions but are often infuriatingly difficult to understand.

On flat track, a cart will generally keep moving in a straight line. It can only change path by moving over a corner track tile - with exactly two connections - properly connected to the tile the cart is coming from. I.e. a cart moving from south to north will keep this direction unless it encounters either a SE or a SW corner tile. It will of course stop if it encounters a wall or other solid obstacle and may revert or go on a diagonal if it passes over an active roller. Carts moving very quickly will ignore corner tiles unless the straight path is blocked by a solid obstacle, like a wall or door. This feature is called "derailing", although it's also often applied to the habit of carts moving in a straight line past track ends or over T-junctions. That's quite misleading, because ignoring a legal corner has a very high speed requirement (>50.000, otherwise a corner will always be respected - rollers cannot cause derailing by themselves), while track jumping has no speed requirement at all and only happens when there's simply no legal track available any longer.

On ramps, pathing gets a bit more complicated, not only because the cart's moving in an additional dimension while still observing track directions. Pathing becomes much more speed-dependent as well.

As has been mentioned, a ramp will cause acceleration if it is both "up"- and "down"-connected. Only one down connection is allowed, a track ramp with more than one "down" connection will not accelerate a cart. More than one "up" connection, however, is perfectly acceptable. A track crossing can accelerate a cart just fine if three of the connections touch walls and only one a floor or hole.

If the down direction is perpendicular to the cart's entrance direction, the cart will start moving diagonally. Whether such diagonal acceleration sends the cart on a diagonal trajectory (usually causing it to slam into a wall and stop), fails to move it off its path or bends it around a corner, depends on the entrance speed and architecture of the circuit.

Carts will jump across open pits even at fairly low speeds, but will always enter a pit containing a (track) ramp when coming from a floor tile or bridge and moving at less than 50.000 speed. Carts going faster than that cannot enter a downward ramp when coming from a flat tile. They will go down the ramp if they already came from a down ramp, a long straight sequence of nothing but downward ramps works perfectly fine. Corners on track ramps can cause the cart to "miss" the next corner or ramp, slam into a wall and stop, however.

Carts going up ramps will emerge with some amount of vertical speed. This can lead to carts bumping into the ceiling (and stopping) or jumping past engraved tracks on the tile just past the ramp. This can even happen when a derail-speed cart fails to take a downward ramp - jumping past the ramp opening seems to grant a small amount of "lift".

Basics of track switching

To do anything with logic, we need something that reacts differently to different "inputs". In the case of minecarts, the different reactions can take the shape of moving or standing still, but also of a choice of path, where different inputs result in different paths taken. Input generally takes the form of signals or power, and there are various ways to turn such an input into a pathing choice. A simple and very versatile switch mechanism is the roller: it acts directly on the movement parameters of a minecart, so of course it can affect the path the cart takes. The roller-driven track switch is in fact shown as the first option in the "minecart" article. The most effective design makes use of the fact that rollers working against a cart's movement direction will reliably turn the cart around. By combining this path reversal with a lowly track corner, a cart can be made to branch off its original route. Since rollers are driven by power, adding gear assemblies to the power train is simple, providing a very natural interface with mechanical logic. Switching rollers can also be placed perpendicular to the incoming cart's direction, but since that causes diagonal movement, it requires either clumsy restraining walls or a very complicated "catching corners" setup.

Tracks can also be switched by "overwriting" a corner with a straight pseudo-track by opening or closing a bridge. Bridges are treated as all-directions track by minecarts and will overrule the directions of track engraved into the floor beneath when extended/lowered. We would construct a bridge on top of a track corner (one tile is enough, but larger bridges may offer additional options) and extend/retract it by our input. The cart will follow the corner when the bridge is raised/retracted and move in a straight line when the bridge is lowered/extended. Other "above floor" building types like hatches (and presumably bars and grates) will not overwrite track directions when closed.

Buildings that serve as obstacles in a cart's path, like a raising drawbridge, a door, floodgate etc. will, if put in the way of a straight-moving cart, simply stop it. Combined with a roller, they can still be used in logic to introduce a delay and if you're working with very fast-moving carts, they can be used as another type of switching device by putting it directly behind a track corner. The fast cart will ignore a corner and continue in a straight line if open floor is available in that direction, but will follow the corner if the straight line is blocked. Opening/closing the door or other building will thus switch the cart between going around the corner and going in a straight line.

Path-blocking buildings can be used in another switching schematic, too, by combining them with ramps to accelerate carts stopped by the obstacle. This is the basis of this entire logic discipline.

Combining ramps with path-blocking buildings

A cart encountering a solid obstacle on its course will entirely stop moving in this direction. With the ability of ramps to provide acceleration to any minecart touching them, carts can be made to return from such collisions: construct the obstructing building immediately behind a track ramp; a cart that cannot pass will "roll down" the ramp after stopping and gain speed in the ramp's downward direction. For logic purposes, this will usually be the "return" direction, away from the obstacle. The return path can also branch the cart away from the actual origin location. If the obstacle can also be removed/opened at will, a cart can now either pass through or return, meaning we can have a single "input" direction and two different "output" directions, and the cart will reliably take one of those two depending on the "signal" governing the obstruction. Doors, hatches, grates, bars, bridges and floodgates all serve as obstacles to minecarts and can be switched between open and closed by levers or pressure plates. Using them, we can switch minecarts between different paths (in binary fashion).

Hatches are a very convenient tool to switch paths of incoming minecarts: they react instantly to received signals and are easy to build. The most reliable switching method is to put the hatch cover over a ramp a cart is trying to pass from below. In this case, the cart will never be in the same tile as the hatch: if the hatch is closed, the cart will bump against it from below and roll back down the ramp. If the hatch is open, the cart will pass directly from the ramp tile below the hatch to the floor tile next to the ramp and hatch.

Alternatively, a hatch can be put over a ramp and the cart's path routed across the hatch itself. If the hatch is open, the cart will instantly dive into the hole (as mentioned above, a horizontally-moving cart will treat a downwards-leading track ramp as a track corner and will not jump past the hole but dive into it, provided it is moving at less than derail speed); if the hatch is closed, the cart will pass over it in a straight line. Hatch covers have the same friction as not-engraved floor. Except in case of very slow-moving carts, this higher friction is irrelevant. Should the hatch open while the cart is directly on top of it, the cart will not enter the ramp in the normal way, but rather loses its entire forward momentum and "falls" into the pit. It will pick up speed from the ramp it lands upon, but may behave differently from the usual cases. A hatch cover over a ramp is also a very convenient signal-operable starting mechanism for minecarts. The cart is simply placed on top of the closed hatch cover and gets dropped onto the ramp below when the opening signal is received.

Design: from the side:

  H__
__/#

from above: closed hatch:

.¢==

open hatch:

.▼==

Doors also react instantly to signals but require an adjacent wall to be built. Constructed walls can be deconstructed after the door is built, this will not impinge the efficiency of the door. To switch tracks in combination with ramps, the only applicable use of doors consists of placing the door on the level floor right next to a ramp-hole a cart tries to emerge from. If the cart encounters a closed door while trying to ascend, it will fall back into the hole. This design works similarly to the first application of hatch covers. It can probably cause an operation error when a door receives a close signal the very same instant a cart is passing through it. I have not yet seen it happen, but if it happens, the door should get wedged open in spite of the signals indicating it should be closed and the cart should get stuck in the door, stopping it dead.

Design: from the side:

   D_
__/#

from above: closed door:

.▼D=

open door:

.▼==

Floor grates and floor bars should work similarly to hatches, flood gates, wall grates and vertical bars similarly to doors, with the notable difference that each of these buildings has an added 100-step delay before reacting to a signal. Apart from designs hinging on specific delays before releasing a cart or switching a track, those buildings are largely useless for our purposes.

Raising bridges can be used in the same way as doors, but react in opposite ways to signals: a raising bridge switched "off" will grant passage, when switched "on" it will block passage. Retracting bridges work like hatches, but can span larger gaps than the one-tile hatch covers and provide less friction. Bridges take 100 steps to react to a signal and will throw, hurl or crush a cart passing over them while they change state, sharply limiting their usefulness in logic.

Logic, building blocks: Operative ramps

I built most of my pathing logic with double-ramp pits, with hatches over one of the pit exits to switch the paths while providing sufficient speed to keep the carts in circulation.

The simplest design is the straight double ramp:

from the side:

__..__
##\/##

from above:

upper level:

==▼▼==

bottom level:

##▲▲##

track on the ramps: == (EW)

I'll go through the possible cases assuming first a cart coming from the west:

If the exit is open, the cart will roll down the ramp, accelerate and emerge on the other side, continuing east, at increased speed.

If the exit is closed, the cart will roll down the ramp, bump into the obstacle (hatch/door/wall/ceiling) and gain speed from a standstill on the eastern ramp. Due to ramp teleportation, that will give it enough speed to emerge from the pit again and return to the west.

If a cart falls into the pit, either coming from the north or south or dropped (say, by opening a hatch cover it was sitting on), it will accelerate on the pit it fell into and emerge from the adjacent pit. A cart falling into the western pit will try to exit to the east.

Of course there are all kinds of exceptions for particularly fast- or slow-moving carts as well as for carts that enter the pit on a diagonal trajectory.

Another very simple but somewhat less predictable design is the "loop ramp":

from above:

top level:

=▼
=▼

bottom level:

###
#▲#
#▲#
###

engraved track on the ramps

╗
╝

A cart arriving on the northern track will roll into the northern pit, gains speed on that ramp, teleport-lifts out the southern ramp and leaves on the southern track. Alternatively, it will not gain the proper kind of speed on the first ramp, thus will not get off the southern ramp but accelerates off this ramp too, lifting itself out of the northern ramp and returning along that track. I don't know at which point the behaviour switches between passage and "back-swing", but i'm certain this behaviour is caused by the fact that the ramps accelerate the cart in direction perpendicular to its entrance trajectory and cause a degree of diagonal movement. Consequently, the walls around the ramps on the bottom are required for safe operation, if there is a breach in the walls, the cart may jump through the hole.

A hatch cover or other means of blocking the exit from one of the ramps will ensure a cart will return on its path, which is evidently only an actual switching method if the cart would have passed through originally.

Other means of combining pairs of ramps in a single two-by-one pit aren't functionally different from the above two.

It is possible to build functional ramped pits larger than that, although one must keep always in mind that to provide acceleration to a cart a ramp must have at least one wall connection and _exactly_ one "down" connection. Ramps with multiple wall connections work adequately, but a ramp with more than one downward connections will not accelerate carts; apparently the game needs a definite cardinal direction to accelerate a cart towards, if two or three directions are offered, the engine decides to pick "none of the above".

The movement pattern inside larger pits can easily become too complicated to base logical operations on, the largest pits i worked with contain no more than three ramps. There's a lot of potential there, both for fiendishly clever devices and immense operator frustration.

Two examples for ramp oddities, out of many

The plain straight ramp can behave in unexpected ways when there's empty space above:

=▼▼╝╗
..ABC

The cart enters the pit from the west. If there is a solid ceiling above the circuit, the cart will emerge going east and take the track corner at location B. If there is empty space above the tiles A and B, the cart will jump over the first track corner and take corner C. If there is a wall in location C (e.g. in an attempt to constrain the cart's movement and force it to take the corner at B), the cart will hit the wall and stop. Unfortunately, this only happens if there is actual open space above, any buildings above the squares like hatches or floor grates will count as closed ceiling, even if the buildings are opened via lever.

The diagonal movement induced by angled track ramps can be used to throw carts through narrow wall gaps into adjacent pits:

=▼║  =▼║   ╗
=▼║  =¢║   ╝
  ▼    ¢    ║
  ▼    ▼    ║
  ║    ║

Left upper level with open, middle with closed hatches. To the right the engraved tracks on the ramps.

A cart entering on the northern E-W track rolls into the northern pit of the looped pit and gains a degree of diagonal movement. If the hatch cover over the southern pit of the same ramp is open, the cart will jump through the gap onto the northern ramp of the straight pit. If the hatch cover above that pit is open, the cart swings south without leaving the pit, then back north again and out of the pit on the straight northward track. If the hatch on the straight ramp is closed, the cart first swings south and back north again, cannot leave the pit to the north because of the closed hatch and accelerates southward again and finally leaves the straight ramp towards the south. If the hatch cover above the southern ramp of the looped-ramp pit is closed, the cart does not jump through the gap into the straight pit but rather bumps against the hatch and exits the looped pit on the northern track, going back west.