Print

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

[Larix]

I just tried it out, and the checkpoint-chain works as an arbitrary-length escalator, too:
the test build spans 99 z-levels, and the cart moves up/down at one z-level/tile each step, running off a single dwarven push and perfectly ride-safe. It requires a straight line without corners and it's easiest to just make the ramp two tiles wide. All we need is alternating slant, so on the slope we simply alternate forward ramps with sideways ramps - that's why it must be two wide, the sideways ramps need non-wall to accelerate to. To handle the offset, you must swap the directions of sideways ramps every dozen ramps.

Track on the ramps is just alternating between these two - going west up<->east down as actual slope:

Code: [Select]

z
87654321
####....
═╣═╣═╣═╣
....####
all track on ramps, each on a new level (not feasible to display here)

i.e. one ramp in line with the overall slope, one ramp across with wall on one side and floor on the other (wall N - floor S/wall S - floor N), additionally attached to the "up" direction of the slope. Upon trying to go up, my carts wouldn't recognise a sideways ramp without an in-line up connection. That extra link doesn't hurt the ramp functionality, because it's just a secondary wall link, the slant remains the same - towards floor. After two correct empty runs, i let a dwarf ride it, and she made it thrice down/up all the way without issue.

This function might depend on the cart's internal speed, but i think regulating speed shouldn't be too much of a sacrifice - a working ramp of this kind will be traversed at one level per step regardless of internal speed, so you won't lose anything by, say, braking the cart down to a low input speed if that's what it takes.

If you want to cross a hundred levels without going a 100 tiles to the side, you could split such a ramp up into two equally long/high checkpoint ramps and link them through a pair of flat-track corners. Use the basic double-ramp pit for the initial push from below and on the "halfway station":

Code: [Select]

####      ####
#▲▲#      #══#
####      ####
it's passable in both directions and either gives you an easy starter checkpoint going up or safely picks up the descending cart.

PS: as a further practical application, checkpoints can be used to force and limit presence of a minecart on a tile, which is of interest when using minecarts to trigger signals. A very fast-moving cart can cover several tiles per step, skipping over some tiles. Track-operated pressure plates will not trigger if a cart skips past them. That can be avoided via checkpoint: build an impulse ramp directly before the plate. Regardless of cart speed, it will touch the tile and will be checked against the plate's settings.

At the same time, a cart will only ever spend one step on a checkpoint tile (unless it's so slow that it actually stops there). A pressure plate in such a tile will thus only be occupied by the cart for one step, which means it'll recover and send its off signal precisely 100 steps after the on signal. Buildings with a 100-step reaction delay will ignore incoming signals while on an activation countdown, and that includes the step during which they actually switch. Thus, you can use a checkpoint pressure plate to "toggle" a bridge, floodgate, grate or built bars.

The simplest checkpoint pressure plate setup would look like this:

Code: [Select]

...#...      ...#...
═══▲^══      ═══╚═══
^ - pressure plate
Cart comes from the west and moves east.

The practical example which made me aware of the possibility to toggle bridges via checkpoint-regulated carts was the werebeast-powered lunar calendar:
http://www.bay12forums.com/smf/index.php?topic=131179.msg4609004#msg4609004

[TheHossofMoss]

Nice =D

[Billy Jack]

Very nice, indeed.  I've just started trying to use minecarts to reduce the amount of stone hauling from the outer reaches of my mining ops.

[Max™]

Hmmm, that's not the elevator design I like to use.

Z+0:
^
||

Z+1:
==^

I draw the tracks onto the ramps then undesignate the actual ramp square, and repeat so they connect from the top down but not the bottom. One push and it hauls stuff safely up absurd numbers of levels and stops smoothly for dumping/returning down to the bottom through a drop shaft.

I assume it's part of the checkpoint effect, I thought it was listed as a reverse-impulse elevator on the wiki though, I just know I went with it after a fun experiment involving trying to set up a long ridden track section that led to tons of hilarity (I'm laughing just thinking about when I figured out to step through it and watched the dwarf hop on and hang on for dear life until it derailed and flung him 5 or 6 tiles before he grabs the cart, takes it back and does it again) and decided I prefer the non-impulse ramp methods.

[Larix]

You're using ramps that are only connected to the "up" direction, which indeed causes a kind of "ramp that doesn't count as a ramp" effect. I mentioned that one, too, but it probably got lost in all that text.

A ramp that doesn't fit specifications for a "proper" track ramp (at least one "wall/up", exactly one "down" connection) is treated as flat floor. If such a ramp is connected "up", carts can use it to climb up to higher levels but the game engine treats them as travelling over flat floor. Since a single dwarven push can move a cart 200 tiles of flat track, it can also move a cart up a 200-tile slope of "flat" ramps.

Adding "full" ramps to make use of checkpoint effects just means you can make the cart travel much faster. They tend to make construction more complicated and prone to dangerous malfunctions when anything was mis-designed, though. The "reverse impulse" solution is quite safe - even in case of a collision somewhere on the slope, the cart will harmlessly stop where it is, because none of the ramps have a legal "down" direction they'd accelerate a cart to.

[WanderingKid]

Lesson Six: False ramps
If a ramp connecting levels doesn't cause friction, you can change level without losing/gaining speed (apart from ordinary floor friction). It's decidedly weird - my constructions only work when the cart enters at very low speed - around that of a dwarven push - but a single push can move a cart up/down 40+ levels without notably changing the cart's speed. Example: http://mkv25.net/dfma/movie-2653-minecartescalator (o hey, it was 47 z. You can safely speed past the end, i just showed that each ramp was a non-functional E-only one.) It's of course also possible to do this without dwarven labour, you just need sufficiently regulated cart speeds from proper ramps or rollers, if needed combined with a few track stops. A super-low-tech and low-risk way of lifting a cart up a huge number of levels.

Larix, how did you carve these 'improperly carved' ramps?  Did you simply not continue them in both directions? For example, on each level you only set a Track carve from the ramp to the east and nothing to the west?

[Larix]

Exactly - i designated a job carving track from the tile itself to the wall on every level.

Each ramp showed "E" as direction. A proper ramp that accelerates/decelerates would show "EW" and i'd order it with a single designation going from the "hole" west of the ramp to the wall east of it. For completeness: on such a straight west-down -> east-up slope that's a single tile wide, "corners" on the ramps (NE, SE) would also all count as flat track, because they'd just link wall to wall. Such a track layout would be useful to build one-way ramps that stop carts coming from the wrong direction (down/from the east - carts going to the east/up would pass unhindered).

The "flat ramps" quirk had actually been found and reported by someone on the old "How does Minecart" thread years ago, it was just largely ignored.

***
Hm, in light of my recent finding that rollers actually seem to apply a straight 100.000 units/step acceleration, moderated by simple caps, would there be some hack to remove the caps from rollers? This might allow building a largely unlimited-speed cyclotron that could speed up a cart until it rotated fast enough to take 90 corners per step (going over 270.000 speed "only" imposes a general 10.000/step friction, it's not a hard limit), with a theoretical maximum of about 68000 tiles/step; although the speed variable might overflow before getting there.

[Bearskie]

This is more than just !!SCIENCE!!; its a fully fledged Dwarven university course.  My highest commendations to you and your masterwork research

[Larix]

Postscriptum: Corners, how do they work?

(Open for refinement/correction, as always, i'm just presenting my findings)

Let's start by grossly simplifying the way a tile is presumably handled by the minecart routines: we assume a tile divided into 100 by 100 sub-co-ordinates (i.e. 100 centitiles "wide" and 100 "long"). Sub-coordinates of the corners are 1/1, 1/100, 100/1 and 100/100, with 50/50 being the centre. A minecart "occupies" the full tile, but its actual location _on_ the tile is identified by a sub-coordinate of specific width and length. A cart leaves a tile when its sub-coordinates go "out of bounds", i.e. above 100 or below 1.

Spoiler (click to show/hide)

 This is all simplifying and assuming a lot
- the game presumably works with 1/100 000 tiles as basic length
- an even-numbered range has no individual middle value
- i don't know the details of how a cart's location within a tile is tracked by the game's mechanics; i only know that some tracking is taking place and the given model explains the observable effects reasonably well.
Aside: ramp tiles are of course 140x140 centitiles.

Thus, in a grid of three by three tiles like this:

Code: [Select]

+---+---+---+
|   |   |   |
| a | b | c |
|   |   |   |
+---+---+---+
|   |   |   |
| d | e | f |
|   |   |   |
+---+---+---+
|   |   |   |
| g | h | j |
|   |   |   |
+---+---+---+

a cart moving across tile "e" would stay on this tile as long as sub-coordinates are in the 1-100 range on both axes and (counting west-to-east and south-to-north) would go to tile "b" if SC went to 50/120, to tile "f" if SC became 130/60, or to tile "g" if SC became -40/-20.

Which influence do track directions have on the cart's movement? If they aren't corners, none at all! If our cart is moving south-to-north across tile "e", it doesn't matter whether that tile has EW, NS, NSE, SEW track, the cart behaves the same in all cases. Similarly when the cart moves diagonally - "straight" track doesn't "straighten out" a diagonally-moving cart. Non-corner track is primarily a "this is track" marker - rollers and pressure plates on the tile can affect/react to carts, carts moving across the tile towards a downward ramp will try to dive into the ramp. For those purposes, the exact direction of the track is entirely meaningless. Dwarfs "guiding" a cart will follow engraved track directions, that's the only influence non-corner track has on pathing - notably, it affects only the pathing of a _dwarf_.

For an explicit example of diagonal movement: the cart moves at 40 centitiles/step north, 15 centitiles/step east, enters tile "h" in the middle of the southern side (50/1). In the first step, the cart moves to subtile 65/41, in the second to 80/81, in the third to 95/121, i.e. leaves to tile "e" and occupies subtile 95/21 there; on the fourth step, it moves to 110/61, i.e. leaves to tile "f", subtile 10/61, on the fifth step it goes to 25/101, i.e. subtile 25/1 on tile "c", which it leaves on step eight.

What we see is the cart spending three steps on tile "h", then apparently moving one step north, then one east, then another north and taking another three steps to leave tile "c", again to the north.

And yes, the exact track layout on those tiles is completely irrelevant, unless there are corners involved.

So, what about corners?

Let's put a corner track on tile "h", sticking to our diagonal-cart example. First of all, if the corner doesn't "block" the direction in which the cart tries to leave the tile, it's again ignored. A NE or NW corner does nothing to the cart. So let's go with a SW corner. On step 3, the cart tries to leave the tile, crossing the northern border at 80/100 (going to /121). The corner prevents that. The cart now leaves to the west (on step three), to tile "g" - in the middle of the eastern border of that tile (emerging at 100/50 on tile "g" but using up the remaining distance units, reaching 79/50 at the end of the step), going straight west at 40 centitiles/step (put differently, at a speed of -40 on the W->E axis).

What happened? According to my tests, the corner is not modelled within the tile, the corner test takes place the moment the cart tries to leave. If the corner comes into play, the cart is "teleported" to the corner-dictated exit co-ordinate, which is the middle of the target tile's border. In addition, only the speed component in the direction the cart tried to leave is preserved, converted into movement in the new direction: in the example, northward speed is converted into westward speed, eastward speed is dropped. The speed conversion is more obvious when applying a corner to the "weaker" movement component: a NW corner on tile "e" would bend our cart to the north (it tries to leave east, eastern direction is blocked by the corner) - going at a speed of 15 centitiles/step: the 15 c/s eastward speed get converted, the previous 40 c/s northward speed disappear.

The corner only affects carts trying to leave towards the corner's two "blocked" directions. If our given diagonally-moving cart finds a SE corner on a tile it tries to leave to the east, it keeps its diagonal trajectory. The game doesn't check the northward movement component against the status of the northern tile border, it only checks the border the cart is actually trying to cross. In addition, a cart leaving to a diagonally adjacent tile isn't affected, either: a cart with the same starting location but moving 40n + 20e will leave tile "h" on the third step, as above, but with a target subcoordinate of 110/121, i.e. tile "f", northeast of "h". A corner, no matter how aligned, will have no effect.

More fun with sub-coordinates

The exact location of a cart within the tile influences cart behaviour in various cases and is pretty persistent: a cart crashing into a wall will come to rest pretty much scraping on it. If it's again set in motion by rollers or a cart collision, this "hugging the wall" alignment persists and the smallest diagonal shift can push the cart across the border. Carts driving up blocked ramps and bouncing off the wall/blockage and rolling back down will keep their lateral sub-coordinate. Carts blocked from going around a corner will stop at the border they tried to cross, not at a location related to their corner exit:
Cart moves w->e, over a NW corner, but finds a door blocking the northern path. The cart doesn't stop at the northern, but rather at the eastern border of the tile. If it's subsequently pushed north by roller or other cart, the tiniest eastward push will move it to the next eastern tile.

All this also affects ramps to some degree - carts bouncing against walls and rolling off a lateral ramp, banging against a ceiling or other obstacle and the like. Corners on ramps have their own peculiarities, but they observe basic corner rules.

Dwarfs re-set carts to the centre of the tile when handling them. A push to the north basically teleports the cart to 50/50 on the next tile north (or 70/70 if that tile is a "full" ramp).

PPS: if a dwarf rides a cart, observable cart weight changes to that of the cart plus dwarf (including all worn items). Interestingly, the weight is not properly cleared after a ride. An empty wooden cart weighs 24 before a dwarf rides it, ~120 after. If another dwarf rides it, the new weight is properly calculated and carts revert to their proper empty weight eventually, but it usually takes a while.

EDIT - a quick heads-up on ramps and pathing:

I've treated ramp acceleration and several effects with them, but neglected the rules of carts pathing to different z-levels via ramps.

I strongly suspect that ramps are internally modelled as plain flat floor with a few extra rules. The sub-coordinates probably only use the two (x- and y-) dimensions, while "height" is _not_ tracked in this fashion when moving on ramps. Notably, gaining or losing speed on ramps is not done by converting a presumed intra-tile height into speed, there's simply an "accelerates toward <direction>" tag on full ramps, and such acceleration is simply applied to a cart as long as it is on the ramp.

Flippantly, we could claim that "impulse ramps" don't really exist (or that all ramps that provide acceleration are impulse ramps). Ramp acceleration just isn't connected to z-level changes.

When leaving a ramp tile, a cart may simply move on to an adjacent tile on the same z-level. This is fairly uncomplicated, it's rather like the normal way a cart moves from one tile to another.

A cart moves from a tracked tile to a lower z-level if there's no solid floor in the direction it's going in, but rather a "downward ramp" (i.e. an open air tile with a ramp below it). If the tile the cart comes from is not track/bridge but plain floor (or e.g. a hatch over open space), a downward ramp will not be followed, the cart jumps instead. If the cart is moving at derail speed, it will not follow a downward ramp if it's coming from a flat track tile or bridge. It will follow the ramp if it comes from a full ramp (i.e. one that can accelerate carts).
The layout of the ramp on the lower level doesn't matter for the path choice. Carts path to properly connected track ramps just like they path to ramps with poorly fitting track or in fact non-track ramps.

Carts can also move _up_ z-levels, and moving up levels while on track seems to absolutely require ramps. It appears that the game engine checks in the direction the cart's trying to move in, and if there's a wall there on the same level but open floor on the level above, the cart may move to the upper level if it's currently on a ramp that has a track connection in that compass direction. For that upward movement, only the existence of the track connection is required: a "dead end" track branch going North will allow carts to climb up to the north - and doesn't slow down the cart while it goes up. If the ramp has no track connection towards the potential way up, the game treats the direction as a solid wall and disregards the open floor on the upper level. A simple pit in the floor containing a track ramp with some "blank" direction:

Code: [Select]

..║..   
..║..    ###
..▼..    #╩#
..║..    ###
..║..
z+0      z-1

can be passed freely in some directions, but not in all - in the shown example, a cart coming from south can pass, one from east or west will jump over the hole (don't come from track), a cart from the north would move into the hole and stop there. The cart's speed will also not change while going through this ramp, because the ramp provides no acceleration - it has no "down" connection.

These are just the basic rules; actual upward pathing occasionally throws odd errors. A "frictionless" upward slope consisting only of upward-connected ramps with no downward connections let a dwarf-pushed cart pass multiple levels (over 40), but a faster cart will fail to climb at some fairly early point (after six or so z-levels). It may be that the level changes are converted into "jumps" which at some point don't properly line up with the track underneath, but that's pure speculation for now. For single-z-level changes, the track connection rule holds up very well.

Abstract:
Track ramps have two possible effects on carts: acceleration and movement between levels. Those two effects are completely separate - it's entirely possible to have level changes without speed changes and vice versa.
- to provide acceleration, a ramp must have at least one "up" track connection (to a wall) and exactly one "down" connection (to floor or a ramp on the same level or to a hole). Acceleration is a flat 4900 speed units per step towards the "down" direction.
- to allow downward level changes, any ramp works, but the tile from which a cart approaches the ramp must be track or a bridge.
- to allow upward level changes, the ramp must have track connection in the "up" direction (other track on the ramp is irrelevant for the purpose).

Carts will also enter lower z-levels by falling there and higher z-levels while on the ascending branch of a ballistic flight path, and can also enter different z-levels by being carried by dwarfs

PPPS: extremely minor datum - the cutoff for the "shotgun" effect (i.e. carts jettisoning their cargo upon collision) is somewhere between 55.000 and 56.000 speed. A cart going just faster than 5 tiles in 9 steps (i.e. there was the occasional 4 tiles in 7 steps interspersed) dropped its cargo upon hitting a wall, a cart going just slower (had exactly one more step on a medium-friction track stop, i.e. 500 speed less, so interspersing 6 tiles in 11 steps instead) didn't. I don't use DFHack, so couldn't measure speed with any higher precision; and tuning cart speed to within 500 of the actual cutoff is a bit of a production anyway.
Upshot is that one dwarven push and two ramps are _barely_ insufficient to get a shot. If you want any shot at all, you need three ramps (or a roller+ramp combo of some kind), if you want decent effect, you should go for high speed anyway - the faster the ammo goes, the more punch it delivers: momentum matters.

[Insert_Gnome_Here]

Is the dwarven knowledje centre still maintained? Will I have to turn on the Girlinhat signal?

[NW_Kohaku]

This is highly useful... I had trouble with a cart track, and was going through it one step at a time, and noticing that some tiles took only one step to cross in spite of the fact that the very next step, they would apparently run out of speed to make it up a ramp. (I was trying to pass a minecart through a hole in an aquifer, so it was an oddly-shaped track.) 

This report on checkpoint bug is highly informative.  It needs to be in the wiki.

[ImagoDeo]

Larix, I am in need of a precise repeater. The Dwarven Child Care Reboot has taken a decidedly danger room-ish direction and the basic wave repeater from the Wiki is not really suitable to my needs, because it doesn't cycle the spears as quickly as would a dwarf pulling a lever. If anyone knows how to build a simple repeater to imitate that with minecart and/or fluid logic, I'm sure you do.

I do intend to read through the entirety of what you've written here sooner or later, but at the moment I just need a repeater.

Thanks a heap. The dwarven children of Picksling will curse your name thank you profusely.

[NW_Kohaku]

Larix, I am in need of a precise repeater. The Dwarven Child Care Reboot has taken a decidedly danger room-ish direction and the basic wave repeater from the Wiki is not really suitable to my needs, because it doesn't cycle the spears as quickly as would a dwarf pulling a lever. If anyone knows how to build a simple repeater to imitate that with minecart and/or fluid logic, I'm sure you do.

I do intend to read through the entirety of what you've written here sooner or later, but at the moment I just need a repeater.

Thanks a heap. The dwarven children of Picksling will curse your name thank you profusely.

He put one up in the traps thread, which had a repeat time of 84.

Basically, if you abuse the checkpoint bug by having alternating impulse ramps, you can guarantee a cart moving at at least 72k speed will move precisely 1 tile per tick.  It might take up a bit of space, but if you just create a track that is repeat iteration long with alternating impulse ramps, and have the "on ramp" to the track involve enough impulse ramps to guarnatee 72k speed or more, which is a pretty broad target, you're pretty safe.  By some back-of-the-napkin math, that's basically just creating a track where you dump a cart on a series of about 8 impulse ramps as a speed-up lane before hitting the circuit.  After that, you just need a track pressure plate or two and an off switch, which can be as little as a door on one of the non-ramp tiles. 

[Larix]

The first proven optimum spike repeater was published by jcochran here. My own design with the same period is a few posts below that (uses two two-ramp pits with NS track to keep going, the "outer" pit/ramp below a wall).

Spikes have a 40-step reaction delay, which limits the cycle speed to ~140 at best with a single plate; the repeaters that can run spikes at the maximum frequency of 82 steps take multiple pressure plates. It also makes constructions sensitive to fast-switching off/on combinations - if the "on" signal comes too short after a legitimate "off", the spikes are not yet ready to process the new signal and have to wait a full cycle before responding again.

FYI: this information provided not because, but _although_ it might be used in "Dwarven Child Care" I generally try to contribute when i feel competent, what you do with the info is your call.

[NW_Kohaku]

Incidentally, the information in this thread is far too useful to not be on the wiki.  As such, I've started putting its findings on the wiki, with links back to this thread. 

It may need diagrams to illustrate some of the principles, so if someone wants to put those up, as well, feel free.


Also, for the record, my own use of a wiki-style impulse elevator (to try to grasp how the checkpoint bug works with it) resulted in 16z-levels of ascension before it suddenly bounced off a ramp.  I accelerated the cart up to just under 1 step per tick, (so it should be more than 80k speed), and had an impulse ramp before the first up ramp. 

Every single tile up to the one it bounced off of took exactly one step.  I still can't tell what caused the bouncing, as there was no apparent deceleration, and no reason why this one ramp should be different from the last dozen.  It then bounced again at 21zs from the base, 26zs from the base, and so on, predictably bouncing every 5th floor. 

... I'm not sure WHAT this implies, as it doesn't seem to behave by the impulse ramps as I understand them to work.  They ARE decelerating, somehow, but I can't tell how. 

Presumably, using a few straightaways to re-boost speed occasionally would fix this problem, and make it work more regularly.  Since I can make it climb 15z without problem with a set of 8 impulse ramps to start with, that means alternating in a few straights every 15zs if they are long, or 6zs if they include "just" three or four impulse ramps in a straight line.

Remind me, Larix, how you achieve your own compact impulse ramp designs that skip these problems?  (Or do you just use straights...)

EDIT: Oh nevermind, this would work properly if it was just a 3x3 ramp, rather than a 2x2, wouldn't it, since that would actually allow the impulse ramps time to add speed...