Bay 12 Games Forum

Dwarf Fortress => DF Dwarf Mode Discussion => Topic started by: Snaake on July 06, 2012, 02:19:58 pm

Title: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 06, 2012, 02:19:58 pm

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 (http://www.bay12forums.com/smf/index.php?topic=112831.msg3508793#msg3508793) and expwnent's (http://www.bay12forums.com/smf/index.php?topic=112831.msg3536975#msg3536975) 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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3290448#msg3290448) and #230 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3292304#msg3292304), and xmoffitt's, in posts #441 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3328930#msg3328930) and #488 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3362517#msg3362517). 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 (http://www.bay12forums.com/smf/index.php?topic=109460.0), 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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3328930#msg3328930) (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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3297711#msg3297711), 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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3430054#msg3430054)
- 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 (http://dffd.wimbli.com/file.php?id=6626) 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 (http://www.bay12forums.com/smf/index.php?topic=112831.msg3440875#msg3440875). 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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: darkrider2 on July 06, 2012, 02:41:43 pm

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

Title: Re: SCIENCE: Quantifying minecart physics
Post by: xmoffitt on July 06, 2012, 03:53:05 pm

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 )


Title: Re: SCIENCE: Quantifying minecart physics
Post by: Trif on July 06, 2012, 04:05:30 pm

I did some research on parabolic paths (#10) in Kelnimar. (here (http://www.bay12forums.com/smf/index.php?topic=106649.165) and here (http://))

Quote from: Trif on June 27, 2012, 10:46:42 am

Spoiler: Setup (click to show/hide)

(http://i.imgur.com/otk4V.png)z20
(http://i.imgur.com/3WVBw.png)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.
(http://i.imgur.com/prY01.png)

Spoiler: Results (click to show/hide)

trajectory of a minecart after acceleration by 10 rollers
(http://i.imgur.com/rX11W.png)

trajectory of a minecart after acceleration by 10 rollers, launched using a track ramp
(http://i.imgur.com/kwkjp.png)
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
(http://i.imgur.com/ZRfB7.png)

You can download the fortress and check my results (or use the setup for further falling ‼Science‼) over here (http://dffd.wimbli.com/file.php?id=6601).

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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: goladith on July 06, 2012, 04:13:14 pm

I blame the Higgs-Boson.

Title: Experiments & Results Part 1
Post by: Snaake on July 06, 2012, 04:26:24 pm

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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3430054#msg3430054) 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 (http://), 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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: darkrider2 on July 06, 2012, 04:45:45 pm

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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Trickman on July 06, 2012, 04:49:26 pm

First time doing SCIENCE and you do a friggin thesis :o

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

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 06, 2012, 06:05:23 pm

Quote from: xmoffitt on July 06, 2012, 03:53:05 pm

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. :P 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. :P

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.

Quote from: darkrider2 on July 06, 2012, 04:45:45 pm

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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3362517#msg3362517), 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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: darkrider2 on July 06, 2012, 08:05:15 pm

Quote from: Snaake on July 06, 2012, 06:05:23 pm

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 (http://www.bay12forums.com/smf/index.php?topic=109460.msg3362517#msg3362517), 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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: lcy03406 on July 07, 2012, 02:10:19 am

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

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 07, 2012, 05:19:38 am

Quote from: darkrider2 on July 06, 2012, 08:05:15 pm

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

Quote from: lcy03406 on July 07, 2012, 02:10:19 am

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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: lcy03406 on July 07, 2012, 05:46:05 am

Quote from: Snaake on July 07, 2012, 05:19:38 am

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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 07, 2012, 08:08:52 am

Quote from: lcy03406 on July 07, 2012, 05:46:05 am

Quote from: Snaake on July 07, 2012, 05:19:38 am

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.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: xmoffitt on July 07, 2012, 10:55:24 am

Quote from: Snaake on July 06, 2012, 06:05:23 pm

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. :P 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.

Quote from: Snaake on July 06, 2012, 06:05:23 pm

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 )

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Friendstrange on July 07, 2012, 11:09:30 am

Dont we have a "How does Minecart" thread?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on July 07, 2012, 11:48:26 am

Posting to watch.

Quote from: Friendstrange on July 07, 2012, 11:09:30 am

Dont we have a "How does Minecart" thread?

This looks like it'll be MUCH more detailed and quantitative.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: darkrider2 on July 07, 2012, 02:09:02 pm

Quote from: expwnent on July 07, 2012, 11:48:26 am

Quote from: Friendstrange on July 07, 2012, 11:09:30 am

Dont we have a "How does Minecart" thread?

This looks like it'll be MUCH more detailed and quantitative.

I think that thread went off the rails at some point.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Ivir_Baggins on July 07, 2012, 02:11:46 pm

Quote from: darkrider2 on July 07, 2012, 02:09:02 pm

Quote from: expwnent on July 07, 2012, 11:48:26 am

Quote from: Friendstrange on July 07, 2012, 11:09:30 am

Dont we have a "How does Minecart" thread?

This looks like it'll be MUCH more detailed and quantitative.

I think that thread went off the rails at some point.

Ba-dum TISH

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 07, 2012, 05:01:56 pm

Quote from: Friendstrange on July 07, 2012, 11:09:30 am

Dont we have a "How does Minecart" thread?

I'm fairly certain I mentioned this at some point:   my experiments posted here are inspired by (a few posts in) that thread, but the focus is pretty different.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: krenshala on July 07, 2012, 05:21:42 pm

For those wanting to do tables of aligned data, use the {tt} tag (I'm using braces here instead of brackets due to BB code). Its the typewriter looking icon next to subscript in the button selection above the text box for post submission.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 10, 2012, 07:01:58 pm

Quote from: xmoffitt on July 07, 2012, 10:55:24 am

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

I'll send you a pm with my email address, but would you mind explaining the basics about the python program (seeing as you already posted the code anyway), or rather, describe the calculation steps (done per tick?), and their order, so others could understand it better too?


So yup, 2nd minecart science fort: 2x16 embark, forested island, right next to some elves, hopefully no goblins (didn’t remember to check, but most of the island was inhabited by the elven civ). 2x16 means the embark is a bit under 100 tiles wide, but I now have a N/S tunnel 766 tiles long.

Testing #9-10 (down ramps, ramp friction):

Spoiler (click to show/hide)

First off, gonna test 1 ramp down. Drop a feather wood minecart (weighs only 4Γ; nothing but bruises from the 3 first collisions, and quicker to carry) onto lowest rollers, 50 tiles of track, then on the last tile it moves to, a ramp down. Cart moved a further 474 tiles (tested a couple times). A larch minecart (weight 23Γ) went the exact same distance. That’s a net energy gain of 473 Urists, assuming the down ramp still has friction. So let’s have a look at #10.

Deconstructed the ramp, minecart moved 1 tile after falling through the hole on the 51st tile. This was somewhat expected, since it wouldn’t experience friction during the parabolic-path fall. I then replaced one of the 51 NS tracks with a NS track ramp, which functioned exactly like a NS track, as expected (since there was nothing upstairs for it to ramp to, and actually no walls adjacent, so the ramp was unusable). That’s about all I can think of for #10 at the moment: ramp tracks do have the usual 1 friction in addition to their ramp effects, and falling down is well, a parabolic path (no horizontal speed gained or lost, probably – although to be exact, that should be verified with higher speeds and a much longer fall).

Moving back to verifying the 1-ramp-down results, deconstructed a track and built a ramp down right in front of the lowest roller mentioned before. First test killed(!) a cat (due to striking it in the head, bruising the muscle, jamming the skull through the brain and tearing apart the brain). Second test had the cart go 594 tiles after the ramp. That would be a net gain of 543 Urists (removed 50 for the energy gained from the roller and 1 for the ramp friction). Another cat impact (this time with seriousfatal injuries)! And then a dwarf, too (broke his arm)! Finally did manage to repeat and confirm an exact 543 Urist net energy gain. Next up, low rollers (was going to push, but this way I don’t have to fiddle with hauling settings, just switch out the rollers) and ramped it down adjacent to the rollers: the cart traveled 783 tiles, for a net energy gain of of 583 Urists (note that I did have to resort to placing 10 low track stops to stop the cart before the end of the tunnel; the extra friction from those is included in the distance above). Next, continued testing with the low roller, but moving the ramp down further away in increments: 50 tiles (and thus a remaining energy of 150 Urists) gave a net gain of 532 Urists; 100 tiles, 470 Urists; 150 tiles, 545 Urists; 200 tiles (ramp down on last tile cart would move to on flat track), 469 Urists. The last two were expected to be the same as with the lowest-roller tests. Clearly there is at least some sort of rounding issue at play here, but it seems to be that: a) with energies of 50-200 Urists, the cart gains about 560 Urists of energy (ranging from 540ish to 580ish); b) if the cart has almost stopped before ramping down, the kinetic energy gained will be slightly less, about 470 Urists. More testing could be carried out, especially in the 0-50 Urists remaining range. I was expecting some variability, having read reports that it was sometimes* possible to generate speed just be having a cart ramp down and immediately back up again (*depending on where the aforementioned feature was located on the track). But this is just… well, I hesitate to use the word, but ugly :/

Testing #10 (up ramps):

Spoiler (click to show/hide)

Ramping up 1 z-level. I’ll be continuing with low rollers, with a ramp down right after (so kinetic energy of 783 Urists as above, not yet counting the friction from the ramp). Ramp up immediately after ramping down had the cart travel over 250 tiles after ramping back up. Going to save myself the pain of building a hundred or so tiles of tracks on the level above (yes, building, since it’s a soil layer), and just channel out a hole for the cart to drop back down onto the tracks below. Said hole will be on the 250th tile after the roller. By measuring with 1-step, my guess for the horizontal flight time is 3 tiles (±1 tile). With this setup, the cart went all the way up to my u-bend, so over 550 Urists of net gain from the 2-tile channel. To avoid boring people with a list of the further tests in text form, here's a table. The first case (up ramp 1 tile away from down ramp) is the one explained above. ~ and a number means that the tiles traveled has been estimated (i.e. there was some hang time, as above, which has been estimated; the errors possible here are +-1 tile). The N/A for the last two mean that the cart didn't ramp up the tile at all, and thus I don't have any measurements.

distance from down to up ramp:  1     2    3    4    5    6    7    8    9    10   11   50   100   150   200
total tiles traveled:          750+ ~313  203 ~312  118 ~312  120  205  121  206   62  226  ~252   N/A   N/A
net gain/loss of energy:       550+  113   3   112  -82  112  -80   3   -79   6   138   26    52   N/A   N/A

So it seems pretty obvious there's some integer rounding going on, as with the small-interval measurements there are 3 clear possible outcomes: a net gain of about 110 Urists, a net loss of about 80 Urists, and breaking almost even (a few Urists worth of net gain). Further away it gets less clear, but in general ramping down, and up again later, will actually give the cart some speed.

I also think it’s noteworthy that due to my impatience and lazyness (to disable the push command for the short while dwarves were doing modifications), at least 4 dwarves have received various fractures and at least as many others some bruises (one got hit 3 times because he took so long to carve tracks). One was unlucky enough to get a piece of skull jammed through his brain, and died. So… feather wood minecarts: maybe safer than iron ones, but don’t bet on it?

For the next update, I think I'll test how much energy highest rollers give (finishing up #13), then maybe continue with the rest of the roller questions. I think I'll try and split up the SCIENCE into smaller chunks from now on (well, this post is already implementing that idea, but the reasoning for the earlier megaposts is I didn't want to just make a post with all the research questions, then have people wait several days before giving any results).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: DrKillPatient on July 10, 2012, 09:11:27 pm

Here's something perhaps worth investigating, if at some point the tests branch off into physics of creatures in minecarts: if a dwarf swings his melee weapon at an enemy while riding past it in a minecart, will the momentum of the minecart add to the force of the swing? I'd guess that the best way to test this would be with hammers hitting low-weight creatures. If the force of the swing is at all affected, it will likely cause the creature to fly farther. This probably cannot be quantified by injuries to the enemy unless the effect is so extreme as to yield radically different types of wounds.

EDIT: Two more points of interest:
- Can enemies strike at a dwarf in a minecart, and if so, do they suffer any penalty for doing so?
- If a weapon is embedded in a minecart-riding dwarf, will it be yanked out of the wielder's hands and carried along? If not, will it be pulled out of the dwarf by the advance of the minecart?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 11, 2012, 05:36:45 am

Quote from: DrKillPatient on July 10, 2012, 09:11:27 pm

Here's something perhaps worth investigating, if at some point the tests branch off into physics of creatures in minecarts: if a dwarf swings his melee weapon at an enemy while riding past it in a minecart, will the momentum of the minecart add to the force of the swing? I'd guess that the best way to test this would be with hammers hitting low-weight creatures. If the force of the swing is at all affected, it will likely cause the creature to fly farther. This probably cannot be quantified by injuries to the enemy unless the effect is so extreme as to yield radically different types of wounds.

EDIT: Two more points of interest:
- Can enemies strike at a dwarf in a minecart, and if so, do they suffer any penalty for doing so?
- If a weapon is embedded in a minecart-riding dwarf, will it be yanked out of the wielder's hands and carried along? If not, will it be pulled out of the dwarf by the advance of the minecart?

I think it would be difficult to test even with the knockback, since that can be quite random too. I've had cats fly a few tiles, or not fly at all, when getting hit by a cart (of approximately the same speed). That said, cavies/bunnies.would be pretty ideal test subjects I think. And I think we know so little of the exact statistics of combat mechanics and skills (cprrect me if I'm wrong) that figuring out any sort of penalty that might result from the speed would be nigh impossible.

Regarding the other two points, there was an example in the dev logs where a dwarf was riding a cart that was launched through the air and it's flight path passed near a goblin on the ledge. The goblin swung at the dwarf as he passed by, and the dwarf dodged out of the cart and onto the ledge.

Not going to do it any time soon (since I still have several of my original points untested), but I'd probably test this by pitting some the target(s) in a something*3 area, and engineering a cart to pass through the middle (preventing gobbos from getting out somehow - probably easiest just with gaps in the floor).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: WanderingKid on July 11, 2012, 02:58:53 pm

Just to add in a little extra data, I believe you're correct that 'highest friction' is roughly infinite.  I currently have a minecart build that gets guided up about 30 z levels and gets pushed back for marble rock movement up to the main smelting area (I've got a ton of coal in this fort).

That cart's return path is simply a series of slopes back down to the pickup zone.  If it's picking up 500 Urists (roughly) per level, it's at (at least) 15,000 Urists when it hits the turn near the bottom (walled for guidance) and then the friction stop.

A way to test this might be to use simple floor friction.  Don't use the track after a certain point and see how far it goes on the floor.  Hm.  My current embark isn't wide enough to try that.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 11, 2012, 03:14:24 pm

Quote from: WanderingKid on July 11, 2012, 02:58:53 pm

A way to test this might be to use simple floor friction.  Don't use the track after a certain point and see how far it goes on the floor.  Hm.  My current embark isn't wide enough to try that.

Definitely a good way to test it, once floor friction is known :P. You mentioned that the track stop is after a turn, what about if you move it to right at the bottom of the 30z ramp? Of course, I think we can only call it "effectively infinite" if it's tested on something like a straight set of ramps down a mountain slope and underground all the way to SMR, and a highest track stop there, immediately. That could net something like 300z at least, for about 150 000 Urists. Effectively infinite, since that's the highest-energy setup I can think of that's achievable with regular worldgen (oh, you can add a set of highest rollers at the top I guess, but that's only a couple of thousand Urists more, probably).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Reese on July 11, 2012, 03:57:02 pm

I am so glad people are quantifying these things, I have been having so much trouble figuring this stuff out on my own.

The how does minecart thread was so disappointing and lacking in !!science!!, and the wiki doesn't have much info yet either.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: WanderingKid on July 11, 2012, 04:02:35 pm

Quote from: Snaake on July 11, 2012, 03:14:24 pm

Definitely a good way to test it, once floor friction is known :P.

I thought earlier in the thread it was tested out at 16 Urists?

Quote

You mentioned that the track stop is after a turn, what about if you move it to right at the bottom of the 30z ramp?

Not in that particular setup, I can't.  I'm relatively sure I'll be making another 'long hauler' cart shaft down to the caverns eventually to bring up random goods, I'll try it then.

Quote

Of course, I think we can only call it "effectively infinite" if it's tested on something like a straight set of ramps down a mountain slope and underground all the way to SMR, and a highest track stop there, immediately. That could net something like 300z at least, for about 150 000 Urists. Effectively infinite, since that's the highest-energy setup I can think of that's achievable with regular worldgen (oh, you can add a set of highest rollers at the top I guess, but that's only a couple of thousand Urists more, probably).

I'm expecting there's a max-Urist speed for minecarts, otherwise they'd eventually catch on fire from air friction.  Though, I have to admit, using that as a weapon into your HFS entry could be hysterical, if you can control it to be a single path outwards.  Clown Smear by Cart.  Joy.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 11, 2012, 04:54:35 pm

Quote from: WanderingKid on July 11, 2012, 04:02:35 pm

Quote from: Snaake on July 11, 2012, 03:14:24 pm

Definitely a good way to test it, once floor friction is known :P.

I thought earlier in the thread it was tested out at 16 Urists?

That's what I got from one non-repeated test (since it was actually an accident). xmoffit quoted a figure of 20 Urists in the other thread, though, iirc. Something in that range, probably, but the exact mechanics are still less certain.

Quote

I'm expecting there's a max-Urist speed for minecarts, otherwise they'd eventually catch on fire from air friction.  Though, I have to admit, using that as a weapon into your HFS entry could be hysterical, if you can control it to be a single path outwards.  Clown Smear by Cart.  Joy.

I also think it's possible there's a general max speed, hence it's inclusion in "later research."

Title: #13-14, plus bonus question
Post by: Snaake on July 12, 2012, 04:52:22 pm

#13-14:[/u]

Spoiler (click to show/hide)

Ok, so next order of business is to find out how much 1 tile of highest rollers pushes a cart. Started building 250 low track stops; I left 1 tile between roller and 1st track stop, so it’s a total of 10001251 Urists of friction. From measuring with one-step, a highest roller gives a speed of about 0,5 tiles/tick initially. To my surprise, the cart stopped on exactly the last track stop. Well, now in retrospect, that was actually what I’d guessed earlier, I’d just made a brainfart when calculating, and thought 250 stops would be a total of 1000 Urists of friction. It is, but then there’s another 250 from the tracks underneath the stops, for a total of 1250 (hence the strikethrough above). I removed one stop from the start (because the start was a lot closer to my meeting hall than the 250th stop), and the cart traveled 255 tiles, including 249 lowest track stops, giving an energy of 1251 (or 1252 if I include friction from the roller tile), strangely enough. I think I’ll still stick with 1250 for highest rollers, nice and even. That's #13 finished up.

#14: While I was building all those track stops, I started with testing multiple lowest rollers (also vs. 1 longer roller of equal tile count). So, a lowest roller was built at the end of my 2nd long track (did I mention there’s two of them running in parallel on the bottom level?). Then another, then another, etc. With 1 lowest roller, the cart went the familiar 50 tiles, with 2, it went 50 after the 2nd, with 3, 50 after the 2nd, and so forth, tested to 5 one-tile rollers. Also tested with 1-3 one-tile rollers of low, medium, and highest (since I had a track prepped for highest rollers handy) strength, with identical results: the minecart doesn’t gain any additional energy from subsequent rollers, they just reset the minecart to the full energy of that roller again. Still need to test how this compares to building 1 longer roller.

Adding new question: how much energy/speed is required for the cart to skip over a 1-tile gap (open space) on an otherwise flat track? This is quite useful/necessary to know, if you want to have track setups where your dwarves are not allowed on the tracks, to avoid collisions. You might want to have 1 escape route from the track area though, in case someone gets lost there by dodging onto the tracks (for example), lest they die of thirst; just don’t have the tracks open at both ends. Used my constructed tracks, but removed tracks and channeled out the floor from the first 75 tiles or so, and built retracting bridges, for faster reconfiguration (1-wide retracting bridges are faster to take apart than even 1 constructed track). If the gap was right next to the start, and a dwarf pushed, the cart fell in the gap with no horizontal velocity. If a roller does the pushing, the cart jumps over the adjacent gap and traveled the expected 202 tiles (201, +1 for no friction on the gap). With the gap on the 2nd tile, both dwarf push and rollers made the cart clear the gap. All tests so far had the cart travel the same 202 tiles. Still need to test for the minimum energy needed. Already tested that having the gap on the 3rd tile out is fine, next going to check on the 10th, 20th etc., then try and narrow it down to an exact energy. Only going to be using the rollers for this from now, since they're identical to the push after the first tile.

tl;dr version: Posting some results now: Highest rollers are 1250 Urists (I think; see the full text), as per my previous guess. Having several 1-tile rollers just gives the same speed as with only one 1-tile roller. Longer rollers not yet tested.

Started testing a new question: how much energy does a minecart need to skip over a 1-tile "open space" channel? Answers so far:
p=.== or R.== both work, that is to say, if a dwarf pushes (the p) a cart, it needs to have 1 tile between the channel and the hauling stop with the push, but if rollers are used, the gap can be adjacent. Testing for energy required is ongoing (didn't have time to play today, just writing up what results I got yesterday evening).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Urist Da Vinci on July 12, 2012, 08:30:27 pm

Quote from: DrKillPatient on July 10, 2012, 09:11:27 pm

... if a dwarf swings his melee weapon at an enemy while riding past it in a minecart, will the momentum of the minecart add to the force of the swing? ...

Nope, it doesn't. We'll have to wait for Toady to add mounted combat before that'll work.

Other interesting points: a dwarf who jumps out of a moving minecart will keep moving in the direction of travel, but if he then drops an item from his inventory, it falls straight down. Shooting a crossbow from a moving minecart likewise assumes a stationary launching position.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: lcy03406 on July 12, 2012, 11:29:48 pm

Quote from: Urist Da Vinci on July 12, 2012, 08:30:27 pm

Quote from: DrKillPatient on July 10, 2012, 09:11:27 pm

... if a dwarf swings his melee weapon at an enemy while riding past it in a minecart, will the momentum of the minecart add to the force of the swing? ...

Nope, it doesn't. We'll have to wait for Toady to add mounted combat before that'll work.

Other interesting points: a dwarf who jumps out of a moving minecart will keep moving in the direction of travel, but if he then drops an item from his inventory, it falls straight down. Shooting a crossbow from a moving minecart likewise assumes a stationary launching position.

But HOW to give the mount and shoot order？

Title: Re: SCIENCE: Quantifying minecart physics
Post by: xmoffitt on July 15, 2012, 09:35:15 pm

Quote from: Snaake on July 10, 2012, 07:01:58 pm

I'll send you a pm with my email address, but would you mind explaining the basics about the python program (seeing as you already posted the code anyway), or rather, describe the calculation steps (done per tick?), and their order, so others could understand it better too?

Sure, here is the simple overview.

• First, you create a Course, which is just a list tiles in a line with various attributes.  For example, course = [track.T] * 500 is just a long track with regular tiles.
• Usually, you will add one or more unknown elements that you are trying to derive values.  For example, course[10] = track.SM is a Trackstop-Medium
• Next, you create a Race object and call run() to start the simulation.
• The impulse is applied which gives the cart position 1.5 and speed 200.
• Then, each tick
• Looks up the tile type and stats from the current location[/i]
• Adds speed from rollers, up to a max speed (this might not be right)
• Decreases speed based on friction
• Updates position based on speed.
• Changes direction of the cart if entering/exiting a ramp. (this might not be right)

Everything is is just fancy stuff to look for different values that "fit" the observation.   I used it to get the friction values for Lowest, Low, and Medium track stops.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on July 25, 2012, 08:47:45 am

Hey, just though I'd pop in to explain why I haven't been posting, and do a little "what now?" post in general.

So, I sort of drifted away from DF. The blame is largely on Steam summer sales; I've been playing Terraria (inspired by minecraft, which was inspired by DF), especially the multiplayer with my girlfriend. Also gotten into the Day Z mod in the past couple of days. At the moment, I don't think I'll be playing DF very actively for a few weeks at least, but might be longer than that, to be honest (months, a year...). DF is one of those games I drift in and out of.

I will try and push myself to finish testing #14-15, since I've done part of that already; no promises though. The same applies to editing some of this info to the wiki (I did write a mention of the thread on the discussion page for the minecart article, requesting a rewrite of the physics section, citing at least this thread, can't remember if I cited others too). Other than that, feel free to finish testing this stuff, using either this thread or some other, more active one, to post the results in.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: eRaz0r on August 01, 2012, 03:20:15 am

While my "experiments" are not to the rigorous level of scientific inquiry as my predecessors here, I'd like to add some minor observations of my own.

1. Rollers built on an upward track (track and roller a single tiles length) can and will launch a cart off the rails on the level above.
2. Carts do have some kind of angular momentum.  A descending ramp track with a turn in it (.e.g a corner ramp) can derail a minecart if there are no walls. The derailment is at an angle less than the 90 degree angle that the ramp should have imparted.
3. Track Stops set to "dump"  will not dump riding dwarves.
4. When using a T-junction with rollers (as presented in the wiki) to control automated movement, riding dwarves are forcibly dismounted at the T, when the cart continues in the direction of the roller. I have not finished testing this last one.  I want to see if I can slow the cart down enough that the direction change is gentle enough that the dwarf remains in the cart.


My fort has a large "roller coaster" that I intended to use to put my marksdwarves on - to ride around the map shooting at whatever they see. The coaster works reasonably well - I have a mount point on top of an archer tower in the west above the "yard" (my old fort entrance). The track ramps down a few Z's as it progresses east over the yard, and turns south until it hits the top of another tower where it joins the "gatehouse" track that zooms in front of the gate (2 z's above the entrance)  and eventually enters the northernmost archer tower where it spirals down into the earth. At bottom the track heads due south.  About the middle of the map there's a T junction. If the rollers are off, the hapless marksdwarf will continue back to the southern archer tower and spiral up the ramps automatically (thanks to the windmill farm on the tower top) where he continues to zip in front of the gatehouse. That's entirely automated.  If the rollers are on, he was supposed to go back to the base of his original archer tower, where he'd have to climb the stairs to top.

So far, the problems are
a) dismounting on the rollers
b) can't get the marksdwarves to ride the thing properly.  Even locking doors and hatches and things, and they still just stand there.  I may have to experiment with burrows next.

Well, that's my contribution (such as it is) to the science of minecarts

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Gerottomo on August 01, 2012, 09:05:53 am

One thing to test would be if a minecart with a large weight in it will derail easier than one without as it would in actuality due to inertia and center of gravity.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Sutremaine on August 01, 2012, 11:01:09 am

Quote from: eRaz0r on August 01, 2012, 03:20:15 am

My fort has a large "roller coaster" that I intended to use to put my marksdwarves on - to ride around the map shooting at whatever they see.

I think this would work as a track switcher, but I haven't done anything with bridges yet:

Code: [Select]

.1....
.1....
.11111
......
.22222
.2....
.2....
Track 1 is, at least at that corner, slow enough to not derail the track as it turns the unwalled corner. To make the switch to Track 2, you unretract the three-tile bridge that covers the gap plus the two corner track tiles, and have the cart come from the north.

Code: [Select]

.1....
.1....
.|1111
.|....
.|2222
.2....
.2....


Title: Re: SCIENCE: Quantifying minecart physics
Post by: eRaz0r on August 01, 2012, 01:16:04 pm

Quote from: Sutremaine on August 01, 2012, 11:01:09 am

Quote from: eRaz0r on August 01, 2012, 03:20:15 am

My fort has a large "roller coaster" that I intended to use to put my marksdwarves on - to ride around the map shooting at whatever they see.

I think this would work as a track switcher, but I haven't done anything with bridges yet:

That looks workable. 
My current set up is more like this :

Code: [Select]

1 . . .
1 . . .
1 . . .
2 2 2 2
1 O O O
1 O . .
1 O . .
Where track 2 has a roller on it to pull the cart on to it.   Your idea sounds better. I've had a lot of luck with controlled derailment feeding from one track to another. 
(I have a double-helix spiral that goes down many z's to various levels - marble mine, spider silk farms, gold mine.  At each major level, using doors and derailment instead of T junction tracks, I can control whether the cart stops there and short-circuits the rest of the descent depending on what my dwarves need..

Title: Re: SCIENCE: Quantifying minecart physics
Post by: eRaz0r on August 01, 2012, 05:00:39 pm

I've gotten the T junction working perfectly as you described. This is much more elegant than the Rollers, and the riders stay in the cart.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Sutremaine on August 01, 2012, 05:17:27 pm

Much easier to power as well, on account of not needing any power.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: eRaz0r on August 02, 2012, 01:19:45 am

Quote from: Sutremaine on August 01, 2012, 05:17:27 pm

Much easier to power as well, on account of not needing any power.

Indeed - one problem though - it's too vulnerable to changes in cart speed. With the bridge retracted, the cart may or may not derail depending on the speed it's gotten at that point.

I went with a different option - a door instead.  The door acts as a wall to "encourage" the cart to stay on the corner, and when closed, the carts jump the corner on to the continuing track.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Tryble on August 05, 2012, 02:58:28 pm

So, if I'm reading all of this right, a short list of facts we now know based on your testing:

One tile of distance traveled is labeled one Urist.

Propulsion:
Minecart travel distance is unaffected by weight or load.
Dwarves push at 200 Urists regardless of Strength, but ignore all or some of the friction of the initial tile some.
Roller speeds are measured at 51/201/451/801/1250, medium/high speeds being estimates.
Downward ramps grant an additional 470-560 Urists of movement.

Friction Costs:
Minecart tracks of any sort cost 1 Urist per tile.
Bridge tiles also cost 1 Urist.
Non-track floor costs 14 Urists.
Track stops add an additional 0/4/40-52/800-850/∞ friction to a tile, medium and higher being variable or estimated.
Turns on a track have an estimated friction cost of 9-14, variable for unknown reasons.

Other:
Bridge tiles operate identically to tracks except for pathing purposes when the cart is guided.
Upward ramps are wonky; they can decrease or increase the distance traveled by a cart.
A 200 Urist push is enough to cause a cart to jump over a 1 tile gap, as long as the gap is not adjacent to the dwarf push (pushd by roller is fine).  The gap doesn't cause any loss in travel distance.


Is this right?  I may have misread or misinterpreted some things.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Sutremaine on August 05, 2012, 03:47:54 pm

Quote from: eRaz0r on August 02, 2012, 01:19:45 am

Indeed - one problem though - it's too vulnerable to changes in cart speed. With the bridge retracted, the cart may or may not derail depending on the speed it's gotten at that point.

You can use track stops to slow a cart down, and they can be made one-way if you use a pressure plate with the track stop.

Quote

I went with a different option - a door instead.  The door acts as a wall to "encourage" the cart to stay on the corner, and when closed, the carts jump the corner on to the continuing track.

Closed?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Urist Da Vinci on August 05, 2012, 03:59:47 pm

Quote from: Tryble on August 05, 2012, 02:58:28 pm

...
Dwarves push at 200 Urists regardless of Strength, but ignore all or some of the friction of the initial tile some.
Roller speeds are measured at 51/201/451/801/1250, medium/high speeds being estimates.
Downward ramps grant an additional 470-560 Urists of movement.
...

Another implication: we think rollers have a "do not exceed" speed, and rollers alone aren't sufficient to "shotgun" cart contents. We also know that 3 z-levels (perhaps plus a dwarf push) are required at minimum to "shotgun". This puts the shotgun requirement somewhere between 1250 - 1680. Careful use of track stops could make this number range smaller.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: zuglar on August 05, 2012, 04:50:19 pm

Quote from: lcy03406 on July 07, 2012, 02:10:19 am

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

I can throw in what I've observed building a magma dipper route:

The dip needs to be at least 2 tiles wide (cart skips over 1-tile holes, I've never tried 3). An iron minecart needs a 2z drop into still 7/7 magma to pick anything up and still escape. A 1z drop will leave it stuck (and Newton's cradle won't get it out). 6/7 magma won't give any to the cart (contrary to the wiki). Sending a cart in while a magma pump is active will get the cart stuck. I have no idea why the latter, unless 7/7 magma is too much friction for a full cart to escape.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: electrobadger on August 07, 2012, 06:23:56 pm

First time poster here. I was inspired by Snaake and xmoffitt's efforts to get to the bottom of quantifying the physics of minecarts.

With numbers, and hopefully in a less cryptic form than xmoffitt's Python code.

First off, Snaake's Urist units are not a linear measure of speed. A cart travelling twice as fast will have 4 times as many Urists by this measure. I have measured speed in tiles per step (i.e. the number of squares moved using the .:One-step control, abbreviated m/s for simplicity).

As an aside, I found that almost nothing depended on minecart weight. All of my experiments were checked with a willow cart (15 U) and a lead cart filled with pitchblende boulders (453U unladen, 4253U laden). The only exception is When Minecarts Collide. Everything else seemed the same for both carts. (If anyone has proof to the contrary, I will retest.)

All of this is was done on vanilla 34.11 + Phoebus tileset.

My findings, answering Snaake's original questions, are as follows:

• Aside from fluids, minecart physics is entirely deterministic, there is no randmness. And it bears some resemblance to real-world Newtonian physics.
• Every dwarf gives every minecart an initial velocity of 0.2 tiles per step.
• See above. Tested on straight and curved tracks. Also non-track, FWIW.
• Here is Snaake's mis-step. Straight track tiles remove a constant amount of velocity per time step, not per tile. The velocity of every cart on a straight track tile decreases by 0.0001 tiles per step per step. A pushed cart at 0.2 m/s takes 2000 s to stop, travelling 200 tiles.
• As best I can tell, curved track tiles apply the normal friction of 0.0001 m/s/s, but also subtract an additional 0.01 m/s when the cart exits the tile.
• Carved and constructed tracks...
• ...and bridges all have the same friction.
• Track stops also apply friction acceleration to minecarts. The values are:
  
  • Lowest 0.0001 m/s/s (same as normal track)
  • Low 0.0005 m/s/s
  • Medium 0.005 m/s/s
  • High 0.1 m/s/s
  • Highest 0.5 m/s/s
  I am not sure about the 'Highest' value, but it is not infinite. A cart launched from 20 ramps up will cross 1 Highest track stop (slowing considerably).
• Down ramps have an acceleration of 0.068 m/s/s. Since a fast moving cart will spend few ticks on the ramp, this means that it will accelerate less than a slow moving cart. As a point of reference, a cart started from rest on the 8th ramp up will reach the bottom travelling at 1.0 m/s, five time faster than a Dorven push.
• Comparing ramps and parabolic drops is difficult. However, a falling cart actually seems to gain less energy (1/2*v²) per z-level dropped than one rolling down a ramp.
• Up ramps have an acceleration of -0.074 m/s/s. This means that a cart can never go up as far as it dropped.
• Unpowered rollers act like the underlying track, they have no extra friction.
• 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
  This attests to the general uselessness of rollers. A cart goes faster after dropping down two ramps than after being launched by the Highest speed of roller.
• As far as I can tell, it does not matter if you have 5 rollers or just 1. As soon as the cart passes the roller, its speed is increased to the above value. This was true for both the willow and lead & pitchblende carts.
• Max roller speed? There is only one speed. However, a cart going in the direction of the rollers, and faster than the roller speed, is unaffected by them.
• Reverse roller running. If a cart tries to go the wrong way through a reverse roller, its velocity is decreased by 1 as it exits the tile. If the velocity goes negative (the cart would be travelling back the way it came, i.e. in the direction of the roller) it is immediately accelerated to the above roller speed. Crucially, this means a Highest speed roller can never launch a cart the wrong way through a Lowest speed roller.
• Derailing will always occur if v > 0.5, and never occur if v <= 0.5. No rollers can ever cause a cart to derail. Again, this is independent of cart weight. Non-track tiles seem to have a uniform friction of 0.05 m/s/s.
• Fluids introduce an element of randomness to cart physics. Here I got inconsistent and confusing results. Also, a headache. Generally, though, more water slows down a cart more, and 7/7 water slows it down a lot. This agrees with zuglar's findings, above.

Snaake's further research questions:

Maximum speed:
While I haven't tried it, there is a maximum speed set by the fact that ramps don't add a constant increment of speed. If my numbers are correct, then even a 200 z-level straight ramp will only get the minecart moving at just over 5.2 m/s. Not that that is slow, as such...

Cart-on-cart collisions:
I haven't tested this extensively, just pushing my two test carts into one another.
The results are that the collisions are not perfectly elastic. If a lighter cart strikes a heavier one, then the lighter cart stops, and the heavier cart moves off with the correct velocity to conserve momentum. If a heavier cart strikes a lighter one, then the heavier cart also stops, and the lighter cart moves off at the former speed speed of the heavier cart. Just my observations, there is a lot more to it than this.

That about covers the OP's questions.

Bear in mind, though, as with all science (and ‼SCIENCE‼), these are just the results of my tests. Corrections, complaints, comments and confirmations welcome.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Tryble on August 08, 2012, 04:37:05 pm

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

snip of enormous, incredibly sexy test results

I would like to do things to you that aren't fit to discuss in public.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Mura on August 08, 2012, 05:09:03 pm

... And welcome to the fora.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: SuicideJunkie on August 10, 2012, 11:21:47 pm

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

Down ramps have an acceleration of 0.068 m/s/s. Since a fast moving cart will spend few ticks on the ramp, this means that it will accelerate less than a slow moving cart. As a point of reference, a cart started from rest on the 8th ramp up will reach the bottom travelling at 1.0 m/s, five time faster than a Dorven push.
Comparing ramps and parabolic drops is difficult. However, a falling cart actually seems to gain less energy (1/2*v2) per z-level dropped than one rolling down a ramp.
Up ramps have an acceleration of -0.074 m/s/s. This means that a cart can never go up as far as it dropped.

How does the distance travelled carry over between tiles?
Consider a minecart with zero speed entering a sequence two down ramps followed by two up ramps, followed by flat ground:

Speed   Distance
Down Ramp 1
0.068   0.068
0.136   0.204
0.204   0.408
0.272   0.68
0.340   1.02

Down Ramp 2
0.408   1.428
0.476   1.904
0.544   2.448

Up Ramp 1
0.544   2.448
0.470   2.918
0.396   3.314

Up Ramp 2
0.322   3.636
0.248   3.884
0.174   4.058

Flat ground
0.174   4.058
0.1739   4.2319
0.1738   4.4057
0.1737   4.5794
0.1736   4.753
0.1735   4.9265
0.1734   5.0999
0.1733   5.2732
0.1732   5.4464
0.1731   5.6195
0.173   5.7925
0.1729   5.9654
0.1728   6.1382
...        ...

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Urist McTaverish on August 11, 2012, 01:17:54 am

Has anyone tested how a minecart full of magma reacts to being derailed? I'm interested in making a magma shotgun using a minecart and track as a sort of mass driver.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: SuicideJunkie on August 11, 2012, 09:42:57 am

See:
Fully Automatic Watergun (http://www.bay12forums.com/smf/index.php?topic=114654.0)
Magma should work the same except for setting things on fire and generating long-lived dangerous terrain.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on August 11, 2012, 10:08:21 am

Can you explain in more detail the difference in units and why the old system is wrong? I didn't quite follow that.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Dharma on August 12, 2012, 06:37:51 am

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

First time poster here. I was inspired by Snaake and xmoffitt's efforts to get to the bottom of quantifying the physics of minecarts.

Your post is very helpful, thanks a lot :)
I am trying to build minecart repeater for archery range, but it involves turn tiles. I expected them just to have higer friction, but it turned out they subtracts 0.01 m/s from minecart velocity (probably similar to reverse roller running) in addition to normal friction.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Reese on August 12, 2012, 10:58:51 am

Quote from: expwnent on August 11, 2012, 10:08:21 am

Can you explain in more detail the difference in units and why the old system is wrong? I didn't quite follow that.

the new system is squares per tick(and it more likely the actual numbers behind the system), the old system was ticks per square

in other words, how far you can get in a given period of time vs how much time it takes to go a set distance.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on August 12, 2012, 12:07:01 pm

But a minecart could be travelling at 1 1/2 ticks per tile, and its speed could be changing slowly on a tile by tile basis, or a tick by tick basis. Ticks per tile is hard to measure accurately, isn't it?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Dharma on August 12, 2012, 01:38:01 pm

Quote from: expwnent on August 11, 2012, 10:08:21 am

Can you explain in more detail the difference in units and why the old system is wrong? I didn't quite follow that.

Urist is measure of energy and m/s is measure of speed. Urists are quite handy as they define how far cart can go until it stops, how many upward ramps it can pass etc. Unfortunately, Urists don't exists in code, they are just a by-product of speed and acceleration calculations. Hence m/s are better suited to emulate DF's internal work (which is a must for high precision things like repeaters).
Another aspect of m/s is easiness of calculating travel times. It is much easier to estimate how much time it takes for highest speed rolled cart to cross 50 tiles knowing that cart speed is 0.5 m/s than that its energy is 1250 Urists.

tl;dr Urists aren't wrong, and can be better than m/s (depends on situation).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: zuglar on August 14, 2012, 11:58:43 am

Quote from: SuicideJunkie on August 10, 2012, 11:21:47 pm

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

Down ramps have an acceleration of 0.068 m/s/s. Since a fast moving cart will spend few ticks on the ramp, this means that it will accelerate less than a slow moving cart. As a point of reference, a cart started from rest on the 8th ramp up will reach the bottom travelling at 1.0 m/s, five time faster than a Dorven push.
Comparing ramps and parabolic drops is difficult. However, a falling cart actually seems to gain less energy (1/2*v2) per z-level dropped than one rolling down a ramp.
Up ramps have an acceleration of -0.074 m/s/s. This means that a cart can never go up as far as it dropped.

How does the distance travelled carry over between tiles?
Consider a minecart with zero speed entering a sequence two down ramps followed by two up ramps, followed by flat ground:

Spoiler (click to show/hide)

Speed   Distance
Down Ramp 1
0.068   0.068
0.136   0.204
0.204   0.408
0.272   0.68
0.340   1.02

Down Ramp 2
0.408   1.428
0.476   1.904
0.544   2.448

Up Ramp 1
0.544   2.448
0.470   2.918
0.396   3.314

Up Ramp 2
0.322   3.636
0.248   3.884
0.174   4.058

Flat ground
0.174   4.058
0.1739   4.2319
0.1738   4.4057
0.1737   4.5794
0.1736   4.753
0.1735   4.9265
0.1734   5.0999
0.1733   5.2732
0.1732   5.4464
0.1731   5.6195
0.173   5.7925
0.1729   5.9654
0.1728   6.1382
...        ...

So, under certain circumstance pairs up down and up ramps can deliver a net gain of energy.

For example, suppose we had a cart pushed on a track that has zero or flat segments followed by a down-up. For most lengths, the cart wouldn't make it back out of the pit, and for most of those that remain there's still a net loss of energy. For a few, though, there's a net gain:

Spoiler (click to show/hide)

Leading flat / exit velocity / exit position
20 0.3141 22.1476
29 0.3093 31.1260
39 0.3038 41.1305
41 0.3027 43.0951
44 0.3010 46.1075
47 0.2993 49.0910
50 0.2976 52.0456
51 0.2970 53.0815
56 0.2941 58.0376
57 0.2935 59.0525
58 0.2929 60.0638
59 0.2923 61.0715
60 0.2917 62.0756
61 0.2911 63.0761
62 0.2905 64.0730
63 0.2899 65.0663
64 0.2893 66.0560
65 0.2887 67.0421
66 0.2881 68.0246
67 0.2875 69.0035
71 0.2850 73.0435
72 0.2844 74.0038
75 0.2825 77.0210
76 0.2079 78.1742
77 0.2812 79.0646
78 0.2806 80.0021
80 0.2793 82.0210
81 0.2047 83.1518
82 0.2780 84.0230
83 0.2034 85.1447
84 0.2767 86.0081
85 0.2021 87.1207
86 0.2014 88.1777
87 0.2747 89.0291
88 0.2001 90.1277
90 0.2727 92.0101
97 0.2679 99.0013
98 0.2672 100.0016

20 leading tiles seems to be the best, a pushed cart will exit the up ramp moving 0.31m/s, assuming that the push starts the cart halway through the first tile and that position is updated before velocity. 29, 39, 41 and 44 also give exit velocities above 0.3m/s. The biggest problem is the numbers are *very* sensitive to initial velocity and position, so it would take some searching to find robust setups that accelerate under all conditions they might be subjected to in your particular track.

Unfortunately, it takes about 0.4m/s to climb a z-level, so it would take a lot of work to exploit this as a replacement for rollers, though I think somebody had posted a trick that repeatedly derails the minecart off corner ramp tracks.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Dharma on August 16, 2012, 02:33:57 am

When cart goes up or down ramp it skips half of the next tile. In case of down-up pit, the next tile is up ramp, so down-up almost always result in net gain (and up-down in net loss) of energy.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: zuglar on August 16, 2012, 10:15:39 pm

Quote from: Dharma on August 16, 2012, 02:33:57 am

When cart goes up or down ramp it skips half of the next tile. In case of down-up pit, the next tile is up ramp, so down-up almost always result in net gain (and up-down in net loss) of energy.

!!

That's news to me. It changes a lot, probably makes the numbers *much* less touchy.

I'm having trouble modeling this tho. Consider a track that goes like this (seen from the side):

A_      __C
  \B_  /
     \/


My calculations suggested that pushing the cart east from B should give it enough momentum to reach C. Instead, it got almost to the top where C is, then reversed directions and ended up at A. The tiles between A and B weren't even smoothed track -- I didn't think they were needed -- and still the cart got past them, and several tiles beyond until it collided with a wall!

If it really skips a half a tile per ramp, then I don't see how it could go B-almostC-B-A when it can't go B-C. Or does it only skip the half tile when changing vertical directions (e.g. flat-up, up-down, etc.)?

BTW, speaking of skips: how much momentum does it take for a cart to skip over a gap? Does filling the hole with water/magma change that?

And, speaking of loss of energy, how much does a minecart lose when derailing or going off end of track?I've noticed that the following loop can skip over the gap outbound, but not on the return trip, when pushed east from the track stop:

   ▼╔═╗
≡══·╝╞╝


But on the other hand, just two down ramps (even with matching up ramps later) gave enough momentum to run over quite a bit of terrain in my first example above...

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Dharma on August 16, 2012, 10:55:12 pm

Quote from: zuglar on August 16, 2012, 10:15:39 pm

Quote from: Dharma on August 16, 2012, 02:33:57 am

When cart goes up or down ramp it skips half of the next tile. In case of down-up pit, the next tile is up ramp, so down-up almost always result in net gain (and up-down in net loss) of energy.

!!

That's news to me. It changes a lot, probably makes the numbers *much* less touchy.

I'm having trouble modeling this tho. Consider a track that goes like this (seen from the side):

A_      __C
  \B_  /
     \/

Probably, skip after ramp happens only after direction change(du - u skipped, dd - d not skipped), so it is not as useful as I thought at first. Still, it is another thing to be aware of...

Our knowledge on minecarts is far from complete. Turns and flats works exactly as they should, but ramps simulation doesn't work at all for now - and not only because of skip. I'll continue work on perfect minecart simulator, but my other, less interesting, projects demanding my attention too.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: zuglar on August 16, 2012, 11:40:49 pm

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

Non-track tiles seem to have a uniform friction of 0.05 m/s/s.

I think this is wrong. I'm trying to verify with the following setups, where the top is purely rough stone and the bottom two are stretches of rough followed by track:
■....................
■..........==========
■.........========================================

Pushing each cart, the top one travels 11 tiles, the middle travels 18, and the bottom 37.

Assuming vIn=0.2, that the push skips the first half tile, and that position is updated before velocity***, that's a friction of roughly 0.002m/s/s, but not exactly: it predicts travel of 10.4/18/31; using friction of 0.00185m/s/s instead predicts 11.2/14.9/31. Again that numerical instability shows up, which makes me suspect the computation is based on ticks/tile rather than tiles/tick. I'll try to work out numbers that way and report back.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on August 17, 2012, 09:31:54 am

Creatures can move "partial" tiles, in that if they don't have a speed of an integer number of ticks per tile, it'll average out correctly. Could that explain the numerical instability?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Sutremaine on August 17, 2012, 01:14:42 pm

Quote from: zuglar on August 16, 2012, 10:15:39 pm

And, speaking of loss of energy, how much does a minecart lose when derailing or going off end of track?I've noticed that the following loop can skip over the gap outbound, but not on the return trip, when pushed east from the track stop:

   ▼╔═╗
≡══·╝╞╝

Corners drain speed. Try pushing a cart along a track vs. along a track with channels vs. along a track that derails at every tile (you might want to construct that last one...).

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on August 17, 2012, 03:27:53 pm

I've discovered something strange. I use a linear accelerator as described, with 20 NE ramps to accelerate a pushed minecart. After the 20 NE ramps, there's an EW ramp to launch the cart. One tile above it and to the east, there's another EW ramp, but the higher ramp does NOT have a wall to the right of it, so it's unusable.

Minecart is pushed from the far west:

Side view:

Code: [Select]

       R
...AAARW

A = accelerator = NE

The effect: the minecart stops in midair after launching off the second ramp. With a wall placed after the second ramp, the minecart launches as you would expect. With the wall after the first ramp removed, it just ignores the first ramp.

This is still quite unsafe for dwarves riding in the cart. They tend to take damage in midair just before the cart falls, probably due to the rapid acceleration.

Strangely enough, you can get splatterings of blood in midair in this way. I'm sure this can be weaponized somehow. If you can launch a creature with poisonous blood in this way, you can use it as defense against flying creatures maybe.

edit: It will also launch its contents, if any.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: zuglar on August 17, 2012, 05:18:23 pm

Quote from: electrobadger on August 07, 2012, 06:23:56 pm

Down ramps have an acceleration of 0.068 m/s/s. Since a fast moving cart will spend few ticks on the ramp, this means that it will accelerate less than a slow moving cart. As a point of reference, a cart started from rest on the 8th ramp up will reach the bottom travelling at 1.0 m/s, five time faster than a Dorven push.

Quote

While I haven't tried it, there is a maximum speed set by the fact that ramps don't add a constant increment of speed. If my numbers are correct, then even a 200 z-level straight ramp will only get the minecart moving at just over 5.2 m/s.

What's the fastest anyone's ever actually observed a cart going? If the model I'm working on is correct, the absolute upper speed limit approaches two tiles/tick. A 100-z down ramp would give enough velocity to make a cart skip a tile very few tiles traveled. Caveat: this does *not* incorporate the half-tile skippage that was recently pointed out, so occasional "glitch" tile skips are probably possible at lower speeds.

Another prediction of my model: a 2x2 all-corners downward spiral should be somewhat self-regulating, with v approaching 0.67m/s and taking about 80z for a cart to pass 0.6m/s.

Only problem: my model predicts that an 8z down-ramp should only accelerate a cart to 0.4m/s; I haven't tested this prediction explicitly, but it is fairly consistent with my observations of a spiral down-ramp (diameter 3) I had dropping 30z.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on August 18, 2012, 08:05:56 pm

I can confirm electrobadger's main results. I used CheatEngine to look into the game. The minecart has a variable for speed. Speed is measured in tiles/100000 per tick, so a speed of one hundred thousand means one tile per tick. Since the game internals use these units, this is what I will use.

The maximum speed is 270,000. You can hit it exactly by going down enough ramps.

Every tick, your speed goes down by some constant based on what tile you are currently on.

Distances: if you push a cart, you start in the MIDDLE of the next tile, not the far end of it, so it takes half as much for you to get past it. Normally, once you've accumulated 100000 distance units, you move to the next tile. This DOES carry over to the next tile.

Tile: friction
Tracks: 10
ground/floor: 200
unusable ramp: 10
going up a ramp: 4910
going down a ramp: -4890

A dwarven push starts the minecart at 19990 in the middle of the next tile, in that the first nonzero speed that the cart has is 19990.

Corner tracks are 10, but on leaving the corner tile, you get penalized another 1000 (in addition to the friction of the next tile).

Track stops:
highest: 50000
high: 10000
medium: 500
low: 50
lowest: 10

Empty space is entirely frictionless.

You CAN phase through walls if both flying and moving faster than one tile per tick, but you stop immediately on the other side. Cue everyone's secret fortress entrances behind walls.

---
WATER

Take the water level (out of seven), then subtract one, then multiply by 100. Add this to the tile's normal friction to get the friction of the tile in that much water.

MAGMA

Take the magma level out of seven, then subtract one, the multiply by 500. Add this to the tile's normal friction to get the friction of the tile in that much magma.

If the cart at least 6/7 deep, and it has room, it will take 2/7 into itself.

I'm (finally) tired of this. I'll put it in a more digestible format on the wiki later.

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

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Snaake on August 24, 2012, 08:16:08 am

Quote from: Tryble on August 05, 2012, 02:58:28 pm

So, if I'm reading all of this right, a short list of facts we now know based on your testing:
...
Upward ramps are wonky; they can decrease or increase the distance traveled by a cart.
...

Is this right?  I may have misread or misinterpreted some things.

The rest was correct: upward ramps do always decrease the distance traveled from what it would've gone on the lower z-level; however, if minecarts go down, then up a ramp, that's unpredictable. Probably because both vary around some identical(?) average (due to some integer rounding or something in the physics), so sometimes you get a net gain, sometimes a net loss. Looking back at the data (post #21), the most common result I got was an increase in kinetic energy.

Other than that, I'd like to thank at electrobadger for doing some independent testing; from a quick(ish) look, it seems that portions of both xmoffitt's and my research were validated. Looking at his results, I'm especially happy that the abovementioned mystery of ramps is solved (points 9-11, post #45 (http://www.bay12forums.com/smf/index.php?topic=112831.msg3508793#msg3508793)): up ramps do take away more energy from a cart than a down ramp gives, but this is per tick, not per tile, and so, since the cart is traveling faster after the down ramp than it was before, it spends less time on the up ramp than it did on the down ramp, and hence, often has some speed "left over". Also an interesting note about the existence of an asymptotic maximum speed, even for megaramp-powered carts.

Also, kudos to zuglar and expwnent (why on earth didn't someone check what the actual internal units were before... *facepalm*). This is starting to look more or less "solved". I think I'll have another look at all that weird-looking data I got for turns, would be satisfying to see it match simulations based off the values mentioned recently.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: taptap on June 13, 2015, 04:27:34 am

Quote from: expwnent on August 18, 2012, 08:05:56 pm

Track stops:
highest: 50000
high: 10000
medium: 500
low: 50
lowest: 10

Is this still correct?

A minecart coming out of a speed limiter (i.e. 45-50k speed) when going through a series of high friction track stops on the second, indicating 25k friction if I am not missing anything. Wait, per tick not per tile?

Title: Re: SCIENCE: Quantifying minecart physics
Post by: expwnent on June 13, 2015, 05:28:05 am

It is per tick, not per tile. I have not checked the results since I originally produced them.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: taptap on June 13, 2015, 06:22:07 am

Quote from: expwnent on June 13, 2015, 05:28:05 am

It is per tick, not per tile. I have not checked the results since I originally produced them.

Sorry, I realised it a little later.

Title: Re: SCIENCE: Quantifying minecart physics
Post by: Max™ on June 13, 2015, 04:13:44 pm

Huh, I think I bumped into the 270k speed cap from the other direction while screwing with launch.lua, I was opening gm-editor in mid-air and screwing with the projectile speeds and I recall that setting it over something like 2.5 million tended to result in death, superdeaths whereupon even if you cheat and resurrect yourself you immediately slam into something again.

Oh and at speeds that high you can grind yourself against the roof of the skybox it looks like. I didn't think to try 2.7 exactly, I just know 3.0 = death, 2.5 = generally ouch, ~2.25 = usually safe.

...BAHAHAHAHAHAHAHAHAHAHAHAHAHAHA... ok, yeah, I confirmed that 2.7 million is a safe speed for a unit in flight, and was going to see what happened if I touched down with the flag toady told me lets you do a safe jump to land on your feet, well, this is also the save I was testing artifake and names with right?

Spoiler (click to show/hide)

(http://i.imgur.com/mFlmVdb.png)

So yeah, I hit a tree (and went through to the other side, painfully >.<) but that isn't why I'm laughing.

I named my upper greaves "Crotchsaver" because I was just doing simple names, Headbox, Kittenstomper, etc, and Crotchsaver seemed apt... and it was!

Title: Re: SCIENCE: Quantifying minecart physics
Post by: NW_Kohaku on June 13, 2015, 06:09:32 pm

Quote from: taptap on June 13, 2015, 04:27:34 am

A minecart coming out of a speed limiter (i.e. 45-50k speed) when going through a series of high friction track stops on the second, indicating 25k friction if I am not missing anything. Wait, per tick not per tile?

Are you accounting for the checkpoint bug?  The first tile after a ramp has no effect upon a cart, and a cart will pass through it in one tick.