Print

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

[fricy]

This is the continuation of SCIENCE: Quantifying minecart physics project. The aim is to build an excel sheet to help with building minecart routes, regulate speed on ramps and to determine how many ticks a given route will take, so we can have better timing.

Current version:
!!Download link!! v2.8

Tested and works: Regular tiles with rollers/pushes/track stops, single ramps with regular tracks in between.
Works more or less: Straight ramps up to ~25 z levels/200000 speed, ramp spirals with regular tracks/corners in between.
Untested/wrong: Long straight ramps, fluids on ramps. speeds/tile skipping above 200k

Spoiler: Usage: (click to show/hide)

 
Data input
Column D contains the track, it sets the impulse- and friction values according to the features entered.
note: If the cart is going faster then the added roller's impulse, the roller will be ignored.

ACCEPTED:
push:    20000
roller high+: 49990
roller high   : 39990
roller low:   19990
roller med:    29990
roller low-:   9990
impulse ramp:   4910
DOWN ramp:   4910
UP ramp:   -4890
corner ramp: -10/tick and -1000/tile
track   : -10
corner: -10/tick and -1000/tile
bridge:   -10
floor:   -200
empty: 0
TS high+:   -50000
TS high:   -10000
TS med:   -500
TS low:   -50
TS low-:   -10
blank is NOT accepted

Column F is for calculating friction in water
ACCEPTED:
blank,0-7

Column G is for calculating friction in magma
ACCEPTED:
blank,0-7

Additionaly you can enter the "Z level" into any of the cells in column C, if any of the subsequent cells is an up/down ramp the Z level indicator will change accordingly.
If you want to delete the number just drag over any of the above/below cell.


Results

Column A: tiles travelled from roller/push the counter resets to zero when (valid) roller is added
Column B: steps that a cart travels
Column G: Minecart speed
Column H: Cart behaviour:
speed>distance units: SKIP
max speed: LIGHTSPEED
>1 tile/step: TELEPORT
>0,7 t/t: SHOTGUN
>0,5 t/t: DERAIL MODE
>0,1 t/t: SAFE
>0 t/t: SNAIL MODE
=0 t/t: !!STOP!!
=0 t/t and cart is on an UP ramp: !Roll again!

Spoiler: LATEST VERSION: 2.8 (click to show/hide)

• Distance calculations:
  a: speed
  b: base friction
  c: distance units (length of a tile)
  c_delta: lefover distance units
  n: ticks/tile
  
  n = (sqrt(4a^2+4ab+b^2+8bc)-2a-b)/(2b) -- rounded down
  c_delta=c-na+b((n^2+n)/2)
  
• Ramp distance units are ~1,4 times longer than regular tiles, but then they compensate for the longer distance. (Partly working)
• Rollers start a cart from the beginning of the roller tile, a push teleports it to the beginning (not the middle!) of the next tile
• Logic checks: ramps/rollers/drop influence a minecart from the middle of the previous tile. Exiting a ramp puts a cart in the middle of the next tile.
• Tile skipping
• Multi-tile rollers are calculated correctly
• No more corner column, corners are entered in D
• Refined ramp formula

[Urist Da Vinci]

...
Friction values are taken from the wikipedia, for rollers I used the values found in electrobadger's post,

Powered rollers give a cart a fixed speed in the direction they are pointing. The speeds are:

• Lowest 0.1 m/s
• Low 0.2 m/s (a dorven push)
• Medium 0.3 m/s
• High 0.4 m/s
• Highest 0.5 m/s

then modified the values by -5% to fit Snaake's results.

#13: How much speed/energy do rollers of varying settings/length give? (1-tile rollers: Lowest 51 tiles, low 201 tiles = a dwarf’s push, medium 451, high 801, highest 1250)

...

Read this post, then go back and redo your calculations: http://www.bay12forums.com/smf/index.php?topic=112831.msg3536975#msg3536975

Electrobadger and Snaake are outdated theories. Expwnent actually looks at game data. DFHack can also access this data.

[fricy]

The most accurate data for roller speeds I found is in the post I linked, and I read the wikipedia and a lot of threads on the forum. (And I have to add I very much admire your contributions to dwarven science.
I'm using those values for friction, (the same is on the wikipedia) the only hard data I'm missing is the roller speeds. I started with electrobadger's values, then modified them by -5-9% to fit Snaake's distance results, as my calculations were a bit longer, I not sure why - maybe I missed a step somewhere. These values can be modified without redoing anything, they are stored in a separate sheet in the workbook.

Code: [Select]

friction
bridge -10
empty 0
floor -200
ramp DOWN 4910
ramp UP -4890
track -10
TS high -10000
TS high+ -50000
TS low -50
TS low- -10
TS med -500

impulse
push 19300
roller high 37000
roller high + 46000
roller low 19300
roller low- 9800
roller med 28400


[Drazinononda]

User review: 3/5

Calculator was great: I've been looking for something to plan out efficient routes for my Dwarven Railway. Now I have it. Only complaint is that when I clicked the download link I quickly bled to death.

[fricy]

Only complaint is that when I clicked the download link I quickly bled to death.

Sorry to hear about the loss of your life.

New version is up:

• Merged the impulse and friction columns, it should be easier to design track layouts now. Sideeffect: rollers have tile friction (-10) now, and rollers on ramps only calculate tile friction instead of ramp friction, but as I understand roller mechanics it shouldn't matter much. Please tell me if I'm wrong....
• Improved the autocomplete.
• Added impulse ramp, it's just a copy of DOWN ramp for now.
• Ramps travel distance is 50000 now. (was 100000 before, some posts indicate it should be half the distance) Max speed is reached after 48 ramps. - testing needed -
• Modified impulse values of rollers. (10000,20500,31500,42500,54000)
• Modified the friction calculations to make up for roller speed changes.
• Added a column for calculating steps needed to complete the route. - testing needed -
• Multi-tile rollers will not behave correctly...

I ran some tests with rollers and tracks stops and updated the calculations with the results from the game:
The modified friction calculation should be more accurate now, testing shows the sheet to be accurate on short distance (4-600 tiles), after that we start to deviate from the game results. Push, low and lowest rollers give accurate results (within ~3%), medium is ~5%, high and highest are off by 6-8%, I had to set highest to 54000 speed, which is obviously wrong as rollers cannot derail. Ramps are untested...

So in one sentence: good enough to design a repeater and predict stops with ~10% accuracy, but still needs work.

[fricy]

New version:
Changelog:
1.5

• Everything except for the "GUI".
• Tile friction is calculated with floating point precision. (was rounded up before) As a result roller speed is correct, testing shows ~1% precision.
• Track stops use rounded up steps to calculate friction. Testing shows this to be true.
• Ramps do not work... They are weird. Rounding up the steps generate too much speed, while using floating point generates too little... I think current release shows ~15% more speed then in DF. Any advice welcome.

[Snaake]

Electrobadger and Snaake are outdated theories. Expwnent actually looks at game data. DFHack can also access this data.

I agree you should use newer data. It *was* some of the (if not just "the") earliest work on actually measuring some of the basics on how carts travel; most of the other initial testing by people was more engineering-style: "how many down ramps do I need for acceleration for this minecart shotgun" and such. It's probably been outdated a couple of times over, and I haven't really done any follow-up. Other projects in DF grabbed my attention, plus the fact that I only tend to play DF in for a couple to a few months at a time, then end up having breaks of about twice that (from this game, not from games in general).

Great job on making a working calculator though! This was one of my hopes for what would eventually come out of those physics measurements.

[fricy]

Thx for your reply.

Yeah, I know that's an old thread, but the minecart mechanics were not updated since, so your results should hold. And besides, after expwnent looked at the game mechanics with cheatengine all minecart testing stopped, there are posts on how to build shotguns, but no more science on their behaviour. So I'm either using that thread, or have to do all testing by myself.... And those are a valuable source of information for me, as I can use those findings to compare my excel sheet results to how the game actually work. Testing is a lot of work, and it's good to have some measurements to see if I'm onto something.

For the calculations I use the values in expwnent's post and refine the other variables until I have a result that is in line with test results. For example I didn't have the concrete value of rollers, only electrobadger's asssumptions. After doing some tests and refining the calculations I'm 95% sure that he is right: using 50000 for highest speed roller in the latest test sheet with a straight track calculates 1252 tiles, according to the thread should be 1251. Other test that I ran was a loop with lowest roller, and 4 corners, and that was off by 2 tiles. On the other hand, ramps are still a complete mystery...
So I have to assume that there's still some hidden variable somewhere that is (almost) invisible when minecarts are travellling with normal speed (<1t/t), but heavily influences high speed carts. I need to design my own tests to understand what's happening, but for checking if I'm going in the right direction that thread is a godsend. So thank you for the work that you have done, I'll try to build something useful with it.

[Di]

What about turns? They seem unrepresented. Seems interesting anyway.
Also, it seems it doesn't account for minecart mass change which may happen when passing through 7/7 water.
And it'd be nice if it was showing shotgun threshold as well (~70 000).

[Snaake]

What about turns? They seem unrepresented. Seems interesting anyway.
Also, it seems it doesn't account for minecart mass change which may happen when passing through 7/7 water.
And it'd be nice if it was showing shotgun threshold as well (~70 000).

I haven't read all of the newer stuff but afaik contents, or the weight of the minecart, don't matter for it's physics calculations. Passing through tiles with water (or magma) will slow it down, but that's just increased resistance/friction in those tiles, not related to the carts filling up.

Fricy: I haven't tried your calculator, but if you're only ending up with differences of 1 tile, I'd make sure that you're properly taking into account pushing vs. roller differences (namely, pushing moves the cart a tile, or was it half a tile, before kicking it off to roll freely along the track), as well as check how you're handling that last tile that the cart moves. What I mean is, does your model require it to have enough kinetic energy to fully move into the last tile, or is over 50% enough (but the game requires 100%), and stuff like that.

[Di]

I haven't read all of the newer stuff but afaik contents, or the weight of the minecart, don't matter for it's physics calculations. Passing through tiles with water (or magma) will slow it down, but that's just increased resistance/friction in those tiles, not related to the carts filling up.

I've always thought it calculated speed through momentum. Anyway, for this setup calculator says it cart will escape pit, game says it will not:

Code: [Select]

push
track
down ramp   water 7/7
impuse ramp water 7/7
up ramp       water 7/7
track
....

[Snaake]

I haven't read all of the newer stuff but afaik contents, or the weight of the minecart, don't matter for it's physics calculations. Passing through tiles with water (or magma) will slow it down, but that's just increased resistance/friction in those tiles, not related to the carts filling up.

I've always thought it calculated speed through momentum.

Possibly, just for constant mass. So effectively it just calculates speed.

[fricy]

@DI
AFAIK minecart mass is only used by the game when two carts collide, push, rollers and ramps, etc. are uniform in this regard.
Shotgun treshold is no problem, I can show any condition. It's not represented now, because I was under the impression that shotgun speed is the same as derail speed. (>0,5 t)
Unfortunatly I can't get ramps to work in the excel sheet. ( Thx for this example, I'll use it as a test case.

@Snaake: Right now both roller and push move the cart into the middle of the next tile, they are identical. But thanks for letting me know, that explains one of my test results with a roller(40000) and a track stop(10000) right after it. I didn't understand why the cart wouldn't get past it.
By the way, the difference is almost negligible in the long run, because the majority of speed loss happens at the end of the run when a cart is slow.  For example let's take a lowest roller with 10.000 speed: the cart goes below 5000 speed in the 39th tile, and generates another ~5000 friction in the last 12 tiles.
(UPDATE: If they are not identical there should be a difference of 1 tile between push and roller low, it looks like a push should stop on the 202th tile.)
I'm using 100% kinetic energy to move to the next tile, I don't think that's the problem with the +1 tile in my example in my last post, I suspect the culprit is the second tile which I assumed to be 50000 distance as with pushes. Nevertheless, 1 tile off is good enough for now.

So, what the spreadsheet does:

You enter the track features into Column (C), liquids into column (E) & (F), and mark if it's a corner tile in (D). The spreadsheet reads those values, matches them with the appropriate friction from the datatable and adds them together in Column (L) (except for the corner friction.) This is the base friction of the tile. If you add a roller into (C) we examine the speed of the cart, if it's lower then the added roller we set the speed to rollerspeed, otherwise we ignore it. First tile is always a push or a roller, otherwise the speed would be 0.

Now we know the speed of the cart, the friction of the tile, the distance is usually 100.000, we need to now how many ticks it takes to cross a tile so we can update the speeed of the next tile:
speed[next]=speed+(basefriction*ticks)+cornerfriction

Tick calculation:
First approach was a truly ugly one: I calulated how many ticks (x) we need to cross the tile with:
distance_(x)=(distance_(x-1)-(speed+basefriction*(x-1))
for up to 25 steps, then if I had any leftovers I averaged the remaing steps. By counting how many cells I need until distance_(x) equals 0 I know how many ticks we need to cross the tile (rounded up), I assumed we cannot cross the tile on fraction ticks.

That turned out to be false, so the next formula was much cleaner:
ticks=distance/(speed+basefriction)
This does NOT update the speed between ticks, it's only updated when we cross to the next tile. And here comes a BUT: this approach works for rollers and regular tiles. It gives perfect results, the only difference I found was with the highest speed roller, there the result is 1252, and not 1251... Ramps on the other hand are off, as I mentioned.

So I assumed the next logical step would be to go back to the (ugly) first approach and update the cells so I don't ignore the fraction ticks, and maybe ramps would work. I did it, and now I'm a bit clueless because of these results:
result/expected
45/51
195/201
445/451
795/801
1245/1251

(The second column is your results for straight tracks and diff. speed rollers. For testing I'm always trying to match these values to see how close I'm to the game.)

I don't get it. The differences are all -6 tiles regardless of roller speed/travel distance. They do not scale.
I need to think. Maybe Toady is using the second formula to save CPU cycles, does not update the speed on every ticks, and ramps just do something weird with the distance calculations...

[fricy]

New version, and some interesting finds:
Changelog:
2.0

• Distance calculations are done with the 1.a formula with some modifications thanks to Expwnent's instructions. Almost every calculation is integrer based now.
• Push starts the cart in the middle of the next tile, rollers start in the beginning of the tile
• Shotgun mode added to cart behaviour
• Z level indicator added
• Formating bling-blings

After my last post I asked Expwnent for some help with distance calculations, and this is the answer I got:

When a dwarf places a minecart on a tile, the minecart is in the middle of the tile. Minecarts keep track of where they are in the tile, rounded to the nearest 1/100,000 of a tile. The progress between tiles accumulates until the minecart moves into a new tile. Suppose you're at location (2.9,0,0) and you're moving .2 tiles/tick in the (1,0,0) direction. In the next tick, you'll be in location (3.1,0,0). But all the player will see is you at tile (2,0,0), then you at tile (3,0,0).

Suppose a minecart is placed at (0,0,0), then it instantly accelerates to 2.8 tiles / tick (the maximum speed) moving in the (1,0,0) direction, even though it's impossible to accelerate that fast without cheating, and further suppose that due to various shenanigans it never slows down or accelerates for any reason. For any non-negative integer t, after t ticks, the cart will have traveled floor(.5+2.8*t) tiles, and will be located at (floor(.5+2.8*t), 0, 0). So it will go 0, 3, 6, 8, 11, 14, 17, 20, 22...

Adding these to the "first ugly approach" resulted in much joy and happiness, as the numbers began to resemble what the game produced. After counting the steps, I determined that the cart does NOT advance to the next tile when the distance calculations on a tile reach 0, but one step before, the leftover distance is added to the next tile's default 100.000. This can be observed when counting the ticks after a push: first tile is 50.000 long, starting speed is 19.990, but the cart only spends 2 ticks on the tile (distance traveled 39970) instead of the "logical" 3, and the next tile will be 110030 long.

Di's test with 7/7 water still does not work, but ramp behavior should be much closer to the game now. Expwnent's last remark in that old topic may be the key here: 

edit: Different water/magma levels have different maximum speeds. Research for later.

So this is one of my next research focus. I made some advances with testing, I found a lua script for DFhack that seems to able to dump minecart speeds and frictions from the game. It has it's own problems, so usage is not easy, I have to build a new test fort for it, but still better then counting ticks manually. If anyone's interested, just ask, and I'll tell you how to make it work.


EDIT:
For the technically inclined:

a: speed
b: base friction
c: distance (length of a tile)
Δc: lefover distance
n: steps

Calculating steps when we know the speed of the cart, the friction and the distance:

n = (sqrt(4a^2+4ab+b^2+8bc)-2a-b)/(2b)

then we round down, and the leftover distance will be:

Δc=c-na+b((n^2+n)/2)


Thank god for Wolfram Alpha. :)


About ramps: The problem is that you have to reproduce distance calculations 100% correctly, otherwise the steps spent on a tile won't align, so the friction values won't align, and when they are not 100% correct differences accumulate, you may calculate 2 steps on a ramp, while the game calculates 3 steps, which results in ~4900 extra speed, which will break the predictions. On low friction tiles these differences are negligible, and on a straight down ramp (where you can't derail) these "missteps" even out, but when you need to regulate a spiral ramp it's crucial to know the 'exact' speed, otherwise you end up slamming into a wall...
After looking at the game data my calculations at the moment (version 2.0) seem to be 99,8% correct, some of the difference is because the roller's start speed is not logical, they do start at 10k, 20k, etc. speed, but the first few ticks does not follow the regular friction calculations. At least that's what I see. I intend to correct this as I have time to carry on testing.

+Planned new feature: Minecart collision calculator, so we can know how fast a minecart will move after being hit with another.

[fricy]

Some more science:

A push will teleport a cart to the beginning of the next tile (NOT the middle!) in one tick with 19990 speed, while a roller will accelerate a cart to roller speed, and it will start to accumulate regular track friction past the middle of the roller tile. So both propulsion methods start the minecart at the beginning of a tile, but not the same one.

So why do we see a minecart skipping over a pit when pushed?

Because some track features will affect a minecart when it is past the middle of the previous tile: entering a ramp or a hole/drop and derailment checks are executed when the cart has left the middle of the previous tile, so with these track features a cart doesn't travel the usual ~100.000 distance units, but somewhere between 50.001-100.000, then the leftover distance of the tile will be added to the ramp that we enter, so on certain conditions the first ramp can be ~150.000 long, producing more acceleration then expected. Rollers also accelerate a minecart from the middle of the previous tile, and not from the beginning.

Then, when a cart leaves the ramps, it will emerge after one tick in the middle of the next regular tile, so it's entry coordinate is "50001-speed". That effectively means, that if we are going with 270.000 speed and exit the ramps the first regular tile that we enter will be 320.000 distance units long, and will start 2z levels above. That's dwarven relativity for you.
Additionally, there's a speed penalty of 4900 when exiting a long track ramp at high speeds, so you can only go with max speed on ramps, when entering a straight track you'll be ''only" travelling with 265000. The exact treshold of this penalty is to be tested.

All that's left to determine is how a minecart behaves on multiple ramps: distance unit calculations are totally different on them. What I could determine is that some kind of skipping over ramps is happening in the game, it looks like after accelerating past 160.000 speed the cart skips over every third ramp. This skipping behaviour also happens on regular tiles at high speed, meaning that you need to place your trackstops accordingly, otherwise the cart just flies past it. How skipping is determined, what's the underlying logic? Still to be resolved.

EDIT:

Here be some data dump from the game:

Code: [Select]

016-65.905400590001535400
016.29990.29990.29990.299959000153000
016.59980.29990.2999059000153000
016.89960.29980.2998-0.000159000153000
017.19930.29970.2997-0.000159000153000
017.49890.29960.2996-0.000159000153000
017.79840.29950.2995-0.000159000153000
018.09780.29940.2994-0.000159000153000
018.39710.29930.2993-0.000159000153000
018.63880.24170.2992-0.000159000152-100
018.884930.246130.34810.048959000152000
019.165630.28070.3970.048959000152000
019.480910.315280.44590.048959000152000
019.830760.349850.49480.048959000151-100
020.215190.384430.54370.048959000151000
020.63420.419010.59260.048959000150-100
021.087780.453580.64150.048959000150000
021.575940.488160.69040.048959000149-100
022.098670.522730.73930.048959000149000
022.655980.557310.78820.048959000148-100
023.247860.591880.83710.048959000148000
023.874320.626460.8860.048959000147-100
024.535360.661040.93490.048959000146-100
025.230970.695610.98380.048959000146000
025.961160.730191.03270.048959000145-100

Explanation for the 4th line:
016.89960.29980.2998-0.000159000153000

016: tile identifier
89960: distance units at exit point
29980: distance units travelled in a tick
2998: minecart speed at exit point, a zero is missing at the end...
-0.001: tile friction
59000153000: some id and shit, 153 means we are on z level 153, the 000 after 153 seems to indicate we are on a straight track without z level change in this tick, note the -100 at the end of lines of the ramps.  A corner will also show -100 at the end, when skipping over a tile we see -200, so it may be a derail check indicator instead. The others are still a mystery.

So if you try to read this data:
016: medium speed roller - first line sets speed to roller speed, then comes 3 ticks while we travel on the roller, first 2 ticks are frictionless (until we leave the middle of the tile)
017-018: regular tracks
019-025: down ramps, last tick accelerates to 103270 speed

As you can see, distance calculations are fairly straightforward on straight tracks, we change tiles when the next tick would end on the next tile, the entry point of the next tile is the leftover distance. I have tons of data to confirm that this is true.
The important thing to notice is at line 11(last tick of tile 18):

018.884930.246130.34810.048959000152000
019.165630.28070.3970.048959000152000

if the next tile were a regular tile we would be at position 93800, but a ramp is coming, so we have downramp friction, and the distance calculations switch to ramp distance calculations, so the position is 884930. Also the distance units switch to something new, we read 246130. On the next tick we enter the first real ramp section, and the distance unit calculation is : 884930+246130=1165630 - so somehow it makes sense.
(Sometimes they don't add up, but I think that's something to do with the script, as it's a bit buggy, some ticks it cannot read at all, sometimes a zero is missing from a number. Unfortunately I cannot fix it, but the read errors are easy to spot.)
 
I made some analysis of the distance units on the ramps, and the for the majority of the travel they increase with 34570/tick (280700-246130= 34570 But Whyyyyyy?). That's about all I could deduce.
I need some fresh ideas to continue.
Snaake, please tell me that you are reading this and have an idea!