Print

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

[Snaake]

Your attention please!
Below is my original post on the subject, edited with most of my results. However, there's lots of newer, more accurate info (and written much more concisely) in eg. electrobadger's and expwnent's posts (#45 and #65, respectively). I didn't feel like rewriting everything to include their data, so go read those, or hopefully the same info will end up on the wiki pretty soon.

Quantifying minecart physics

I've been thinking about doing some sort of SCIENCE before, but haven't really had any subject strike my fancy. Until now. I'd really want to have more numeric data for minecarts, similar to how we can plan a windmill farm or waterwheel power generation scheme beforehand (power is also visible in-game though), for better design of rail systems. Exactly how much roller power do you need to ramp up a level? How long can you make a flat track before the cart stops? Does is matter how strong the dwarf pushing off the cart is? What about the weight of the cart and/or its contents? Other factors?

So, the idea is to do some more quantifying of some aspects of minecarts and their physics. When I started thinking this out, I read some stuff, and while there had been some research, most of it seemed more engineering than physics  - "how do I get this thing done/this setup to work", instead of "1 roller tile of lowest-speed rollers gives a standard iron minecart x Urists of kinetic energy." The significant exceptions I found on a read-through of the entire The "How Does Minecart?" Thread were Sadrice's testing, in posts #200 and #230, and xmoffitt's, in posts #441 and #488. At least Sadrice was using versions 34.08-34.09, I think. So some of this is verification of their results for 34.11 (even though I don’t think any of the numbers have changed since 34.08, and anything for minecarts in any way since 34.09), other stuff will be new SCIENCE. If I've missed any other results like these, please point them out, I would be very interested to compare results.

Assumptions/hypotheses and areas of research are listed below. I'll be using empty minecarts for now. Contents will weigh down the minecart, but the effects of that will have to be tested separately. I'll start off with pushing minecarts, since guiding doesn't really involve the physics at all, treating the minecart like a big, tracks-only wheelbarrow with more elaborate options, and riding is like pushing but with the dwarf as extra contents. I'll start with the speed gained from pushes, move onto the slowing effect of a flat track, then the friction of track stops, rollers of varying speed, then speed gained/lost from ramps,and finally fluids. This post will have a list of all the assumptions and their current status. Then, I'll post the actual descriptions/narrative of the experiments. I hope you'll forgive the multi-post, since my RTF of this is about 8 pages long. I will put some stuff in spoiler tags, so you don't have to scroll as much. I was originally going to post this in The "How Does Minecart" Thread, since that's where the previous results were posted, and it was my inspiration as well; however, it is already 39 pages long, and doesn't seem to collect much interest anymore, hence the new thread.

List of stuff to test:
#1-6 (pushing, tracks and turns) - mostly done:

Spoiler (click to show/hide)

#1: Minecart physics have no randomness. They are governed by a definable set of equations, probably some approximation of Newtonian mechanics. Exception: Some (small?) variability due to rounding to the tile grid and such may be observed. (Assumption, proof for some scenarios acquired)

#2: A push by the same dwarf will always give a specific minecart the same speed or possibly energy/momentum. (Assumption, verified; but see below)

#3: Factors affecting speed gained from push - which of the following matter: strength of the dwarf, weight of the minecart, other? How much energy/momentum/speed is imparted? First testing by Sadrice (post #200), but his track had turns. Sadrice did discover that a minecart always travels the same distance, regardless of contents, minecart material (=weight), or dwarf strength. (Measured/Verified; speed/distance traveled is always identical)

#4: 1 tile of track has some (small) amount of friction, and causes the cart to slow down. How large is this amount? (Measured; a cart stops on the 201th tile after the initial hauling stop on a straight track)

#5: My initial guess was that track turns wouldn't slow down the cart any more than any other track square. Sadrice had already found this to be false (post #230), though, stating that they have about 11 times the friction of a straight track tile. So 10 additional tiles worth of friction? (Measurements made indicate between 9-13 additional tiles worth of friction depending on the situation, no definitive answer)

#6: Carved and constructed tracks have the same friction, also regardless of material, ie. are always functionally identical. (Assumption, verified)

#7-8 (bridges and track stops) - mostly done:

Spoiler (click to show/hide)

#7: Bridges have same friction as track tiles. They're not functionally identical, since dwarves guiding minecarts will not treat bridges like they do tracks, i.e. they will choose the shortest path if on a bridge. (Assumption, verified)

#8: Measuring the friction of track stops of varying settings. Also, does the dumping setting matter for friction? In a complex world, it'll matter only for non-empty minecarts; this will have to be tested at a later date, only empty carts for now. Fluids may be useful standard weights for testing this. xmoffitt came up with some data on this on page 30 (Measured up to medium: lowest = no extra friction, low = 4 tiles of extra friction, medium about 40-50 (I measured 52) tiles of extra friction. High is at least, maybe exactly, 800. Highest might be infinite friction, but no certainty on that yet. Add the base 1 tile of friction from the track to these values.)

#9-11 (ramps) - testing done, no simple answers found:

Spoiler (click to show/hide)

#9: How much speed/energy does ramping 1 level down give? Does the ramp have regular track-tile friction? (subject to variation, but about 560 Urists, or as little as 470ish Urists if the cart has almost stopped before ramping down; regular track-tile friction probably applies)

#10: How does falling down 1 level compare to ramping down 1 level? This is related to whether ramps have regular track-tile friction, and to how falling/the parabolic paths work in general; probably only going to test a 1-z drop at this point. (Parabolic flight path, no track friction during it (of course). Depending on speed, the cart can go multiple tiles horizontally before it falls 1 z-level. Not testing flight paths more at this point.)

#11: How much speed/energy does ramping up 1 level take? Does the ramp have regular track-tile friction? I can't think of a way to test the latter at the moment, but it can probably be assumed that whatever holds for down-ramps is also true here. (Also variable, but results indicate that on average, somewhat less energy is required to ramp up than down, usually giving a net gain of energy; however net losses are also common; up-ramp friction not tested due to no ideas on how to do it)

#12-16 (rollers) - partially/mostly done:

Spoiler (click to show/hide)

#12: Unpowered roller tiles are identical to regular track tiles, and powered roller tiles have regular track tile friction, but no other friction effects. (Assumption, verified)

#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)

#14: Does it matter if you have 5 one-tile rollers, or 1 five-tile roller? (To be measured)

#15: Is there a max speed that rollers accelerate to, as many have stated/the current consensus states? (To be measured)

#16: Can a track go over a roller in the opposite direction, if the rollers are low-strength, and the cart is going fast enough? What are the effects of this/is it possible to calculate the speed afterwards? (Might be possible, but at least low vs. lower isn’t enough. Hence it definitely isn't something simple like the "braking" roller subtracting it's speed from the cart's current speed)

#17-21 (derailing and fluids) - abandoned/left for others to test:

Spoiler (click to show/hide)

#17: The physics of derailing (on turns): How much speed is needed, and how much friction do non-track tiles have, or is some other model used for bringing the cart to a halt? (To be measured)

#18: How much does 1 tile of water slow down a minecart, for different depths of water?  (To be measured)

#20: Is ramping up/down affected by water; is a ramp down with water on it the same as a ramp down, plus a flat tile with the same amount of water on it? (To be measured)

#21: Is magma the same viscosity as water, i.e. does it slow down carts by the same amount? (To be measured)

Later research questions - left for others, as planned originally:

Spoiler (click to show/hide)

- If a max speed from rollers exists, do carts going faster than this get set to this max speed if they go over a roller?
- Is there a max speed (set by the air friction) for regular tracks without rollers? (Lots of down ramps! !!SCIENCE!!)
- If so, does water/magma have a (lower) max speed that the cart slows down to immediately on contact?
- Inspired by this post, is it possible to build a dwarf-powered long-distance minecart system using the possible behavior that a minecart colliding into another comes to a stop, and imparts all of its kinetic energy to the 2nd cart (totally elastic collision?)? In other words, does this happen and is the collision totally elastic, or is some energy lost in the collision? (Collisions do happen, and most, but not necessarily all, of the colliding cart's momentum is transferred to the collidee; see this
- I'm also leaving all parabolic trajectory research, as well as speed research, for others to do for now, although some results regarding speed can of course be deduced from the results I'll be getting.

Note on units:

Spoiler (click to show/hide)

Throughout the text, I’ve mostly been using tiles of distance as units, sometimes calling them Urists. These are actually units of work/energy, as in, 1 Urist/tile of friction = The work done by the friction of a track over 1 tile. At least for track-related minecart physics, the mass of a cart doesn’t seem to have any effect on it’s behavior (not necessarily true for impacts, parabolic flight paths, or skipping on fluids, to mention some cases where the opposite might be true). If we take xmoffitt’s measurement of a dwarf push giving an initial speed of 0.2 tiles/tick and assume that for track physics, a minecart’s weight doesn’t affect it’s kinetic energy, but that the kinetic energy is rather just purely ½v², the initial energy is 0.02 tiles²/tick². The work 1 tile of track does as friction is then 0.1 milli(tiles²/²). Thus 1 tile²/tick² = 10 000 Urists, and a dwarf pushes a cart off at 200 Urists (see discussion at end of #2 experiment). I have not done (almost) any measurements of speed (in tiles/tick) as a function of distance or time, unlike xmoffitt.

I'll be posting the more detailed descriptions of the results/setup in later posts, but will edit any knowledge into the list above. I've uploaded the save folder to DFFD, if you want to do some testing with ready-made tracks (read the DFFD description and preferably the epilogue, which will come in the last of my initial experiment posts here, to get an idea what you're getting into with the fort). The version is 34.11, Phoebus tileset.
I'll be editing some results to the wiki, if they seem reliable. Feel free to test any/all of this yourself too, either for more verification, or new research into the stuff I haven't gotten into yet. It's very likely I won't have the attention span to test everything listed above in full detail; I will try to get at least some results for everything, though.


edit:
my first post describing the experiments ended up as reply #5, so scroll down a bit.
3rd post describing results (questions #9-11) is #21. Short versions of results also added above.
As of 25th July 2012, I'm not actively working on this anymore (will still try to check in on the thread, but not doing testing). See post #33.

[darkrider2]

Welp, watching this thread, and possibly participating later on.

[xmoffitt]

One thing I discovered in my research, is that the truncation of continuous units speed and positions onto discrete units of tile location and time has a huge effect.   For example, a trackstop placed at tile "15" could have much different slowdown distance than a trackstop placed at tile "16" because the linger time is 3 ticks versus 2 ticks.

Here is a python program I wrote that models the physics and exactly reproduces all stop-distances for lowest,low, and medium trackstops.  I left off in the middle of trying to figure out what ramps do, so no guarantees on usability.

Spoiler (click to show/hide)

Code: [Select]

import sys
import logging
import numpy

loglevel = logging.WARN
if( '-v' in sys.argv ):
    loglevel = logging.INFO

if( '-vv' in sys.argv ):
    loglevel = logging.DEBUG

logging.basicConfig( stream=sys.stdout, level=loglevel )

LOG = logging.getLogger()
LOG1 = logging.getLogger( 'timelog' )
LOG2 = logging.getLogger( 'delaylog' )

UNK = 999

XIDX = 0
ZIDX = 1
FORWARD = numpy.array( [1,0] )
DOWNHILL = numpy.array( [1,-1] ) ## toady said 2,2,3 was the box at one point

##DOWNHILL = FORWARD

class Track(object):
    '''All values found experimentally using the runout distance measurement'''

    DATA = [                                # DERVIED FROM RUNOUT WITH FEATURES:
        ('T',  'TRACK'            , 0.1),   # T only, -and- tile delay log
        ('TT', 'TRACK_TURN'       , 1.77),  # T, TT
   
        ('SLL', 'TRACKSTOP_LOWEST' , 0.1),  # T, SLL
        ('SL',  'TRACKSTOP_LOW'    , 0.5),  # T, SL
        ('SM',  'TRACKSTOP_MEDIUM' , 5),    # T, SM
        ('SH',  'TRACKSTOP_HIGH'   , 86.45),# T, SM, SH, **RD**
        ('SHH', 'TRACKSTOP_HIGHEST', UNK),
   
        ('RLL', 'ROLLER_LOWEST'    , 0.1, 50, 131 ), # T, SM, RLL. ??accel is rough
        ('RL',  'ROLLER_LOW'       , 0.1, 27, 200),  # T, SM, RL
        ('RM',  'ROLLER_MEDIUM'    , -13.1),# T, SL, SM, RM
        ('RH',  'ROLLER_HIGH'      , -UNK), # T,
        ('RHH', 'ROLLER_HIGHEST'   , -UNK), # ???

        ('TD', 'TRACKRAMP_DOWN'   , 0.0, 49.74, None, DOWNHILL ), # ???
        ('TU', 'TRACKRAMP_UP'     , UNK ),  #

        ('F',  'FLOOR'            , 2 ),     # F only, -and- T, F
        ]

    @staticmethod
    def friction(values):
        '''takes a number or list (e.g. from DATA) and returns the friction'''

        if( isinstance(values,list) or isinstance(values,tuple)):
            return values[0]
        else:
            return values

    @staticmethod
    def acceleration(values):
        if( isinstance(values,list) or isinstance(values,tuple)):
            if( len(values) > 1 ):
                return values[1]
        return 0

    @staticmethod
    def maxspeed(values):
        if( isinstance(values,list) or isinstance(values,tuple)):
            if( len(values) > 2 ):
                return values[2]
        return 0

    @staticmethod
    def direction(values):
        if( isinstance(values,list) or isinstance(values,tuple)):
            if( len(values) > 3 ):
                return values[3]
        return FORWARD


    def __init__(self):
        for data in self.DATA:
            shortname, longname = data[:2]
            values = data[2:]
            values = Track.friction(values), Track.acceleration(values), Track.maxspeed(values), Track.direction(values)
            setattr(self,shortname,values)
            setattr(self,longname,values)

def sign(x):
    return cmp(x,0)

class Cart(object):
    position = None   # x,y array measures in tiles
    velocity = None   # x,y array measured in microtiles/tick

    def __init__(self):
        # array dimensions are x,z
        self.position = numpy.array( [0,0], dtype=numpy.float32 )
        self.velocity = numpy.array( [0,0], dtype=numpy.float32 )

    def setPosition(self, x=None, z=None):
        if( x is not None ):
            self.position[XIDX] = x
        if( z is not None ):
            self.position[ZIDX] = z

    def getdistance(self):
        return self.position[XIDX]
    distance = property(getdistance)

    def nextPosition(self):
        # units of speed are microtiles per tick.
        return self.position + self.velocity / 1000

    def limitSpeed(self, max_speed):
        '''decrease speed to at most max_speed'''
        curr_speed = self.speed
        if( curr_speed > max_speed ):
            self.velocity = max_speed * (self.velocity / curr_speed)
        LOG.debug( 'limitSpeed to %s', max_speed )

    def getspeed(self):
        return numpy.linalg.norm(self.velocity)
    speed = property(getspeed)

    def addSpeed(self, delta_speed, direction=None):
        '''accellerate (add speed) in a (direction is array) or along current dir (direction is None)'''

        if( direction is not None ):
            direction = direction / numpy.linalg.norm(direction)
        else:
            direction = self.velocity / self.speed

        LOG.debug( 'addSpeed %s PLUS %s going %s', self.velocity, delta_speed, direction )
       
        self.velocity += (direction * delta_speed)

        LOG.debug( 'addSpeed EQUALS %s', self.velocity )

    def subSpeed(self, delta_speed ):
        '''accellerate opposite current direction, never change direction'''

        curr_speed = self.speed

        delta_speed = min( curr_speed, abs(delta_speed))

        self.addSpeed( -delta_speed )

    def setDirection(self, direction):
        '''preserve the current speed, but change the direction'''
        direction = direction / numpy.linalg.norm(direction)

        #LOG.warn( 'direction changed to %s', direction )

        curr_speed = numpy.linalg.norm(self.velocity)

        self.velocity = curr_speed * direction

    def __str__(self):
        return 'Cart[ @ %s --> %s ]' % (self.position, self.velocity)

class Race(object):
   time = 0     # measured in ticks (int)
   course = []  # list of tile friction values along the route.
   cart = Cart()

   def __init__(self, course):
       self.course = course
       self.delays = [0] * len(course)
       self.prevtime = 0

   def impulse(self):
       self.cart.addSpeed( 200, direction=FORWARD )
       self.cart.setPosition( x=1.5 )

   def tick(self):
       self.time += 1

       LOG.info( 'time %s, cart %s', self.time, self.cart )

       # STEP1.  lookup tile values from current location. 
       # assume linear track along X.
       location = int( self.cart.position[XIDX] )
       tile = self.course[location]
       
       friction = Track.friction( tile )
       accel = Track.acceleration( tile )
       maxspeed = Track.maxspeed( tile )
       LOG.info( 'Track stats at %s.  friction %s, accel %s, maxspeed %s', location, friction, accel, maxspeed )

       # STEP2.  update speed based on acceleration from ramp/roller.
       if( accel ):
           LOG.info( 'applying accel of %f', accel )
           self.cart.addSpeed( accel )

       # STEP3. limit speed to the speed limit (applicable for rollers)
       ### TODO.. unknown if rollers deccelerate (and how much) when above max speed
       if( maxspeed ):
           self.cart.limitSpeed( maxspeed )

       # STEP4.  update speed based on decceleration from friction.
       LOG.debug( 'applying friction of %f', friction )
       self.cart.subSpeed( friction )

       # STEP5.  calculate position based on speed.
       nextpos = self.cart.nextPosition()

       nextlocation = int(nextpos[XIDX])
       if( nextlocation != location and nextlocation < len(self.course) ):
           # update delay stats.
           delay = self.time - self.prevtime
           self.delays[location] = delay
           LOG2.debug( 'delay %03d,%02d', location, delay )

           # STEP6. check interaction effects with destination tile
           nexttile = self.course[ nextlocation ]

           # tracks yank the cart into the desired direction!
           nextdirection = Track.direction( nexttile )
           #LOG.warn( 'next direction at %s is %s', nextlocation, nextdirection )
           self.cart.setDirection( nextdirection )


           self.prevtime = self.time

       self.cart.position = nextpos
       
       #prevlocation, prevtime = self.prev
       #if( location != prevlocation ):
       #    delay = self.time - prevtime
       #    self.prev = (location, self.time)


       return ( self.cart.speed <= 0 )

   def dumpCourse( self, size=30 ):
       
       markers = ['  .  '] * size
       frictions = ['  .  '] * size
       accels = ['  .  '] * size
       speeds = ['  .  '] * size
       for x in xrange(0,min(size,len(self.course))):
           if( x % 10 == 0):
               markers[x] = '%5d'%x
           frictions[x] = '%05s' % ( '%02.1f'% Track.friction(course[x]) )
           accels[x] = '%05s' % ( '%02.1f'% Track.acceleration(course[x]) )
           speeds[x] = '%05s' % ( '%02.1f'% Track.maxspeed(course[x]) )
       LOG.info( ' '.join( markers ))
       LOG.info( ' '.join( frictions ))
       LOG.info( ' '.join( speeds ))
       
   def run( self ):
       LOG1.debug( 'Tick,Dist,Speed' )
       LOG2.debug( 'Tile,Delay')

       #self.dumpCourse()

       self.impulse()
       while( self.time < 10000 ):
           self.tick()
           LOG1.debug( '%03d,%0.2f,%0.1f', self.time, self.cart.position[XIDX],
self.cart.speed )

           if( self.cart.distance >= len(self.course)):
               LOG.info( 'Course overrun at time %d, final speed %f',
                         self.time, self.cart.speed )
               break
           if( self.cart.speed <= 0 ):
               LOG.info( 'Cart stopped at final distance %d', self.cart.distance )
               break

       return int(self.cart.distance)

class Solver(object):

    MAXVALUE = 10000

    def __init__(self, course ):
       '''Attempt to determine the friction/accel values of the feature repeated
       at each point in testreange.'''
       self.course = course
       self.setVariables()
       self.setTargets()

    def setTargets(self, stopdist=0, tiledelays=None):
        self.stopdist = stopdist
        self.tiledelays = tiledelays ## tuples of (course-index,delay)

    def setVariables(self, *testvariables):
       self.testvariables = testvariables ## tuples of course-index, tile-index

    def test(self, *values):
        if( len(values) != len(self.testvariables)):
            LOG.warn( 'bad test values, need %s numbers', len(self.testvariables))
            return

        for vv in xrange(len(values)):
            cidx, vidx = self.testvariables[vv]
            newtup = list(self.course[cidx])
            newtup[vidx] = values[vv]
            self.course[cidx] = newtup

            LOG.info( 'TEST course[%s] <-- %s', cidx, newtup )

        r = Race(self.course)
        dist = r.run()

        ## positive error means "too fast"
        rv = []
        msgs = []

        tmp = 'stop %s' % dist
        if( self.stopdist ):
            err = dist - self.stopdist
            tmp += ' (%+d)'%(err)
            msgs.append( tmp )
            rv.append( err )

        if( self.tiledelays ):
            msgs.append( 'delays' )
        for idx, delay in self.tiledelays:
            err =  delay - r.delays[idx]
            msgs.append( '%s (%+d)'%(r.delays[idx], err) )
            rv.append( err )

        LOG.info( 'TEST %s -> %s', ' '.join(map(str,values)), ' '.join( msgs ))
        return rv
   
    def sweep(self, bound1, bound2, maxdecimals=1):

        rounder = pow(10,maxdecimals)
        r1 = int(min(bound1,bound2)*rounder)
        r2 = int(max(bound1,bound2)*rounder)

        LOG.warn( 'Sweep rounder %s, %s, %s', r1, r2, rounder )

        for value in xrange(r1,r2+1,1):
            value = value / float(rounder)
            result = self.test( value )

            yield value, result
           

    def search(self, maxdecimals=1, hint=None):
        value = 0
        result = 1

        rounder = pow(10,maxdecimals)

        upper = self.MAXVALUE
        lower = 0

        if hint:
            lower,upper = hint

        for limit in xrange(0,1000):

            value = (upper + lower) / 2.0
            value = int(rounder*value) / float(rounder) # require

            if( value == upper or value == lower ):
                break
 
            result = self.test( value ) [0]
           
            if( self.testindex == 1):
                # accel and maxspeed have opposite direcition as friction in solution finding
                result = -result

            if( result < 0 ):
                upper = value
            elif( result > 0 ):
                lower = value
            else:
                break

            if( upper == lower ):
                break

        if( result != 0 ):
            LOG.warn( 'NO SOLUTION! target was %d, with maxdecimals %d', self.stopdist, maxdecimals )
        valuetup = self.course[self.testrange[0]]
        LOG.warn( 'Final value at %s is %s, last bounds (%s < x < %s)', self.testrange, valuetup, lower, upper )

#----------------------------------------------------------------------
#----------------------------------------------------------------------
#----------------------------------------------------------------------

track = Track()  # singleton

import unittest
class RaceTest(unittest.TestCase):

    def test_flat(self):
        course = [track.T] * 500
        r = Race(course)
        self.assertEqual( r.run(), 201 )
   
    def test_low(self):
        course = [track.T] * 500

        course[50] = track.SL
        r = Race(course)
        self.assertEqual( r.run(), 197 )

        course[60] = track.SL
        r = Race(course)
        self.assertEqual( r.run(), 193 )

    def test_medium(self):
        course = [track.T] * 500
        course[10] = track.SM
        r = Race(course)
        self.assertEqual( r.run(), 148 )

        course = [track.T] * 500
        course[20] = track.SM
        r = Race(course)
        self.assertEqual( r.run(), 149 )

    def test_ramp(self):
        course = [track.T] * 500
        course[6] = track.TD
        for x in range(10,25):
            course[x] = track.SM

        r = Race(course)
        self.assertEqual( r.run(), 55 )

suite = unittest.TestLoader().loadTestsFromTestCase(RaceTest)
#unittest.TextTestRunner(verbosity=2).run( suite )


maxdecimal = 1
if( '-0' in sys.argv ):
    maxdecimal = 0
if( '-1' in sys.argv ):
    maxdecimal = 1
if( '-2' in sys.argv ):
    maxdecimal = 2


course = [track.T]*500


TESTIDX = 6
course[TESTIDX] = track.TD

for x in range(10,25):
    course[x] = track.SM
r = Solver( course )

r.setVariables( (TESTIDX,1) )
r.setTargets( stopdist=55, tiledelays=[(TESTIDX,5)] )

#for x in range(10,24):
#    course[x] = track.SM
#r = Solver( course, stopdist=105, testrange=[6], testindex=0 )

#for x in range(10,23):
#    course[x] = track.SM
#r = Solver( course, stopdist=155, testrange=[6], testindex=0 )

if( 'solve' in sys.argv ):
    ## TODO.. additional constraint to solver.  linger over testindex range!
    r.search( maxdecimals=15, hint=[1,80])

if( 'sweep' in sys.argv ):
    for value,error in r.sweep( 0, 80, maxdecimals=0):
        LOG.warn( 'sweep %s %s', value, error )


if( 'run' in sys.argv ):
    #value = 39.3
    value = 0
    error = r.test( value )
    LOG.warn( 'run %s %s', value, error )


[Trif]

I did some research on parabolic paths (#10) in Kelnimar. (here and here)

Spoiler: Setup (click to show/hide)

z20
z21
Minecarts get dropped on the rollers from above to avoid any initial (horizontal) velocity.

I also tried it with a ramp at the end.

Spoiler: Results (click to show/hide)

trajectory of a minecart after acceleration by 10 rollers


trajectory of a minecart after acceleration by 10 rollers, launched using a track ramp

Note the small gap near the end of the arc: this z-level was skipped by the minecart (I repeated the experiment twice). This means that the minecart was faster than 1 tile/tick after falling for 21 z-levels.

both trajectories in one graphic

You can download the fortress and check my results (or use the setup for further falling ‼Science‼) over here.

I also tried it with 20 rollers, and the trajectories were identical. The maximum roller speed (#15) must be lower than or equal to ten rollers.

[goladith]

I blame the Higgs-Boson.

[Snaake]

Okay, so the descriptions of what I did start here. I hope you'll excuse the relatively free-form, written-as-I-went style. I'll try and edit some of the more number-heavy, repetitive text into more of a standard list format or something. I'll be putting the text in a few big blocks, and spoilering those, so you can read the sections you want and hide the rest. If the text feels too small, ctrl- +/- is your friend (or whatever your browser's zoom feature has as a hotkey).

So, here goes. Spent some time looking for a decent embark. 5x5 is a bit more than 200x200 tiles, and is necessary to fit a straight track long enough.
Results for #1-4 and #6.

Spoiler (click to show/hide)

First off, setup and a long, straight, flat, carved track, north-to-south. Built some basic food production and a dormitory, carved a long track, turned minecart pushing off from all but one average-strength dwarf. Pushed the alder minecart  (basic quality, weight 16 Urists) down the track a few times with her. The cart consistently came to a stop 201 tiles away. My hypothesis for this is that the dwarf "lifts" or maybe guides the to the square next to the stop, then kicks it off at an even 200 Urists (see note regarding units above). A cart doesn't "feel" the friction of the square it gets pushed out of. Probably so it can ignore the friction of the hauling stop, which will often/can have a highest-friction track stop. #1 and #2 proven (1 only for basic stuff, higher speeds would be more prone to rounding issues etc.), the friction of a tile measured for #4, at 1 millitile/tick^2. Basically repeats of Sandrice's and xmoffitt's earlier, similar experiments.

Meanwhile, I also constructed a similar long, straight track out of shale blocks, and pushed off an -iron minecart- (weight 314 Urists) with her a couple of times. Then I switched the carts around. Carved tracks & constructed tracks were the same, and the cart's weight didn't matter. Enabled vehicle hauling/pushing on other dwarves, all gave it the same initial speed. Result for #3: All dwarf-pushes are equal.

I'll be using Sadrice's suggestion of tiles traveled as the units of speed, or rather, units of impulse/kinetic energy. Like for Sadrice, the important thing to me is whether a cart reaches the destination, not necessarily how fast. If a cart travels 200 tiles, it initially has 200 Urists of energy. Per tile of straight track, 1 Urist of work is done by the track friction.

As mentioned, I'm not going to be done one-step measurements of speeds for everything, but I did do a count here with the conclusion that moving the last tile (200th->201st) took 79 frames (counted it twice, manually, no macro). The 2nd-to-last tile took 51 frames by my counting (only counted that once). *shrug* Not really going to use those values for anything, but it's worth noting that they're probably always the same for this setup (if there's any %-based slowdowns in other track setups, these values will not be the same.

Moving onto #5.

Spoiler (click to show/hide)

Switching to only using wooden carts for faster hauling to the start (the hauling route only has the stop at the start; it gets carried back there). I tested:
- 1 u-bend
- 2 u-bends (converted part of the original carved straight track for these)
- a squiggly track with nothing but turns: cart goes east, north, west, north, east, north, west... switching direction every tile
- zigzag turn A (cart goes S, turns W, immediately followed by turn S again), plus u-bend
- 1 turn west
- 1 turn west (same as previous) + 2nd turn (north) later
- 1 turn west (at different distance from start)

Results gave varying values for the effect of the turns:
- 1 u-bend on the 101st tile: cart traveled 74 tiles after = total 175 tiles => u-bend "cost" 26 tiles, for 13 tiles/turn
- u-bend on 101st tile, another on 44th tile after that: cart traveled 17 more tiles = total 162 tiles => 2 u-bends had a total cost of 162 tiles => 2 u-bends cost 39 tiles, for 9.25 tiles/turn.
- nothing but turns: cart moved 18 tiles (verifying Sadrice's result), for average cost of 11 and 1/6th of a tile/turn (probably some remainder gets dropped here)
- zigzag A: 2 turns at 10th tile, then u-bend on 92nd tile after that: cart traveled 42 tiles after that = total 144 tiles => total friction 57, cost per turn average of 14.25.
- 1 turn west on 101st tile: cart traveled 86 more tiles = total 187 => turn cost 14 tiles.
- 1 turn west on 101st tile, turn north later on 49th tile after: cart traveled 29 tiles = total 179 => turn cost 11 tiles/turn (same result as Sadrice, post #230)
- 1 turn west on 42nd tile: cart traveled 145 tiles = total 187 => turn cost 14 tiles.
With zigzag A, I also initially ran it accidentally with 1 non-carved floor tile in between: in that run the cart went 16 tiles less, which is pretty close to what xmoffitt stated for floor friction. So we accidentally got some data for #17.

I think I'll end number 5 here for now with a general statement that the amount of speed lost to a turn is between 9-14 millitiles/tick, and that there's probably at least some geometric component to this loss of speed or kinetic energy, rather than just being a constant friction value like for straight tracks. All this uncertainty definitely casts a shadow of Sadrice’s initial roller tests in post #200, at least. :/

#7-8:

Spoiler (click to show/hide)

#7: Built five 1*10-tile retractable bridges on the constructed track, should be enough to show any effect. Full 201-tile of distance achieved, so same friction as tracks.

#8: Started building various track stops. Lowest-friction track stops don't slow down the cart any more than any other track tile; in other words, their sole function is to allow dumping on the go. "Low" cost an extra 4 tiles of distance, so a total of 5 when you count the underlying track. "Medium" was 52 tiles of distance lost, so total of 53 Urists of friction, probably the most useful amount for flat-land tracks. As mentioned previously by others, high and highest stop a pushed minecart right away (tested with stop adjacent to the start, and with 1 tile of track in between); they will be useful/necessary for systems with ramps and/or rollers though. Testing on these will be postponed for now. The values obtained for lowest and low track stops are compatible with xmoffitt's. No difference in distance reduction with dumping track stops compared to non-dumping ones.

Editing comment on the above: Upon rereading xmoffitt’s post #441, I noticed that he had gotten variable amounts of friction for medium stops, depending on it’s location. D’oh! *facepalm* and all that; don’t think I tested for that back when I originally did these track stop measurements. This calls into question all the later roller results obtained using medium track stops as well. However, he did also state that low track stops were a reliable 4 extra friction, so those results should still stand (just without any other measurement sources to back them up).

#9-11 postponed in favor of roller testing.

#12-13:

Spoiler (click to show/hide)

Point 12: Built some 10-long (max length) S->N rollers on my straight N->S track, no power. Still the same 201 squares, so assumption verified.

Point 13: Supplied 20 power from a windmill, power used: 10 for gears (2), 2 for the highest roller tile. Using the N->S long, straight and flat track, with 0 initial speed by having an open space above the roller start, and on the level above a hauling stop to the east of that, with “immediately always push west”. This causes the cart to drop onto the start tile with no speed. 1 tile of roller at “highest” () zoomed across the map, hit the map edge at about 218 tiles traveled. Likewise with “high,” and “medium” was still going pretty fast at the end too – when Toady said he’d increased the speeds gained from rollers for 34.08, he wasn’t kidding! (I think I last used them with my 34.07 fort ) On “low”, the cart travelled 201 tiles if I include the initial roller tile. This would mean that 1 tile of low-speed rollers gives it the same speed as a dwarf’s push, but unlike the dwarf’s push, it wouldn’t ignore the tile it starts in, again supporting the “the dwarf guides the cart off the stop into the next square, then pushed it” theory (theory in the scientific sense: a hypothesis with empirical evidence). Basically, the roller tile is equivalent to the tile after the hauling stop in a dwarf-pushed version. For uniformity, I'm going to say that a low roller gives a cart 200 Urists of kinetic energy. On “lowest,” the cart traveled 50 tiles after the roller. Interestingly, power consumption for the 1-tile rollers was 2 throughout, regardless of setting.

Time to add some braking systems, so I can test the higher-energy stuff. Added 1 medium-strength track stop to the medium roller test. Not enough, and neither were 2 or 3 medium track stops. At this point I was still continuing with the assumption that the placement of the stops doesn’t matter, as it didn’t seem to, back in #8 (didn't seem to with low stops, didn't necessarily test medium stops/can't remember if I did). Finally, with 6 medium track stops, for a total of 6*52=312 extra friction, the cart stopped at the 145 tile mark, for a total of (approximately) 457 tiles with medium rollers (editing comment: my original result for medium track stops was 52 extra tiles of friction; not changing these calculations here, even though they're probably wrong). For “high” rollers, went straight to 10 medium track stops, but in the end needed 12 (*52=624 extra tiles worth of friction) to stop it at the 191 tile mark, for a total of approximately 815 tiles worth of speed. For highest, I initially tried 18 medium track stops, but eventually stopped it at 145 tiles with 22 medium track stops (*52=1144 Urists), for a total distance equivalent of approximately 1289 tiles. Some, or maybe even all, of these values may have additional errors due to human mistakes (accidentally having 1 low track stop in there), of course.

So - time for cross-checking, in the form of rollers vs. loads of low track stops. At lowest speed, the cart rolled 19 tiles, which included 8 low track stops, for an equivalent distance of (8*4+19=) 51 tiles. Multiple track stops and low vs. medium track stops checking out so far. With low speed, the cart rolled 45 tiles, including 39 low track stops, for an equivalent distance of (39*4+45=) 201 tiles. Checks out again. With medium speed, the cart traveled 95 tiles, including 89 low track stops, for an equivalent distance of (89*4+95=) 451 tiles, which is slightly different from previous values. I had barely enough track to test high speed rollers, which came out to a distance of 201, 150 low track stops, equivalent distance (150*4+201=) 801 tiles. Previous value was different again, time to take apart all these low track stops and redo those 2 medium ones, also the highest rollers/medium stop one. Retesting with medium rollers had the cart go 169 tiles (6 medium track stops), equivalent distance 481 tiles, then 155 tiles (still 6 medium stops, but rebuilt them since I thought I might’ve had a low one in the previous), equivalent distance 467 tiles (tested this one a few times, including a rebuild on the same spot), then (moved the 6 medium track stops 1 tile further from the roller) 156 tiles = equivalent distance 468 tiles. All different values - something definitely fishy is going on here. I thought I had tested and came to the conclusion that the location of said track stop didn’t matter in #8; I guess I forgot to test the effect of the position of a medium track stop. The cart is only going at a speed somewhere between 3-4 ticks/tile right after the roller, so I don’t think there should be any “tunneling” effects, where it skips a tile. Rather, I think this might be something inherent to medium and above track stops: their location on the track matters, possibly because their braking effect is dependent on the current speed or energy of the cart.

I’ll admit at this point that one reason why I postponed ramp testing was that my initial plan was to slow the cart down to an absolute minimum using track stops prior to ramping it down, preferably so it would spend it’s last square of movement to enter the ramp. However, when I built a nice combination of medium(3) & low(7?) track stops that should’ve done the trick, it ended up still having a few tiles’ worth of movement left, which perplexed me.

Editing comment: As mentioned at #8, the measurements that used medium track stops are not completely reliable; looking at the cross-check above, multiple medium track stops never all function at a full 52 Urists of friction, at least; all the roller speed values using them for the estimates are higher than the ones measured with low track stops. Should probably remove 1 from all the roller power measurements above as well (for uniformity with pushing), for 50/200/450/800 Urists from lowest to high rollers, and based off the approximate 1289 tiles for a highest roller that was measured with medium track stops, I'll hazard a guess of 1250 Urists for "highest" rollers.

Small sidetrack to #16, then medium+ rollers for #13 & high/higher track stops for #8:

Spoiler (click to show/hide)

I want to get some results for the higher-energy #8 and #13, even if they may be uncertain/rough ones, due to this new medium+ track stop dilemma. I’ll be assuming that the values measured with low track stops are the correct ones, for now (so 50/200/450/800 for lowest to high rollers). Mostly because they’re nice and neat (=seem like something Toady might’ve set them to), and at least the first two did match flat-track measurements with no track stops.

#16: Prior to actual testing, I had envisioned weak opposite-direction rollers as an alternate system to check the roller speed results I’d obtained with medium track stops - actually tested this before the cross-checking with low track stops above, and all the rechecking that weirdness that ensued from that. So, switched out the initial roller to low speed and put a lowest speed one in the opposite direction in front of it. First tested with the rollers adjacent to each other, so it gets power from the N->S roller, then with the second roller some 20 tiles away. The speed from the low roller isn’t enough to make the cart go over the lowest speed roller; it just ends up bouncing back and forth between the two. So while this may be/probably is possible with higher speeds, I think it’s doubtful that it’ll be very useful or practical as a braking system; better to use high/highest track stops instead.

#13 and #8 (high-energy versions): Ok, medium rollers and 1 high track stop. Fully stopped on the track stop, even at only 1-2 tiles’ distance from the roller. Ditto with high rollers. Highest rollers, highest track stop. Before I could test this, I got my first ambush when the human caravan arrived: a squad each of goblin axemen and hammermen (I thought I had invaders off, but I guess not? Or maybe that only affects sieges). They proceeded to slaughter most of my war dogs, but with the help of the humans and by recruiting anyone who knew which end of a weapon to hold, the goblins were defeated at great cost.

Anyway, back on track (pun intended), highest rollers and highest track stop – cart stops at the track stop. Maybe highest track stops just stop any cart, regardless of speed? I’ll probably check again when testing ramps later, since testing so far (by other people) has shown that you can obtain higher speeds with them than you ever can with rollers. 1 High track stop wasn’t enough to stop the minecart from zooming to the edge of the map, going to see if I can get enough low track stops added to get some kind of measurement before the tantrum spiral drags me down.

On the amusing side of things, the dwarven caravan arrived, and the liaison wanted to make me a barony. I’ve had serious forts not get made baronies (probably because I got bored too soon), but the 11-dwarf science fort with an ongoing tantrum spiral, only 3 underground rooms (dorm, hospital, and burial area), no defences (only 2 military left alive), and a bunch of rotting corpses on the surface is deemed worthy. Sorry, 987-dwarf science fort, as of the time of the “has been made a barony” announcement. And then the baroness went stark raving mad. Finally, with 6 dwarves left alive (2 children and the mad baroness included), I had enough track stops: 1 high and 62 low (apparently 60 would have been just enough, with my track). The cart rolled 206 tiles including the roller, for a total of 454 Urists of friction + however much a high track stop gives.

Assuming the guesstimate of 1250 Urists for highest rollers, and subtracting 62*4+206 = 454, the highest track stop would have done 1250-454 = 796 Urists of work. That's not an exact value though. It has to be at least 800, to stop a cart from a high roller. Current guesstimate for high track stops' friction is 800, or maybe 850.

Finally, the epilogue:

Spoiler (click to show/hide)

Everything is taking ages to do, with all the wounded, dead, goblinite and corpses to dispose of, and less than a handful of dwarves to do it with. I'll be slowly wrapping up this round of testing, and preparing the fort for uploading of the save.

I tested this system for using a pressure plate under a cart to trigger some rollers earlier on the track. Said rollers then propelled another minecart into the initial one, sending it off. This was to create a system for more adjustable (now available in intervals of 50 weight-units!) send-off criteria than the 0/25/50/75/100% available via the hauling interface.

Also still did one test with a 1-bend track (this was already included in #5 earlier). Start tile (hauling stop with push) not counting, it went 42 tiles, SW turn on 42nd, then (12*4+97=) an equivalent distance of 145 tiles, for a total of 187, which would mean 14 tiles for the 1 turn.

Epilogue: The tantrum spiral seems to have stabilized with 5 dwarves left alive (2 kids). 5 migrants arrived in the spring, but another ambush just before the summer killed/wounded several dwarves. In the summer, another 13 migrants came. In the autumn, 12 more migrants arrive, and the place is mostly cleared up, including removing the track stops, rollers etc. components that you can’t see the strength of while they’re built. After the last of the wounded dying, there’s now 33 dwarves. I’ve uploaded the save to DFFD here, if you want to test some stuff with ready-made long and flat tracks. Be warned that a nasty ambush can wipe out the fort, and a siege would probably be game over.

That's that so far. I'm posting this now; be back in a bit to do some more editing and to reply to any posts others have made.

Added in a bit to the end of the #16 side track spoilerblock about a "best guess" for the friction of a high track stop.

[darkrider2]

Anyway I made a perfectly straight segment of track and measured how many frames the cart stayed on each tile, using . to advance the frames. Here are my results for the first 50 tiles. For some reason the first tile doesn't work like the rest of the tiles, I don't know why this is.

Spoiler: I now hate tables (click to show/hide)

tile	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	39	40	41	42	43	44	45	46	47	48	49	50
frames	2	5	5	5	5	5	5	5	5	6	5	5	5	5	5	6	5	5	5	6	5	5	5	6	5	5	6	5	6	5	5	6	5	6	5	6	5	6	5	6	6	5	6	5	6	6	5	6	6	6

It does slow down but I can't tell by how much each tile. The first 50 tiles seems to have an average of ~5.2 frames per tile. The tiles that need six frames get closer together and the ones that need five start getting further apart near the end.

[Trickman]

First time doing SCIENCE and you do a friggin thesis

Well done, mate. I'll follow this thread for more findings.

[Snaake]

One thing I discovered in my research, is that the truncation of continuous units speed and positions onto discrete units of tile location and time has a huge effect.   For example, a trackstop placed at tile "15" could have much different slowdown distance than a trackstop placed at tile "16" because the linger time is 3 ticks versus 2 ticks.

So your thinking is that the friction experienced is also dependent upon the time spent on the tile? Possible, I suppose, just makes our job of reverse-engineering the equations a bit harder. I admit I still prefer the hypothesis that the effect of a medium or stronger track stop, and probably turns, are somehow %-based off of speed, or more probably energy. One thing that complicates matters slightly is the question of which order are things calculated in: for example, is the slowdown of a turn calculated before or after the friction from just being on a track is applied?

While you're here, what's your comment on the 0.5 tiles initial push impulse by the dwarf (whereas I assumed 1 tile of guiding)? To be more specific, why/how did you decide on 0.5 tiles of push impulse, or was it just the first thing that came to mind for you? I'd also be interested in how you tested for the values you stated previously for medium track stops, floors, and turns (converting to my Urists, 50, 20, and 17.7 Urists, respectively).

Won't comment on the python program; while I can understand some python, I've never really learnt that language, and not much of a coder anyhow.

Trif: Nice looking results! Shows the parabolic path (=constant downwards acceleration) really well. It does look an awful lot as though the ramp doesn't add any significant upward velocity though, instead just slowing down the horizontal velocity of the cart before it launches off. Will have to have a look at those again once the slowdown from going up a ramp is figured out. More upward ramps might have enough of an effect to launch it upwards a bit, too. The setup I would use (knowing that there's probably a max speed you can achieve with rollers) would be more like a straight ramp down 10 z-levels, then a straight ramp up 3 z-levels.

Anyway I made a perfectly straight segment of track and measured how many frames the cart stayed on each tile, using . to advance the frames. Here are my results for the first 50 tiles. For some reason the first tile doesn't work like the rest of the tiles, I don't know why this is.

Spoiler: I now hate tables (click to show/hide)

tile	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	39	40	41	42	43	44	45	46	47	48	49	50
frames	2	5	5	5	5	5	5	5	5	6	5	5	5	5	5	6	5	5	5	6	5	5	5	6	5	5	6	5	6	5	5	6	5	6	5	6	5	6	5	6	6	5	6	5	6	6	5	6	6	6

It does slow down but I can't tell by how much each tile. The first 50 tiles seems to have an average of ~5.2 frames per tile. The tiles that need six frames get closer together and the ones that need five start getting further apart near the end.

Yeesh, yea that table looks like a pain to write, and I'm just quoting it. Lessee... let's just ignore the first tile, since that clearly doesn't work with normal push logic (or if it does, it only counts as half a tile)... it takes 46 ticks for the first 6-tick delay to show up (counting said 6-tick delay), then 31 ticks, then 21, 21, 16, 11, 16, 11, 11, 11, 11, 11, 6, 11, 11, 6, 11, 6, 6. Nope, can't make sense of it either. These seem to be basically the same results as xmoffitt posted in The "How Does Minecart" Thread post #488, just measured in a different way? I was able to convert it so I had the location of the cart at each tick, and graph the location as a function of time; unfortunately the bending of the slope (the slowing down) is only very slightly visible. The slowing of the cart only becomes easily noticeable sometime after the first 50 tiles .   Always good to have people making their own, independent checks though, else we'd never catch mistakes.

[darkrider2]

Yeesh, yea that table looks like a pain to write, and I'm just quoting it. Lessee... let's just ignore the first tile, since that clearly doesn't work with normal push logic (or if it does, it only counts as half a tile)... it takes 46 ticks for the first 6-tick delay to show up (counting said 6-tick delay), then 31 ticks, then 21, 21, 16, 11, 16, 11, 11, 11, 11, 11, 6, 11, 11, 6, 11, 6, 6. Nope, can't make sense of it either. These seem to be basically the same results as xmoffitt posted in The "How Does Minecart" Thread post #488, just measured in a different way? I was able to convert it so I had the location of the cart at each tick, and graph the location as a function of time; unfortunately the bending of the slope (the slowing down) is only very slightly visible. The slowing of the cart only becomes easily noticeable sometime after the first 50 tiles .   Always good to have people making their own, independent checks though, else we'd never catch mistakes.

I measured speed as frames per tile. He measured as tiles per frame. 5 on my chart is 0.2 on his. Glad to see the results are somewhat consistent with other scientists. I'm thinking the game does minecart speed similarly to the way it treats creature speed. A speed of 400 means that the cart/creature must wait 4 frames before moving. While a speed of 450 means it has to wait 4 frames, move, then wait five frames to move again for a total of nine frames in wait. (450+450=900)

Unfortunately since minecarts are constantly decelerating it's a bit difficult to determine speed when the system waits till the speed ticker remainders add up to an even 100 or so before adding an extra frame to the wait counter.

[lcy03406]

Very glad to see the science!
Would you do some experiments on ramps or water/magma?

[Snaake]

I'm thinking the game does minecart speed similarly to the way it treats creature speed. A speed of 400 means that the cart/creature must wait 4 frames before moving. While a speed of 450 means it has to wait 4 frames, move, then wait five frames to move again for a total of nine frames in wait. (450+450=900)

Thank you for that info. I was assuming that friction etc. is calculated once per tile, and the above provides explanation of how that would work (do friction, speed adjustments etc., figure out appropriate delay before moving to next tile, wait, move, repeat).

Very glad to see the science!
Would you do some experiments on ramps or water/magma?

Like I said, I will. #9-11 are about ramps, #18-21 about liquids. I'll try and get these done first, before getting bogged down in the problem areas (medium+ track stops, turns) again. Probably not this weekend, though.

On a side note, now that low track stops have been confirmed (?) as reliably giving 4 extra friction/multiplying the track's friction by 5, you don't need a 5x5 embark to be able to test stuff (especially thinking about turns here) and be able to compare to a straight track. You only need about a 50x50 tile area at a minimum, if you use low track stops smartly. A straight track of 40 tiles with low track stops would just stop a 200-Urist cart, but you should rather use 39 tiles of low track stops and about 10 tiles of regular track, for accuracy.

[lcy03406]

On a side note, now that low track stops have been confirmed (?) as reliably giving 4 extra friction/multiplying the track's friction by 5, you don't need a 5x5 embark to be able to test stuff

I suggest not to use any stops but embark to 1x10 or 2x10 area.

[Snaake]

On a side note, now that low track stops have been confirmed (?) as reliably giving 4 extra friction/multiplying the track's friction by 5, you don't need a 5x5 embark to be able to test stuff

I suggest not to use any stops but embark to 1x10 or 2x10 area.

Well, that can work too, but then you can't test single turns. Hm, I was going to play my main fort for a bit now, but a thin rectangular embark would actually make for an easy test for high/highest power rollers. (duh!) Be right back.

edit: well, set up a fort in a 2x16 serene woods embark, but haven't dug out the full length of the track yet. So, you'll have to wait for next week anyway, for any results. Edit2: derp! Only just realised that even 2x16 will only be about 700 tiles of straight track. I think I'll still use this fort, because it's a lot safer than the old one (being brand new, and iirc on an island with only elves). The extra length will come in handy with downward ramp testing, which was next on the list.

[xmoffitt]

So your thinking is that the friction experienced is also dependent upon the time spent on the tile? Possible, I suppose, just makes our job of reverse-engineering the equations a bit harder. I admit I still prefer the hypothesis that the effect of a medium or stronger track stop, and probably turns, are somehow %-based off of speed, or more probably energy. One thing that complicates matters slightly is the question of which order are things calculated in: for example, is the slowdown of a turn calculated before or after the friction from just being on a track is applied?

This is correct.  Your conclusions about order are also valid.  For example, do you take the friction value from the tile you started in or finished in?  Do you decrease speed from friction before or after you move?  I believe I have all those things done correctly in the python program, as it exactly matches my experimental observations.   I do have a spreadsheet of raw results if you want to PM me your email address.

While you're here, what's your comment on the 0.5 tiles initial push impulse by the dwarf (whereas I assumed 1 tile of guiding)? To be more specific, why/how did you decide on 0.5 tiles of push impulse, or was it just the first thing that came to mind for you? I'd also be interested in how you tested for the values you stated previously for medium track stops, floors, and turns (converting to my Urists, 50, 20, and 17.7 Urists, respectively).

My experimental setup was a long straight track greater than 200 tiles long.  One time, I did measure the ticks the cart lingered on each tile for the entire trip (just like darkrider2).  Obviously, that was a tedious measurement.   For all subsequent observations, I just measured where the cart stopped with various obstacles along the way.  By slightly changing the number and location of the obstacles, I was able to get very accurate measurements for their friction values.

As far as the initial push, I used the per-tile delay data on the straight track to solve for the unknowns: starting position, starting velocity, and per-tick friction.  I had to try a few different assumptions about order of effects, but eventually it matched exactly.  So the reason for 0.5 is because the numbers fit and it made sense.   (Speculating about DF's internal implementation, it seems positions are tracked as floating point numbers but tiles are defined at integers, so whenever something gets built or placed it probably gets put at an exact spot "in the middle" of the tile )