1. None
Dfhack offers the watch-minecarts script which can track location and speed of a cart. That's fine as far as it goes, but wouldn't have provided much useful info here.
I have a pretty detailed knowledge of cart speeds and movement patterns, so can easily (mentally or by hand) calculate the expected coordinates for cart moves; i've also tested those predictions time and again, at the values i was looking at here they were easily precise enough.
To measure what was going on, i used the simple expedient of pausing the game and stepping through the events via "."; even if you use the dfhack script, i strongly recommend you use this tool as well, the data provided by dfhack are _not_ a substitute for careful observation.
The main work really consisted of forming hypotheses and doing test runs that checked them.
E.g. hypothesis: there's a kind of holding effect that prevents carts from moving their full speed-dictated distance over ramps in some cases. Test is quite simple - if a high-speed cart fails to move off a ramp in one step sometimes, the effect indeed exists. Just make sure that speed before and after the ramp is over 150000.
For the details of the effect, i organised runs so that a first ramp was entered at interesting coordinates, generally starting with a cart going at max ramp speed (2,65 tiles per step, or 2,7 with a little trick). Knowing the speed makes it easy enough knowing which coordinate a cart's at, you don't need dfhack for that. The final test was a top-ramp speed cart entering ramps with a remaining travel distance of 1,1 normal-floor tiles vs. one with a remaining distance of 2,1 tiles. If the break indeed happens 100000 distance after "starting the checks" (here entering ramps), they should behave exactly identically, including a first single-ramp move on the third on-ramp move (i.e. a notably early occurence). That was exactly what happened, the pattern was 100% the same over forty ramps. The likely alternative hypotheses (e.g. "stop happens at end of legal move or tile border", which was my first hypothesis - and which proved wrong) would have resulted in measurably different behaviour at that scale.
2) you need a constant line of nothing but ramps, with a slant change on every second ramp. The checkpoint effect applies when moving from a ramp to a different-slant ramp, and a sufficiently speedy cart can move through a ramp and into the tile beyond it when it has the proper starting coordinates; the checkpoint places a cart at the very end of the tile, which is the best possible starting coordinate for this purpose.
The setup would look like this:
▲#
▲#
▲#
▲#
▲#
▲#
▲#
## .. ##
══╠╠══╠╠══╠╠
.. ## ..
1 2 3 4 5 6
with the engraving pattern below. A cart going west-to-east at sufficient speed will only touch (checkpoint) tiles 1,2,3,4,5 and 6 and speed through the following same-slant ramps, reaching the next checkpoint in a single move. All ramps are legal because they have wall to the east and potentially also to the north/south, and a down ramp or flat floor to the west, or north, or south (the non-wall link defines slant direction). Ramp slant changes between west and south/north on every
other ramp. A checkpoint always neutralises the last step of acceleration accumulated, so there's no speed change at all other than the tiny track friction, as long as the cart keeps going at a rate of one checkpoint per step. The additional alternation between northward and southward slant is because the "lateral" checkpoints don't generate lasting lateral motion, but displace the cart north/south by 5000 distance each time.
I built and tested this thing, allowing a dwarf to travel up 70 z-levels in 35 steps, faster than all-ramp track or free-fall can move an item or unit downwards.
It's a refinement of the all-checkpoints ramp chain which allows moving stuff at one z-level per step, up or down, with nearly no input speed requirement, which is usually also ride-safe. It consists of nothing but ramps, with a slant change on every one of them. The main design issue is that it requires a straight line - ramps and corners don't mix well, corners are always best taken on flats.
Theoretically (didn't bother to test), a transterminal-speed cart could travel three ramps per step when going over all-ramp track that changed slant on every third ramp. The cart must be at more than 283000 speed for this to be possible at all, which can't be achieved with conventional means, and due to the transterminal friction of 10000 per step, a cart can't keep going at that rate for very long.
BTW, "little trick" to get a cart going at 2,7 tiles per step over flat floor: if you accelerate a cart on ramps and then let it pass over onto normal flat floor, you'll lose ~5000 speed to the checkpoint effect. You can get around this by using a cart collision: place a compatible (lower- or same-weight) cart on the "exit tile", i.e. on the flat floor past the last ramp. The incoming cart will push the standing cart "instead" of going off the ramp and passes on the full unchecked speed. This way, the full 2,7 tiles per step max ramp speed can be used on flat floor.
Tested and proven.
Author
Topic: My very own Minecart Education Thread. Ten Lessons, now complete. (Read 30556 times)