Print

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

[Larix]

Seeing how i can "persuade" an over-derail cart to take a down ramp by sending it over an impulse ramp (on flat ground), i checked whether the opposite worked as well - using a ramp to prevent an ascending cart from taking off. Yep, it does:

Code: [Select]

######     ######
▼═════     ▼▲════
######     ######

Left: cart comes from below at high speed, goes up the ramps and gets airborne instead of following the flat track; i had one level of open air above, and the cart banged into the ceiling and stopped.
Right: cart comes from below, the impulse ramp (SE or NE) prevents it from taking off, cart stays on the level and follows the track; it can go around a corner immediately behind the ramp.

I think WanderingKid's already discovered this feature and used it to regulate the output of his impulse ramp spiral. Impulse ramps offer some interesting options to direct and control cart movement across z-levels, and not just acceleration while going up. I'll have to see if i can come up with a powerless goblin grinder that consists entirely of ramps, without bleeding off speed. I think it must go across three z-levels.

[GavJ]

You can load minecarts into other minecarts, you know. And when one shotguns, the ones that come out of it run into each other.

This easily could (or could not) help this to become vastly easier. I.e.heavy cart has half cart and quarter cart loaded into it, then 1/8th car loaded into one of those, etc. You might not be able to guarantee order of collision well enough though, but it's worth looking into.

[Larix]

I don't see how this would be in any way beneficial:
the only collisions i've seen to result in speed increases were frontal collisions, where the pushed cart needed to have at least ~1/3 of the momentum of the pushing cart _opposed to the pushing cart's momentum_. Carts thrown out shotgun-style all travel in the same direction when coming from the same cart. In addition, the full weights of carts including cargo are taken into account in the calculations and shotgunning doesn't accelerate the cargo, it only separates it from the container (often by stopping the container). I might be missing something super-smart, but as presented the suggestion sounds like a complete non-starter to me.

I delved into the powerless minecart grinder a bit and the basic design isn't overly difficult, it only takes _two_ z-levels:

Code: [Select]

z0          z+1         comparison
#######     #######     #######
#▲▲▲▲▲#     #.###.#     #▲▲▲▲▲#
#######     #▲###▲#     a▲▲▲▲▲b
a▲▲▲▲▲b     #.###.#     #######
#######     #######

#######     #######     #######
#╔╝╝╝╗#     #.###.#     #╗╝╝╝╝#
#######     #╔###╚#     a╔╔╔╔║b
a╚╔╔╔╝b     #¢###.#     #######
#######     #######

Carts go around counter-clockwise, entering from a (can be simple open floor) and leave through b, if desired (lever-operated door). Entrances and exits can be built in other locations, too, for easier "feeding" of the grinder.

The design objective was to build a minecart grinder in which the cart's always on a ramp - collisions with creatures can sometimes stop a cart, and if it stops on flat floor, it won't accelerate again, leaving the grinder inactive. One way to do this would be to make the necessary four turns on impulse ramps - as seen in the "comparison" circuit. This design has a grave disadvantage: it lacks speed. Since the corners aren't properly aligned corner tiles, the cart bumps into the wall (or door) behind the ramp and re-accelerates from a standstill. I tried it out and the cart takes 48 steps for a full round, of which 32 are spent on the four corner tiles (eight steps each). When released through a door at b, the cart is fast enough to leave the circuit via derailing, but that's still just a less-than-impressive ~70k speed.

If a corner tile is supposed to be both a ramp _and_ a properly aligned corner, it requires a level change. That's what i did in the proper design, seen to the left. It requires two tiles on the z-level above, each of them a "downward" impulse ramp, to prevent the cart from taking off (would result in a wall collision and complete loss of speed), not to mention that every tile the cart passes over was supposed to be a ramp. The cart takes eleven steps for a full round, and while it doesn't seem to reach "blow apart" speeds, releasing it at b sees it going at a pretty decent ~170k. I tried releasing it from two more locations, and the cart was always going at least 150k. The cart can be stopped and re-started by a lever-operated hatch cover as shown in the blueprint.

The impulse ramps in the speedy grinder can all be attached to the central row of stone, of course, i displayed them this way to emphasise the difference between impulse ramps and corners. If built like that, _some_ of the outer walls could probably be left out, but four pillars/obstacles will be required to prevent derailing off corners, and there seems to be a degree of diagonal movement present, so some curtain walls may still be needed.

[GavJ]

shotgunning doesn't accelerate the cargo, it only separates it from the container

Why does my cargo fly 3x further then when I use max speed versus only a few ramps, and reach several z levels higher?  It's definitely affected by cart speed. I don't know how to turn them into reliable frontal collisions, but surely it's worth trying a nested minecart frontal with another nested minecart, etc?  It sounds tricky, but if it works, the whole thing fits in 1/10th the space and becomes vastly easier to build.

Edit: More information:

I thought this was too well known to bother writing a thread about my low grade !!science!! on shotguns and minecarts and whatnot, but maybe it isn't? I built a firing range fortress, loaded a minecart, and save-scummed for maximum comparability between tests, only taking the extra small bit of time to build walls or bridges as necessary, etc. to test different things. But in every case, the cart was loaded with a full load (86 or something?) of lead bars:
Test 1) 10 impulse ramps. Range = 28 tiles (middle of the bar spread on the ground)
Test 2) 50 impulse ramps, which should be max normal speed. Range = 76 tiles
Test 3) 30 impulse ramps. Range = 43 tiles
Test 4) Build walls to "choke" the shot for the first 3-4 tiles, simulating a narrow hallway. In real life, this would not affect absolute range but it would increase effective range by putting a larger number of low velocity pellets into the target in the central area (through ricocheting into a shallower angle), thus causing sufficient damage further out. In dwarf fortress, the range was unaffected in EITHER sense. The furthest bars were just as far, and density in the middle did not increase. Thus, it appeared that no ricocheting occurred, and seemingly not even very much or any "sliding" along walls after impact. Things DO definitely slide along the ground, but maybe this doesn't apply to walls? It seems almost like anything that hits a wall just stops dead and falls straight down.
Test 5) I tried building floors above the muzzle, same concept but vertically. Range was reduced notably. It was reduced more at higher powers. I suspect that what's going on is the bars that would have flown furthest were the ones that were randomly chosen to be at higher angles (parabolic trajectories, duh). Thus, when you block those from going as high as they need to, they fall short, and only the flatter trajectory bars make it out, which don't go as far. It's possible that like walls, they sort of stop dead on a ceiling too, but it was too hard to tell for sure. I could retest it and count the density of bars right at the muzzle afterward to find out if anybody cares. That said, I never saw any bars even at max power go more than 1 z level up from the launch point, so you don't need huge amounts of headroom.

Bottom line for this thread, though: ABSOLUTELY the cart going faster = faster projectiles that fly out of it. In fact it seems like it is probably a straightforward linear relationship, as you would expect in real life (the slightly nonlinear final range distance you have to realize takes into account parabolic math and thus would not be expected to be perfectly linear even if muzzle velocity were linear)

[GavJ]

Update: varying density of ammunition does NOT change projectile speed, only the speed of the launching cart. Which is realistic, but I was hoping maybe it wouldn't be like the OP.

I tried a cart full of lead, a cart full of quartzite blocks (1/4 density), and a cart 1/4 full of lead (so the projectiles were denser but not the total cart), on the same track, all went the same range with the same number of impulse ramps, but different ranges with different number of ramps.

[Larix]

With "shotgunning" i mean the event of ramming the cart into something (wall, other minecart etc.) to jettison the load. This event does _not_ accelerate the cargo of the incoming cart. Before the collision, the cargo goes at the speed of the cart it's in, and after collision, it keeps going at the speed of the cart (maybe +- a bit, since the process is mildly random).

You might have missed the point in all the shotgun experimentation: the collisions i'm producing have the outgoing cart going _faster_ than the incoming cart. Follow your cargo and carts step by step - if you end up with speeds of four tiles per step or more, you're onto something. I won't hold my breath, though

Loading items into carts before accelerating them will increase gross weight and thus momentum (i've done this in my experiments) but i can't conceive a way to make the flying cargo useful for acceleration _through collisions_ - carts-inside-carts that get released through collisions tend to collide with each other in an uncontrolled way while moving in more or less the same direction.

Incidentally, your experience with "muzzles" and bracing walls is in line with what i've seen - when a free-moving item (including minecarts) hits a wall, it will typically stop dead and fall to the floor. Thus, walls and ceilings don't "direct" trajectories, they just stop everything cold that'd go out of bounds.

[GavJ]

I understand. I haven't thought it through that far yet. I'm just saying, it might be helpful for compactness of the same system somehow. You would still need two opposing shotguns, for sure, but maybe you wouldn't need 8 or 16 or whatever, if you could somehow have the whole cascade happen as a series of impacts building on one another from carts immediately after being jettisoned from other carts.

At the very least, I think it's probably worth the simple experiment of just shotgunning a cart (first once doesnt matter) loaded with a heavy and a light cart, the light one of which is then loaded with another relatively heavy and light cart (relative to one another), etc. We might just get super lucky and have it work perfectly.

A has B(weight 16) and C (weight in it.
C has D (weight 4) and E (weight 2) in it, the other 2 is C's weight itself.
E has F (weight 1) and G (weight 0.5) in it, blah blah you get the idea.
(I don't think that the contents of a cart count toward the weight of another cart that it is in. So weird and tricky to make the math add up, and the above is wrong, but yeah)

No they won't be head on collisions, but you don't KNOW for sure that's the only way to make it work. Mid air shenanigans of this sort might function differently.

I will do this myself when I have time.

[Yaur]

Yep. DF handles damage through a momentum system, both for projectiles and for melee weapons. Low p, high KE projectiles tend to underperform.

Out of curiosity... does anything interesting happen when you hit a steel clad dwarf with a supersonic wooden minecart?  I'm thinking shaft of enlightenment style where there should be a bunch of damage but the armor deflects it.

[NW_Kohaku]

Sorry to necro a bit, but I wanted to share maths...

Actually, there is a way of calculating near-exact speeds in this game.

You were calculating off of just an assumption of terminal velocity, but there actually is a listed speed in the game.  When Toady added gaits, he added in what speed each gait was to represent.  A "standard" (10 tick per step) gait is 9.6 kph, or 2.6667 m/s.

This means 1 tile per tick (100k cart speed) is 26.667 m/s.  Notably, since Toady also mentioned that he was using a standard of either 2x2x3 meter cubes for tiles or else 2.5x2.5x3 meter cubes, this basically means that a tick is a tenth of a second in non-fortress-warped time, or a time scaling factor of 720.  (Also, keep in mind that Adventurer Mode exists, and uses a totally different time scale... Notably, it runs at 1 second per tick, rather than 72 seconds per tick, but still ten times as fast as what I just calculated... Considering that you're supposed to dodge and such in those split-seconds, that may well be purposeful time distortion even in Adventurer Mode.)

To go further, normal maximum cart speed is 72 m/s (even). 

Finally, the speed of sound at sea level is 340.29 m/s, (I could use the more specific calculated one you used, but these things aren't close enough to worry about a m/s or two,) which is a "mere" 4.27 times the ordinary maximum cart speed.  Your 162 tiles in ten steps speed translates into 432 m/s, so you actually sent that cart in the first post mach 1.27. 

Or in short, your calculations were wrong, you're going even FASTER than you thought because carts can already travel faster than what should be terminal velocity through nothing but air by just going down a ramp.  (In fact, they amusingly can go down ramps faster than they fall through open air in-game, as well...)

TL;DR: LOL Dorf Fissiks

[Xazo-Tak]

Quick question: If a cart dips itself in water to double the weight, does the speed halve?
Because if not, you could make a chain of featherwood carts where there's a pond between each cart, and if we assume the first cart is going at 270,000 so the friction is negligible, then the speed is going to multiply perhaps massively with each collision, because each collision is a high-speed heavy cart hitting a featherweight cart.
I really hope this can be done, because it'd make it possible to hit an enemy with a cart that has a speed in the billions.
Unless the cart just phased right through of course.

[Larix]

Won't work.
1. Most collisions between carts are only partially elastic - the speed conveyed to the pushed cart is strictly limited to at most the speed of the pushing cart.

The fully elastic collision that allows a resultant speed higher than the "input" speed is a rare exception, which is why it wasn't discovered or explored before this thread. It only happens in a frontal collision between two carts with very similar weight (heavier cart at most twice as heavy as the lighter cart) and very similar momentum (lower momentum involved must be ~31% or more of higher momentum, i.e. a 1/2-weigh lighter cart must have ~62% of the speed of the heavier cart).

2. In order to pick up liquid, a cart mustn't go faster than 10 000 speed. You can't load a speeding cart.

Phasing isn't a problem - carts don't phase through stuff. There are some edge cases: carts can seemingly port through walls, but that's just when flying high-speed carts would otherwise get stuck in rock; dwarfs can "step through" moving carts, but that's an artefact of the step-by-step resolution of movement and of the fact that collisions happen when a cart tries to move into a creature's tile, not vice versa.
Two different potential collisions at high speed between carts:

   b       aB
   ║       ║
   ║       ║
a══╬══A    ║
   ║       ║
   ║       ║
   B       bA


one cart moves from "a" to "A", the other from "b" to "B". At sufficient speed, carts can seemingly move through each other in the left-hand crossing. But that's still not phasing - each cart resolves its entire movement in one go, so what matters is where a cart stops at the end of its turn. There's only one collision spot, so if neither cart ends its turn on this exact tile, no collision can take place. On the straight track to the right, you'll always get a collision, no matter how fast carts go. A collision can take place on every tile. No matter where a cart's turn ends, it'll always be in the way of the other one. Carts do check for obstacles and corners on each tile they pass through, no matter whether that's one tile or fifteen tiles in one step.