Possible Replacement for WSP-Submitted for discussion

  • In looking at the resources for this game (read: wikias) I've noticed people making reference to an engine's WSP or Waggon-Speed Product. This metric is inherently flawed in that it does not take into account the time that an engine spends accelerating from it's standing start.

    After crunching the numbers and running equations (yay math!) I've come up with a possible replacement for this metric. Although mine doesn't give a straight-up number it does give you a simple equation that can be used to compare two engines for running the same route. I present the Break-Even Equation:


    or in game terms: MaxSpeed*(t-(MaxSpeed/2*Acceleration))

    To use this to compare engines take their equations and set them equal to each other then solve for t. This will give you the time it will take for the slower accelerating train to overtake the faster accelerating train. If the t value is negative that means that one of the trains is both faster overall and faster accelerating. These equations are most useful to determine whether or not a faster acceleration is worth a tradeoff in speed for a given run.

    This is just a basic equations and I have derived versions of this that take into account an engine's condition % and the number of waggons it hauls. These more complex equations, as well as the math I used to get the basic version can be supplied upon request.

  • Here's the finished piece. This one takes into account, # of waggons hauled and condition. It does not mention wait times because it would be the same for either train and therefore the wait times would be cancelled out in the solve.


    a = Acceleration
    c = Condition (as a percentage)
    t = time, solve for this.
    v = velocity (max speed)
    w = # of waggons per EH slot

    Once you select two trains and solve for t. If the answer is 0 or negative, use the faster train, it will always be more profitable. Otherwise if the one-way travel time for the route is more than t use the faster train, if it is less than t use the slower train. For Bonus Engines always assume that it uses 1 EH Slot.

  • Excellent work. But it needs to be taken a step further. Not many people are going to want to work out these equations train pair by train pair. We need to do the calculations and put the results into a matrix, era by era. Then this will be very useful. I'll get to work on that soon.

  • I looked at the "Physics" of it and considered Velocity and Acceleration. However it has been a long time since I did that type of Math and even longer since I dealt with Physics.
    This much I am sure of traction which should have a bearing on acceleration and velocity does not apply ie. An empty wagon travels the same time as a full train.
    With the changes in the game; (not sure if things have changed in Rail Nation USA) there should be a difference between various trains depending on how near or far the goods are. I am not sure if anyone does this though.

  • Ok, either we need a better explanation of the results, or there is some thing wrong with the equations. I worked out Swallow vs. Raven and Swallow vs. Rhino. I assumed condition = 100% and all upgrades were installed for both trains in each pairing. Unless I did my arithmetic wrong, here are my results: Swallow vs. Raven, T = -8121.16; Swallow vs. Rhino, T = 6.22.

    Now, you said that "If the answer is 0 or negative, use the faster train." That would mean that the Raven would be preferred over the Swallow. However, Swallow vs. Rhino yields a positive T, even though the Rhino is clearly superior in velocity, waggons and acceleration.

    So, either the explanation of result needs more detail, or the equations are flawed. I don't know which.

  • @Peeks: Traction does not seem to play a part in any of the game physics, so I have ignored it when creating my equations.

    7om : I re-ran the numbers for Swallow vs Rhino and got 0.27sec. The Rhino may be superior in waggons hauled and acceleration but it is not in top speed (80kph Swallow vs 70kph Rhino). As for the Swallow vs. Raven. Yes, the t value is negative (-61.48 by my calculations) so the faster train (Raven 85kph vs Swallow 80kph) would be more profitable.

  • It's a nice effort but I still think traction force and distance need to be considered as well. I saw somebody's spreadsheet a while back that showed their efforts to calculate route times based on acceleration and speed, but the work was unfinished. It gave distances to top speed in feet, IIRC, but how many feet are represented by a single set of tracks is another question. I guess I can try to figure that out now since one of the supplies for the RG I'm hauling is a single track away.

  • Disregard my previous post. I didn't notice the details of Post #2 until we were talking about it in chat.

  • As we said in chat (man, I wish I had screenshot that, good stuff) it appears that the map is set up like a hexboard. For the benefit of those who have never seen one a hexboard is a map where the entire picture has been marked off in intelocking, uniform hexagonal pieces. These are most often used in tabletop strategy/role-palying games (Tobruk by Avalon Hill, Hammer's Slammers by Mayfair Games, Robotech by FASA, and Iron Dragon by Eden Studios are examples of what I mean). It creates a very simple system to calculate distances by however many 'hexes' away the target is. In this case you can clearly see this concept being applied in how the rail between industries and cities are laid out. There are only 6 possible directions that tracking can take. (E/W, NE/SW, NW/SE), a track is NEVER seen going N/S, this is a dead giveaway that the Devs used a hexboard to design the map.

    People have been assuming that the distances of a piece of track are equal, this is a fallacy. They are measured in hexes this is what is leading to the different travel times between industries for the same train. As yet, I am uncertain the distance being represented by each hex on the map but that is not my focus atm.

    Zaniac, you mentioned the spreadsheet that Arianna made (I was helping him with the physics of it before he disappeared). It did mention the distance in feet but that had no bearing on the rest of the sheet. In fact, it was Arianna's work that inspired me to derive the equation from post #2. I was hoping to combine his work with my equations to come up with a definitive 'this is better than that' matrix of engines.

  • Well, since you mention it:

    When I was experimenting with travel times, the one I specifically paid the most attention to was what I'm already hauling - Lampworks to Cars in New Cork. The track is laid in a NE/SW direction. Travel time for a fully upgraded Centaur with 100% condition was 00:20 each way. The same trip took would have taken my Satyrs at 99% condition 1:13.5 to complete.

    Now that you've explained in more detail the hexboard concept here, I can see exactly what you mean now. It's like having right triangles where the E/W tracks are the base, the N/S tracks just don't exist, and the NE/SW and NW/SE tracks would represent a hypotenuse. I should have looked here before switching servers. I'll look up travel times later this morning since one of my Centaurs will need servicing by then anyway.

  • Not right triangles, equilateral. I know it's a nit-picky mathematical distinction but a right triangle has one angle of 90 degrees. The triangles created by connecting hexes on a hexboard are equilateral, all angles are 60 degrees and all sides of the triangle are equal.

    The short version of the math content is this: lose w entirely from the equation in Post #2, set t equal to the one-way travel time as calculated by the game and you can use my equation to calculate the distance between the two industries. Equation then becomes d=vc[t-(vc/2a)]

    This section is necessary to explain why the short version works.

    In my original derivation of the equation I started with the Velocity-Time curve (read: graph, but in mathematics all graphs are called curves). With this curve it's a straight solve for the speed, the slope of the graph is the acceleration and the area underneath it is the distance covered.

    Starting with the basic kinematic motion equation of V=AT. I set up the curve so that it grew linearly (acceleration of a) until the max velocity (Vm) was reached (I called this point Tv), and remained flat after that point. I then set the arbitrary end point of the graph to be Tf and left it that way.

    Using the Rules of Integration from Calculus I then figured the area under the curve to be:
    ∫at dt (from 0 to Tv) + ∫Vm dt (from Tv to Tf).

    Solving these gave me:
    0.5at^2 |(from 0 to Tv) + Vmt |(from Tv to Tf).

    Evaluating those gives:

    With v=at being the basis of the equation you can then say that t=v/a and then substitute Vm/a for Tv:

    Continuing on:




    For simplicity's sake change Vm to v and Tf to t and you get

    The train's condition percentage directly modifies it's max speed (v), so a 100kph train at 80% only goes 80kph. By changing v into vc anywhere it appears...

    If we were to plug numbers diectly into the equation now we'd end up with unit conversion errors (why the Mars Probe slammed into Mars in 1999). So we'll have to convert v and a. As a hack (I've already explain enough for one post) the conversion rate is 5/18.
    So 190kph = 950/18 m/s
    15 acceleration = 75/18 m/s^2

    One thing you need to make sure of is that the travel time is greater than the time it takes the train to reach max speed. If it is less than this you wouldn't need my equation the answer would simply be d=0.5at^2. With your Centaur example the time to reach max speed is 190/15 or about 12.67 sec.

    d=1947500/2700≈ 721.296 meters

    This number can be further refined by doing these calculations with other trains in order to eliminate roundoff error generated by the computer.


    The post was edited 1 time, last by Grundini ().

  • Working on factoring in an engines reliability but the numbers are getting ugly.

  • Once you come up with something really solid, you should add the info somewhere to one or both of the wikis. It would be cool if we could even setup a built-in calculator there, such that players would only need to input their data and let the calculator figure out the answer for them.

  • My brain has started bleeding trying to keep up with you guys. Thanks for taking a fun game and turning it into a learning lesson that I cannot deal with.. My brain has imploded and turned into pudding..thanks a lot.. :laugh:

  • I know it is heavy but it is interesting. I am sticking this because it has a lot of potential. Thank you Grundini.

  • I would expect trains to have to both accelerate away from a stop and decelerate when approaching a stop. So


    might be a better equation.

  • I put together some graphs showing hauling capacity (tons/hour) vs distance traveled using the math and assumptions discussed in this thread.

    The following link might work...


    It might be desirable to reduce tons/hour by a consistent factor of two to take into account round trips. While the graphs may contain numerous errors, they seem to give a more intuitive picture of the relative power of each train. (I'm now putting the source code firmly in the public domain. Use as you see fit. Credit me if it's easy, but, hey, if it makes you feel good to claim sole credit, I don't have a problem with that either.)

  • Can this "discussion" please be unstickied?

    It actually truly hurts that it is stickied in the first place :(