Thank you. *attempts to use it* 'Not a recognized command' 'Plugin does not exist'
..aw. Guess I'll have to go searching.
I asked about tool specifically because I ran into some weird behaviour with trying to make near corner ramp-only upward spiral percussion corridor recently where both off-turn directions from corner ramp to hole resulted in a bouncing back down, whereas that didn't occur with normal track corner. I initially thought it'd be caused by corner ramp sideways acceleration, but with both directions resulting in it made me think that perhaps their ramp-nature centering was off - is it middle of the next tile (sideways ramp for checkpoint) or 50k into the side of next tile?
Hrrg, i just don't get your thrust. I guess it's a testament to how fiddly minecarts are that it's so hard to understand/be understood when talking about them
I hope the following two observations aren't completely useless:
Going up a corner ramp always generates diagonal velocity to the "outside" of the corner. This may mess up the placement of a cart when it falls down a shaft - the landing location is determined by the "remaining distance" from the cart's last move; i've never experimented with this, i generally remove any diagonal component by flat corners behind the corner ramp.
Checkpoint teleportation always sends the cart to the "far" border of the checkpoint tile, opposite to the border through which it entered: cart checkpoints from south to north -> ends up at the northern border of the new tile; checkpoints from east to west -> ends up at western border of the checkpoint tile; if the cart isn't exactly centred in the respective "other" dimension, that offset remains unaffected by the checkpoint. Say the cart's 20000 north of the middle when going east->west before checkpointing, it'll be just as far north after the checkpoint.
BUT when a cart goes off the ramp on a diagonal, it indeed checkpoints through the whole tile on the diagonal, i.e. when it goes SE->NW, it'll 'port all the way through the checkpoint tile to the extreme northwestern point of the checkpoint tile.
To the best of my knowledge, speeds, distances and lateral offsets are fully converted to "ramp measure"; a cart in the middle of a flat tile will also be in the middle of a ramp, regardless of where the ramp slants to; if the dfhack tool is right, ramps are calculated as being 100000x100000 subtiles, speeds and distances travelled are simply converted by division through 1,4143.
[two-z-per-step ramp track using spaced checkpoints]
... while it works fine in a straight line for going upwards, when going downwards I think the only design for alternating slants every second tile while keeping 1 exit would be using corner ramps.
Hilariously enough, it works perfectly fine downwards, too: while you need track connection to your "up" direction if you want to go up ramps, you don't need a "down" connection to go down. I've actually tested the design downwards first (without a rider, since i braked by ramming the cart into a wall), and the fact that half the ramps have no track branch to the next tile down didn't inconvenience the cart in the slightest. Going down, the checkpoints touched will be the alternative tiles (those not numbered in the diagramme).
[speed requirement]
*Speaking of which, shouldn't that be 143k at most, not 160k? The cart checkpoints to the end of previous ramp, so with ramps being 140k long only a little more speed than that should be necessary to cross the next one in a single step; certainly not 20k more. Where does that extra speed get used?
You're right, 147k speed should be enough. During each step on EW ramps, the cart loses 4900 speed to ramp deceleration before moving (but gets them back at the end of the move), so this speed buffer is required to get through the intervening tile, but no more. I tried out a variety of things and am quite certain that while the cart has a net near-zero speed change, the full ramp increment is shifted back and forth.
***
Right, some more stuff:
Fortifications are equivalent to wallsfor the functionality of a ramp, it's important whether a tile it touches is a wall. It may be of some interest that
fortifications, both carved into actual walls and built as a construction, count as wall for track ramps.
Bridges transform track rampsA retracting bridge extended over an up track ramp (the ramp's bottom tile, not the potential floor hole above it) makes that ramp a non-accelerating all-directions one. Notably, this can be used to
- switch ramp acceleration on/off - including for ramps with four-way track surrounded by walls on all but one side: such a ramp will accelerate carts, but not when covered by a ramp.
- open/close path to the level above: a track ramp adjacent to a wall that it has no track connection to will not allow a cart to climb that wall; a bridge extended over the ramp provides path up over that wall.
### ###
#▲═ #╔═
### ###
track
cart coming from east takes the upward corner, goes south (with lateral speed); the wall to the west is considered solid, derailing "over" it is impossible.
<extend the bridge>
### ###
#B═ #╬═
### ###
effective track
cart coming from east goes west without losing speed (may jump)
Interestingly, dwarfs and other mobs will use a bridge-covered ramp freely, and a cart can travel down onto it just fine.
The path enabling only applies for
track ramps, unengraved ramps won't allow carts to climb up.
my standard accelerator coil for max ramp speed uses three ramps in a line:
# #
#╔╗ #╔╗
#▲║ #╗║
#▲║ #╗║
#▲║ #╗║
╚╝# ╚╝#
# #
ramps track
since going down off the ramp constitutes a checkpoint which costs 4900 speed, two consecutive steps on ramps are required to keep accelerating until terminal speed of 270k is reached. Only 265k of these are actually usable, because you'll leave ramps when releasing the cart.
Of course, there's a smaller design possible which makes the full 270k speed usable on flat floor:
# #
#╔═╗ #╔═╗
╚▲╝# ╚╔╝#
## ##
ramp track
Simply throw two same-weight carts into the circuit. One cart will (from the beginning or eventually) stand in the checkpoint place just behind the ramp. The cart going over the ramp will push it transmitting its entire speed without losing the checkpoint amount, then rolls off the ramp on the next turn with one step's worth of speed, which is immediately neutralised by the checkpoint. I.e. the pushing cart will always dutifully take up position in the checkpoint square after pushing the other cart, ready to take the full speed amount of the other cart on the next round. Even a single step of acceleration is worth 4890 speed, a full round costs 4000 speed for the four corners and another ten speed for every step consumed, so the carts will keep accelerating all the way up to the full 270k. Since the push transfers the undiminished speed amount, letting the cart out of the cycle will result in a cart going at almost 270k speed over flat floor.
The usefulness is sharply limited, since only empty carts can be used - past 55k speed, all cart contents will be dropped upon collision.
Author
Topic: My very own Minecart Education Thread. Ten Lessons, now complete. (Read 29328 times)