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)

Affordability

Infinite research is essentially an inexhaustible resource sink for players who build very large bases. While the bonuses it provides can significantly improve the player's capabilities (particularly as regards combat), they are subject to diminishing returns; thus, the per-level contributions from very high levels of infinite research will eventually provide only marginal improvements.

As the price of most infinite research topics (specifically, those based on geometric progressions) increases very steeply, it may be a good idea for players to set realistic target levels for each of the infinite research topics they wish to pursue, and make their factory plans accordingly. To that end, the following properties of cumulative infinite research prices may be useful:

• The cumulative price of the first N - F levels (notation as in previous sections; i.e., here counting "infinite" levels only) of infinite research topics whose underlying equation is a powers-of-two geometric series (see equation type (1) in preceding sections) is 2 × P[N] - P[F+1]; i.e., twice the price of the final researched level, less the price of the first "infinite" level.
  • This tends toward 2 × P[N] as N goes to infinity.
  • The above also shows that, assuming constant research speed (usually, this is the same as science pack production capacity), each subsequent level of an infinite research topic of this type will take about as long as all preceding infinite levels took combined (or, twice as long as the previous level).
  • Further, assuming one has reached a level M they consider the "highest feasible" with their current science pack production capacity, expanding said capacity by a factor of X will allow at least floor(log[2](X)) and at most ceiling(log[2](X)) (i.e., the next lower / higher integer from the base-2 logarithm of X) additional levels to be researched before the next level takes longer to research with the expanded capacity than level M + 1 would have taken with the pre-expansion production capacity.
    • For example, if one expands production capacity by a factor of 10, they will be able to research at least floor(log[2](10)) = 3 and at most ceiling(log[2](10)) = 4 additional levels in a given technology before the exponential increase in price wipes out the benefits of their ×10 capacity expansion.
• The cumulative price of the first N - F levels of infinite research topics whose underlying equation is an arithmetic series (equation type (3)) is (N - F) × (P[N] + P[F + 1]) ÷ 2; i.e, N - F times the mean of the prices of the first and last "infinite" level.
  • Expanding production capacity by a factor of X, as above, will in this case allow an additional N × (X - 1) levels to be researched before the benefit of the expansion is wiped out (i.e., research progress speed drops to or below what it was pre-expansion).
• The cumulative price of the first N levels of artillery shell shooting speed, the sole infinite research topic whose underlying equation is a powers-of-three geometric series (equation type (2)) is 1.5 × P[N] - 0.5 × P[1]; i.e., 1.5 times the price of the final researched level, less half the price of the first level. (Note that the expressions above have been simplified to reflect the fact that this particular topic has F = 0. Since it is the only topic with this equation type, the loss of generality does not matter.)
• In all

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 Advanced section below 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
  • The simplest way is probably either to drive manually through at top speed, stopping nowhere, or to divide the length of the circuit in tiles by train top speed with the fuel in question (usually, 83 tiles / second).
  • For detailed advice, see Advanced section.
• 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 intended for train schedules conforming to the example in the previous "Ore Transport" section, i.e., schedules where:

• The train moves a single product
• The train has only 1 loading and 1 unloading stop
• The train loads till full and unloads till empty

Even then, it 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.
• Are not overloaded

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.
• Related research (braking force, stack inserter capacity) is lacking (should be at maximum)

If you believe 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

To reduce the level of abstraction and provide numerical results, this section at times relies on the assumptions made in the "Ore Transport" example above. 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 would be some distinctive but non-essential blueprintable structure, e.g. a "+" made out of walls, etc.
  • Blueprint two identical markers a known distance apart; tile the blueprint by aligning the "starting" marker copy of the current iteration with the "end" copy of the previous iteration.
  • 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 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
    • inserter stack size bonus is researched to maximum
    • there is no slot limiting in the wagon (via the red X symbol or due to slots being filter-reserved for something else)
    • 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.
  • Note that if item stack size is less than inserter stack size (i.e., <12, which applies to items that stack to 1, 5, and 10), this formula ceases to be applicable; instead, the time is uniformly T = 40 / (12 * 2.31) =~ 1.44 s, which is the minimum possible time to load a cargo wagon full.
    • The numbers represent: 40 - number of stacks a wagon can take; 12 - number of inserters that can be placed around a wagon; 2.31 - number of stack inserter arm cycles per second for chest-to-chest loading.
    • Note that for items that do not stack (i.e., stack to 1; this includes e.g. nuclear fuel and artillery shells), it does not matter whether a stack or non-stack (fast) inserter is used, as when item stack size is less than inserter stack size, it is the item stack size that is moved, and stack and fast inserters (as well as both their filter versions) have the same movement speed.
• 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.