Print

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

[Sanctume]

I wanted minecart impulse ramp hauling from about 40z below.  It worked the last time I tried in 43.05 32-bit.

I'm using 43.05 64-bit and there should be no change, but somehow my mine cart fails to keep going up.

Trackstop ├ is push east when full, and takes from nearby stockpiles. 

But the minecart stops after the 5th impulse ramp.  In this case at z+3.

I was reading about the rocking horse effect but not quite understand it, other than the minecart may fall down after 4th or 5th impulse ramp. 

But I thought that if the impulse ramps are continue in a series, the minecart should keep going?

Was there suppose to be at least 1 track (not a ramp) in between each impulse ramp to push the cart above its current z level?


col: ---------1------0---2
     012345678901234567890
z+0: +######
     +├═╚╚╚#

z+1: ########
     #####▼╚#

z+2: #########
     ######▼╚#

z+3: ##########
     #######▼╚# (stops here)

Track/Ramps: NE ╚ . NW  ╝ . SE ╔ . SW  ╗ . Track Stop ├ . Down Ramp ▼

[Bearskie]

Well, to quote from Larix's Minecart Education thread, I don't think your impulse ramps are legal. (R1 but no R2)

A ramp is only fully traversible for carts and can only provide acceleration if it's properly connected by track. There are two arguments that get checked, and they concern track connections and nothing else. It doesn't matter where the cart comes from, whether it changes level or not, it's all about how the ramp is built.

* Requirement one: the ramp must have track connection to wall. One, two or three connections are all acceptable.

* Requirement two: the ramp must have exactly one track connection to a non-wall tile. This can be an adjacent ramp on the same level, flat floor or a hole (e.g. containing a down ramp).

There are couple of designs on the wiki for functioning impulse elevators, but this one interested me the most - it's from the same thread, and is fairly similar to your attempted design. There is also an advanced design further on that accelerates as it climbs.

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.

[Sanctume]

Yeah, that was the thread I was looking at.  So I should change my setup to the following.

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)


If I understand this correctly, this is suppose to move from east to west, since the z level is descending. 
My plan is moving from west to east and going up.

Code: [Select]

col: ---------1------0---2
     012345678901234567890
z+0: +##########
     +├═╚####### (track stop ├, push east when full; using NE ╚ track/ramp)

z+1: ###########
     ###▼═╔##### (using SE ╔ track/ramp to alternate)

z+2: ###########
     #####▼═╚### (using NE ╚ track/ramp)

z+3: ###########
     #######▼═╔# (using SE ╔ track/ramp)

Track/Ramps: NE ╚ . NW  ╝ . SE ╔ . SW  ╗ . Floor + . Track Stop ├ . Track EW ═ . Down Ramp ▼

So, this should work.  And should be similar for corner turns to go up z levels?

Spoiler (click to show/hide)

Well, to quote from Larix's Minecart Education thread, I don't think your impulse ramps are legal. (R1 but no R2)

A ramp is only fully traversible for carts and can only provide acceleration if it's properly connected by track. There are two arguments that get checked, and they concern track connections and nothing else. It doesn't matter where the cart comes from, whether it changes level or not, it's all about how the ramp is built.

* Requirement one: the ramp must have track connection to wall. One, two or three connections are all acceptable.

* Requirement two: the ramp must have exactly one track connection to a non-wall tile. This can be an adjacent ramp on the same level, flat floor or a hole (e.g. containing a down ramp).

There are couple of designs on the wiki for functioning impulse elevators, but this one interested me the most - it's from the same thread, and is fairly similar to your attempted design. There is also an advanced design further on that accelerates as it climbs.

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.

[Fleeting Frames]

You might actually be familiar with it - used that design for magma elevators in both Moonhome and Deathgame. However, do mind turning into a wall - T-shaped track is necessary (and alternating empty holes on the sides for Ts are necessary), if you don't have over 0,5 tiles/step speed. If you already engraved the tracks, you can just add additional engraving designation. The movement direction is bidirectional, provided it gets past the first ramp; it will go 1z-level/step both ways, with nearly unchanging speed (ground friction only) at any speed past...oh, 0,05 tiles/step (plus whatever it takes to overcome the first ascending ramp - being placed on an impulse ramp is enough to cover both.)

What you have in your opening posts on higher z-levels are actually non-accelerating "invalid" ramps that act as flat track (most useful when messing with water or magma) - and you're going too fast to ascend, hitting a wall instead. A dwarf push moves a cart on something like 1219 tiles straight, iirc (but you tend to hit walls on the way down, so it's not as useful or fast as checkpointing).

Oh yeah, if you try to use corner/ramp turns to go up or down z-levels, mind the sideways drift and ensure another corner to reset it within 10 steps, lest the cart crash into a wall, stop and reverse direction to down/sideways. Alternatively, use non-ramp corner followed by a "rocker" for ascending with a kick.

(Since corners change 'exit' direction on every turn, you could theoretically build nearly as fast 2x2 corner spiral, were it to not drain lot of speed both ways due displacing 5k of it sideways; starting from a rocker you'd have to have an impulse ramp something like every 6-7z where it'd come to a stop, which would make it take around twice as long per z on average and would require some additional hoops to descend.)

[Sanctume]

The one I had in the after Moonhome had more room, so I was essentially had 3 flat tracks then 2 impulse ramp to move the minecart up a z.  I seemed to work.

But this time, I was carving a more compact spiral and failing.

I was watching WanderingKids' video again, trying to understand the "rocking horse" and "shun" setup he was doing.

[Fleeting Frames]

Ah. To clarify (also, edited post after you posted), when I say rocking horse, I mean this: Wall East-West Ramp East-West Ramp, Wall. (or it's mathematical equivalent). If you look at the map in my sig, used in Moonhome at bottom (10z, though check year 34 map - 42 has bit of flooding accident) as well as on turn on 70z for the kick after corner. (caverns avoided by following 48x48 tile edges).

It's called rocking horse because it accelerates carts both ways.

Iirc WanderingKid's thread had two tiles per level, an impulse ramp followed by ramp to ascend, followed by a track/corner, then starts over. It's very remarkable for it's time where minecart physics were far less understood, but it starts at 4 steps/z-level and maxes out at 2 steps/z, while Larix's fastest designs max out at 0,5 steps/z-level.

The shunt on first z-level is basically if it comes back down it ascends the track/ramp/corner onto flat floor and hits the wall there instead of hitting a dwarf in the face.

[PatrikLundell]

My standard spiral ramp has a 3*3 footprint with a downward fall chute in the center and the spiral being used for the upwards direction. Obviously, this design is not good for riding (at least not downwards). In this design, each straight piece is a flat impulse ramp and each corner is a normal turning and climbing ramp. Designating the track carving is an S movement: side wall to flat stretch, flat stretch to climbing ramp, climbing ramp into wall onto which the ramp is climbing (repeat each level, turning 90 degrees).
Obviously, that uses a footprint different from yours and essentially moves stuff straight upwards. I haven't bench marked if for efficiency, though.

[Fleeting Frames]

Well, it caps at 2 steps/z from the start for ascending, since ramp exit direction changes with each ramp, it consists of only ramps and there's two ramps per z-level. Though corner ramps (which are negative impulse ramps here, tbh) means it has to spend a step accelerating for each corner ramp, since corner ramps drain speed to ascend/descend, even in 1 step, resulting in overall performance somewhere near but below 3 steps/z.

On the flip side, it supports returning cart down while another is ascending, which enables much higher rate of 'fire' (nearly to the level of screw pump, if properly done without collisions). I'd probably carve two straight rampways side-by-side, though, but that has much bigger footprint.

[Sanctume]

My standard spiral ramp has a 3*3 footprint with a downward fall chute in the center and the spiral being used for the upwards direction. Obviously, this design is not good for riding (at least not downwards). In this design, each straight piece is a flat impulse ramp and each corner is a normal turning and climbing ramp. Designating the track carving is an S movement: side wall to flat stretch, flat stretch to climbing ramp, climbing ramp into wall onto which the ramp is climbing (repeat each level, turning 90 degrees).
Obviously, that uses a footprint different from yours and essentially moves stuff straight upwards. I haven't bench marked if for efficiency, though.

So something like this?

Code: [Select]

z+0   z+1   z+2   z+3   z+4   tracks
##### ##### ##### ##### #####
##### ###╗# #╔╝▼# #▼### #####
##.## ##.╚# ##.## #╗.## ##.##
+├╔╝# ###▼# ##### #╚### #▼╔╝#
##### ##### ##### ##### #####

z+0   z+1   z+2   z+3   z+4   ramps
##### ##### ##### ##### #####
##### ###▲# #▲╝▼# #▼### #####
##.## ##.╚# ##.## #╗.## ##.##
+├╔▲# ###▼# ##### #▲### #▼╔▲#
##### ##### ##### ##### #####

Track: NE ╚ . NW  ╝ . SE ╔ . SW  ╗ . Floor + . Track Stop ├ . Track EW ═ . Down Ramp ▼ . Up Ramp ▲

[Fleeting Frames]

I assumed that layout, but every corner turn in the bottom should be a ramp, otherwise there's no "upwards" acceleration.

[PatrikLundell]

Yes, that basically looks the way I do it, although the downwards chute ends on a ramp at the bottom (with tracks) and tracks leading off to the track stop for dumping after which the cart continues to the track stop for loading (where it stops). The entry at the top has to be constructed such that the pushed cart bumps into the wall to fall down, rather than fall onto the upwards track to return back up.

The bottom view shouldn't have any tracks at all, but ramps instead of the tracks depicted. The "straight stretch" ramps go sideways up the wall and don't lead anywhere (as there's a roof above), providing the impulse. Thus, z+4 would be "▼▲▲", which is also what it looks like before tracks are carved.

[Sanctume]

Thank you guys. 

I just made all of them carved track ramp in the "s" configuration and it works ok. 

Code: [Select]

z+0   z+1   z+2   z+3   z+4   tracks
##### ##### ##### ##### #####
##### ###╗# #╔╝▼# #▼### #####
##.## ##.╚# ##.## #╗.## ##.##
+├╔╝# ###▼# ##### #╚### #▼╔╝#
##### ##### ##### ##### #####

I end up with using all carved track ramps
z+0   z+1   z+2   z+3   z+4   ramps
##### ##### ##### ##### #####
##### ###▲# #▲▲▼# #▼### #####
##.## ##.▲# ##.## #▲.## ##.##
+├▲▲# ###▼# ##### #▲### #▼▲▲#
##### ##### ##### ##### #####

But this could technically work using track ramps every 4th set?
z+0   z+1   z+2   z+3   z+4   ramps
##### ##### ##### ##### #####
##### ###▲# #▲╝▼# #▼### #####
##.## ##.╚# ##.## #╗.## ##.##
+├▲▲# ###▼# ##### #▲### #▼▲▲#
##### ##### ##### ##### #####

Track: NE ╚ . NW  ╝ . SE ╔ . SW  ╗ . Floor + . Track Stop ├ . Track EW ═ . Down Ramp ▼ . Up Ramp ▲

[Fleeting Frames]

3rd schema: Not if you use valid aka accelerating track/ramps to ascend on each z-level. The checkpoint effect will 'erase' the second, opposing track/ramp on z+0, but unlike with contiguous corner ramp spiral or alternating T and straight tracks the rest of them will remain uncheckpointed; thus 'normal' physics class formula of s=v^2/2a applies and the overall energy of the cart will be negative with the previous floor friction cost i.e. insufficient to ascend (I think of it as this way : Ramp minus floor minus ramp < 0, but tbh sub-tile positions actually make that worse than this.).

(Descending from ramp at near-zero velocity works a little differently, where you can enter the edge of next tile at zero velocity, due post-checkpoint compensation always applying opposite direction from ramp's 'exit'.)