User talk:Misacek01

Welcome to the Official Factorio Wiki! Now that you have an account, there are a few key places on this Wiki that will be helpful in your efforts to improve it.
First and foremost, please be sure to read and understand the rules of this Wiki. If you have any questions or concerns with these rules, please don't hesitate to ask an Admin.
Secondly, if you're new to editing Wikis and are unfamiliar with MediaWiki's formatting, please be sure to read the help pages. In addition to the help provided by MW, we also provide a style guide that we enforce.
If you're unsure where to begin, please see the editor noticeboard, where information on the current objectives and projects of the Wiki may be found.
Again, welcome, we hope you contribute as much high quality information as you can. :) Gangsir (talk) - Admin 23:45, 19 September 2017 (UTC)

Page Edits Under Construction (Please Don't Edit)

Throughput

Unlike belt-based transport systems, there is no simple, straightforward way to precisely calculate how many trains one needs to move a given quantity of items. However, like other transport methods, there is a well-defined output of resources at the source (loading station) and consumption at the destination (unloading station). Based on these, a train network can be designed either to move all product from the source to the destination (capacity covers all input), or to move at least enough product to cover demand at the destination (if this is less than output at the source).

Players should note that if a train network is underdesigned (not enough trains to cover demand at destination), trains will tend to load and unload in the minimum time possible given the player's station design, and spend most of their time traveling. If, on the other hand, a network is overdesigned (more trains than needed to cover demand at destination), then the network will self-adjust by leaving some trains underutilized, and the "extra" trains will tend to wait in and before stations.

In the latter case, if output at source is greater than demand at destination, the trains will tend to wait before the destination (waiting to unload), while if output is less than demand, trains will pile before the source (waiting to load). Either way, this is why it is a good idea to have stackers (waiting areas) near your stations, so that such waiting trains do not block other traffic on the network's main "through" rails.

Note that the above behavior corresponds to "wait until full / empty" departure conditions at source / destination. Certain other conditions / condition combinations will preserve it, but some will not. For example, trains set to leave stations if and only if a specific number of seconds has passed will always do so, regardless of whether they are full, empty, or partially empty, and will generally not adjust to changes in source output / destination demand in any way.

Simple Example - Ore Transport

Let us assume the player needs to transport all the ore mined at remote mining outposts back to their base for smelting, and decides to use trains and stations dedicated to each ore type, but running the bulk of the distance on the same rail system. The train configuration the player has decided on is 1-4-0; i.e., 1 locomotive, 4 cargo wagons, no locomotives on the other end of the train (unidirectional, or "single-headed", train). The trains will run on nuclear fuel for best possible acceleration and top speed.

The player will likely want to know how many trains they will need to assign to each ore loading station to transport all of their mines' output, and may also be interested in the total number of trains to help them decide on how many rails their system should use.

Let us focus on transporting the output of a single iron ore field. (The situation would be the same for copper or coal, as they have the same mining time and stack size as iron, but not stone or uranium, whose mining times are different.) The field has 120 drills, of which none are expected to run out in the near future; the drills use only efficiency modules and the player's mining productivity bonus is at 80%. The field has its own loading station to which no other fields contribute their output.

A manual calculation (or one of the online Factorio calculators) tells us that this field will produce about 6,800 ore per minute (a bit less than 3 full blue belts). All trains have 4 wagons per train, which can transport 8,000 units of iron ore (2,000 units, in 40 stacks of 50, per wagon). For simplicity, let us assume that all trains serving this station will stop at no other loading stations and deliver all cargo to only a single unloading station (which may, however, be shared with trains from other loading stations).

The throughput of the train network associated with this station (i.e., the station, its destination, and all trains running the route between the two) is then J = 8,000 x N / T, where N is the number of trains on the route and T is the time an individual train takes to run a full circuit on the route (i.e., for example the time between a particular train's two successive departures from the loading station). (J, used in physics for flux, here denotes throughput.)

The number of trains we need to move 6,800 ore per minute on the network is then N = J x T / 8,000 = T x 6,800 / 8,000 = T x 17 / 20 = 0.85 T. So far, the mathematics has been straightforward; however, the time T a train takes to complete a circuit will in practice likely need to be estimated; the only other option is detailed observation of trains running on the actual network in question.

Estimation of train round trip time - Simple

The following section is quite technical and mostly discusses advanced concepts in train network design. If you are here looking for a simple way to estimate the time a train takes on a track also used by other trains, this is probably sufficient:

• Estimate the full-speed circuit time as above.
• Add 20-30 seconds, depending on whether, in your estimation, the part of the network the train will run on has "a lot" or "little" traffic.

Note that the above is highly simplified and intended for networks that:

• Are well designed
• Are well signaled
• Have well-organized traffic
• Have efficient station design
• Are of "reasonable" length and complexity
  • For example, a typical megabase-scale network might be too large to qualify.

In addition to the above, it will generally tend to be a poor estimate in any of the following cases:

• The network has service interruptions, for example due to:
  • deadlocks
  • trains out of fuel
  • biter damage
  • bad circuit logic, etc.
• The departure conditions are poorly designed
• Low-performing fuel is used
  • Generally, nuclear fuel is optimal, but rocket fuel may also be adequate; if your trains burn small power poles, do not expect the above figure to be accurate.
• Relevant research (braking force, stack inserter capacity) is lacking (should be at maximum)

If you feel your network may have some of the above issues, feel free to read on; some (though not all) are covered in the more technical section below.

Estimation of train round trip time - Advanced

Estimation of the train round trip time could proceed e.g. like this:

1. Measure the approximate length of rail, in tiles, that makes up the circuit.

• If the circuit mostly consists of parallel "there" and "back" rails in close proximity, measuring the one-way length and multiplying by 2 is probably good enough.
• If the bulk of your rail line follows a tiled blueprint of known length (e.g., a reasonably long segment of perimeter wall), you can count the number of iterations of that blueprint to get a simple estimate of the length of the rail.
• It is possible to place text notes on the main map. If your rail line is mostly a long, straight drive to some far-flung outpost, you could measure convenient landmarks (big power poles, fixed-interval defenses, etc.) and note the distance from some starting point in the map in reasonable intervals (e.g., 500 or 1,000 tiles) for any future needs.
• The same as above can be accomplished with "marker" blueprints of known length. (The marker being some distinctive but non-essential blueprintable structure, e.g. a "+" made out of walls, etc.) These can also be combined with the map notes if desired.
• Precision measurements are generally not essential; for example, an error on the +-10% scale is probably acceptable for most purposes.
• If precision results are desired, there are several options:
  • If the entire rail line is covered by radar vision, you can blueprint it (in parts if necessary) and count the number of rail segments (x2 for number of tiles) in the blueprint tooltip.
  • You could isolate the line from all traffic and send a train through for a "test lap", using either out-of-game timepieces or in-game combinator clocks to measure the duration directly. Note that clearing all traffic may be highly impractical if parts of the route are in heavy use by other automated trains.
  • You could do the same as above but drive manually, "pedal to the metal", and hope for the best on any intersections. In this case, you would not need to clear traffic, but saving the game beforehand might be a good idea.

2. On nuclear fuel, train top speed is 83 tiles / second (shown in-game as 298.8 km/h, on the assumption that 1 tile = 1 meter, the mps-to-kph conversion factor being x3.6).

3. First assume that the train will run the entire circuit at top speed, with no waiting at crossings and stations and "instant" acceleration / deceleration. In that case, its time will be T[1] = L / 83 seconds, where L is the length of one full circuit in tiles. (If measured from rail blueprint: Keep in mind that 1 straight rail segment = 2 tiles; 1 curved rail segment =~ 8 tiles.)

4. Next, you will need to make adjustments to the "lower bound time" T[1], mainly for:

4.1. Time spent loading and unloading

• In this, assume the train (un)loads in the minimum time the station can manage. This will generally be true unless the station becomes the bottleneck (not enough output at source / demand at destination), which will only happen if the train capacity is overdesigned. Since we are trying to find the minimum required number of trains, that case does not interest us.
• The minimum possible time to load a train in an unmodded game is about 12.04 * (S / 100) seconds, where S is stack size of the item being loaded. This applies when 12 stack inserters per wagon are used and inserter stack size bonus is researched to maximum, and assumes no slot limiting (via the red X symbol or due to slots being filter-reserved for something else) in the wagon, and that inserters load from / unload into chests with sufficient item stocks / free space. Note that the number of wagons has no effect, as all can load simultaneously.
• Since for ores, S = 50, the time to load a train full of ore is about 6.02 seconds. Thus, assume 6 seconds to load and another 6 to unload.

4.2. Time spent accelerating from and decelerating before stations

• For stations, both acceleration and deceleration time depend only on:
  • train mass
  • number of active locomotives
  • fuel acceleration (and, indirectly, top speed) bonus
  • braking force research
• Assuming 1-4-0 trains running on nuclear fuel and braking research at maximum, the time penalty due to acceleration and deceleration vis-a-vis a full-speed run is not large. It could be calculated using the actual values the game uses to do so, which could likely be retrieved from the game files; however, this is tedious and probably not necessary. (Note that the calculation would most likely require calculus, as generally acceleration problems lead to differential equations.)

4.3. Time spent waiting at, accelerating from, and decelerating before intersections

4.3.1. Waiting time:

4.3.2. Acceleration and deceleration time

• These can vary wildly depending on how many times the train must stop at intersections, as well as how far before the intersection the train starts decelerating.
• Acceleration time from a light is the same as from a station, but deceleration time can be reduced (all the way to zero, i.e., an instant stop) if a light in front of the train turns red later than the point where the train would need to start braking using the "normal" deceleration curve.
• Trains always stop at red lights so long as the train's lead element has not yet passed the light's position, even if they need to decelerate from full speed to zero in a single tick to do so, as it is the only way to conclusively prevent crashes between automated trains given the pathfinding and driving algorithms the game uses.
• The likelihood of a light turning red while a train is "too near" to stop normally generally increases with the number of intersections on the route and the amount of traffic trough them; however, aside from that observation it is highly unpredictable to the point of near-randomness.
  • Note that generally, problems of this type - i.e., the organization of transport and throughput on topologically complex networks - require very advanced mathematics to solve, and some are not even known to have (or are known to not have) definite analytical solutions. In any event, the complexity of calculation that would be required is far beyond what it is likely reasonable to expend on a partial component of a problem in a video game.
  • As a practical solution, you may apply a small reduction (say, around ~1 second per instance) to the acceleration + deceleration time penalty of a red light stop relative to the time penalty you have estimated for the acceleration + deceleration part of a station stop.
• In general, as a network approaches a certain level of traffic (its "limit throughput"), delays due to intersection waits, originally small for traffic levels well below the limit, will tend to increase over-proportionally to the incremental increase in traffic, and eventually the network will lock down completely. (The lockdown level of traffic is an exceedingly complex function of the network's topology, and calculating it would entail the high mathematics mentioned above.)
  • For traffic levels near the lockdown threshold, transit times will be finite but exceedingly high; therefore, given how cheap all cosntruction in Factorio ultimately is, it is best to expand the network infrastructure if and when you start noticing considerable delays due to intersections (i.e., delays relative to a "clean" run of the circuit with no waits).
  • Where exactly you set your cutoff is up to you, but if your trains spend, say, 1/3 of total circuit time waiting, your network is probably nearing its limits and you might do well to consider expanding it. (Although before that, it may be a good idea to check that the source of excessive delays is not deadlocks, trains out of fuel, biter damage, poor or incorrect signalling, and other "preventable" problems.)
  • As a side note, this also implies there is a maximum throughput that a network with a given topology can have such that adding further trains past the number corresponding to the maximum actually lowers the throughput. An intuitive way to visualize this is a road which obviously moves more cars from start to end when not quite full than when completely jammed. While there are certainly more individual cars per unit length on the solid-jam road than on the half-full one, none of them are getting anywhere, while on the half-full road at least some cars are getting somewhere. Unfortunately, again the optimum capacity is hard to calculate unless the network is trivially simple.