Print

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

[Larix]

I've messed around with bashing minecarts together a bit, and the rules of such collisions are pretty straightforward, although the consequences can get strange.

1. if a cart attempts to move into a tile currently occupied by another cart, it transfers its entire movement pulse to that cart and comes to a stop. If it was moving faster than derail speed, it will also let go of its cargo.
2. the speed at which the pushed cart will move is
incoming speed * incoming cart's weight/pushed cart's weight
capped at incoming speed. Apart from the cap, that's plain old conservation of momentum, i think.

But
2a. any potential speed of the pushed cart in the same direction is lost without a trace: a brass cart going east at maximum roller speed (50k) was chased by a high-speed (~120k) wooden cart, also going east. When the wooden cart caught up with the metal cart and pushed it, the wooden cart stopped and the brass cart slowed down to about 7k.

3. this speed transfer/speed erasure only applies to movement axes in which the incoming cart is actually moving at nonzero speed: if a cart moving S->N hits a cart going W->E, the eastward-heading cart will keep its eastward movement component and will gain an additional amount of northward speed, resulting in a north-east heading.

4. if two carts attempt to move into the same tile on the same turn, build order of the carts decides which one enters the tile first. I think it's last-built cart moves first, as with other build order checks, but haven't tested this recently. As a consequence, if two carts approach each other from opposite directions, trying to enter the collision tile on the same step, the "younger" cart will move off in the older cart's movement direction, with that cart's momentum, while the older cart simply stops. A precisely calibrated circuit doing this could sort minecarts by build order.

5. the speed cap allows regulating speed/momentum - letting the incoming cart smack into an aluminium cart, which then pushes a silver cart, which pushes the actual outgoing cart, will automatically cut momentum to ~1/4, before taking incoming/outgoing cart weights into account.

I've no idea where to put this. It's a part of minecart physics, but strikes me as a complete niche feature which most players will never really bother with.

EDIT: o wow, that's a whole subset of complete wtf stuff going on there.
I slapped together an ultra-simple test rig for build-order-driven minecart separation, with two minimally different architectures:

Code: [Select]


╚═C═╝   
Model A (conflicting entrance)

╚═cc═╝
Model B (conflicting exit)

In the first case, both carts try to _enter_ the same, currently empty square. In Model B, they reach immediately adjacent squares without colliding, the collision occurs when the carts try to _leave_ their squares and move into the one still occupied by the other cart. The collision takes place quasi-invisibly, during the build-order-determined resolution of moves of all buildings/creatures/items.

Under Model A the younger cart stops and the older cart moves off - the older cart moves first, enters the collision point first and thus gets pushed when the younger cart's turn in the resolution cycle comes up.

Under Model B, following the same logic, the older cart stops and the younger cart moves off. I.e. the older cart is the first to try and move, encounters the younger cart and pushes it, transferring its entire momentum to it (while the younger cart's momentum disappears).

In each case, the cart which comes to a stop does so on the tile it occupied _before_ the collision occurred, i.e. just one tile off the "C" point in Model A and on its own "c" spot in Model B.

So, first of all - it's the _older_ cart which moves first. Both designs accurately separate carts based on their build order, as long as the carts really come in during the same turn. Switching the directions from which carts come in doesn't change the results. The carts should preferably all be constructed before you install and link the hatch covers, just to make sure you don't add another degree of build order into the equations.

And because we were due another case of pure unadulterated wtf, these kinds of collisions _can_ transfer the unmodified, uncapped impulse in some cases. As far as i could determine, there are two conditions:

1. both carts must be moving before the collision; moving carts crashing into stationary carts cannot result in more than input speed. I had observed the latter in previous applications, so was rather surprised to see an exception to the "no faster than input" rule all of a sudden.
2. the relative weight difference between carts must fall within some limit, the pushing cart may have to be less than twice as heavy as the pushed cart. An iron cart will not cause acceleration when pushing an aluminium cart (weight factor larger than two and smaller than three), but a willow cart _will_ accelerate an adamantine cart (weight factor just smaller than two). This can result in above-derail speeds. Gotta see if i can pull this off with rollers, as a bonus "you totally can get derail speed with rollers" trick.

[Larix]

EDIT: I put my findings on yet another subpage of my user page:

http://dwarffortresswiki.org/index.php/User:Larix/Minecart_Collisions


Research report:

I looked into the "conserve momentum to the point of speed increases" feature some and as far as i can tell it works like this:

- momentum is conserved in collisions, but _normally_ the output speed will not exceed the input speed.

There are peculiar exceptions to this, however, which among others allow accelerating roller-propelled minecarts to derail speed (practical limit just under 100k). The conditions for a successful acceleration are

1. The weight of the pushed cart be at least 1/2 that of the pushing cart. The _momentum_ must also be a certain minimum fraction, although that's not so clear - 32% are not enough, 45% suffice.

2. The collision is head-on.

Tests run, using a two-roller setup feeding a collision track, using Model B above:

both rollers highest speed:
a) platinum minecart (older) pushing lead minecart (younger) - lead minecart moves at above-derail speed (about 90k) - weight ratio ~ 1,9
b) platinum minecart pushes silver minecart - silver minecart moves at below-derail speed (no more than 50k) - weight ratio ~2,035

c) platinum minecart pushed by highest-speed roller, lead cart pushed by medium-speed roller - lead minecart moves at below-derail speed - weight ratio ~1,9 speed ratio ~5/3, momentum ratio ~3,3

d) to check for head-on vs. "overtaking" collision, i let the same platinum cart overtake an electrum cart moved by a high-speed roller - momentum ratio ~ 1,9 - electrum cart moves at below-derail speed.

And to be surer that it's momentum that makes the difference:
c') platinum-highest head-on with a medium-speed gold minecart (momentum ratio ~1,9) - gold cart moves at derail speed
d') platinum highest overtakes gold-high - gold minecart moves at below-derail speed. I didn't check overtaking collisions after this.

but
c'') platinum-highest head-on collision with an electrum-medium cart (momentum ratio of ~2,2) - electrum cart moves at derail speed. The same holds for an electrum-highest cart pushing a lead-medium one. But since a silver cart will not gain derail speed when pushed by a platinum cart at equal speed (see above), weight and momentum are apparently separate conditions.

Oh, and this round's serving of wtf:

- a minecart that entered a roller tile by _rolling_ there may start moving a full step later than a cart that was placed there by a "place track vehicle" job. I had to replace carts via "guide south/north" a few times to get the starts properly synchronised again.