Official Factorio Wiki - User contributions [en]

Raw fish

2021-03-04T07:35:07Z

Misacek01: added minor bits of information

{{Languages}}
{{:Infobox:Raw fish}}<div style="overflow: hidden">
'''Raw fish''' can be harvested from [[water]]. They can be used to refill a small amount of health instantly. In order to catch raw fish, mine one of the dark spots that can be found moving around in water bodies. Each dark spot yields 5 fish when mined. Fish can be also collected via construction robots, by marking a water area that contains fish with a [[deconstruction planner]].

Raw fish is used to heal by clicking on the character or anywhere else in the world with the fish in the cursor. They heal 80 HP each and have a short cooldown for reuse, limiting the amount of incoming DPS that fish healing can absorb. Using a fish produces a munching sound.

Using [[landfill]] on water where a fish is swimming will "destroy" the fish. Fish can be shot and killed via [[pistol]] or [[submachine gun]], and also by explosions, but are immune to any kind of [[shotgun]] fire. Shooting fish does not grant any fish items.

Fish are created in water when the world is generated and do not despawn or respawn.

Fish can also be obtained by launching a rocket from a [[rocket silo]] equipped with a [[space science pack]]. One science pack is converted to one fish, however one rocket can at most return one stack of raw fish. This means that launching more than 100 space science packs will return only 100 fish and waste all extra science packs.

== Achievements ==
{{Achievement|so-long-and-thanks-for-all-the-fish}}</div>

== Gallery ==
<gallery widths=250px heights=200px>
File:Inserter fishing.gif|[[Inserters]] can catch fish.
</gallery>

== Trivia ==
* The fish item icon is meant to represent a [[Wikipedia:en:European perch|European perch]], a freshwater fish widespread in Europe and elsewhere. This was chosen because a perch is the favorite plushie of the artist's daughter, see the [https://www.reddit.com/r/factorio/comments/gom295/friday_facts_348_the_final_gui_update/frgl1go/ Reddit comment by V453000]

== History ==

{{history|1.0.0|
* Launching a rocket with space science packs inside now returns fish (not documented)}}

{{history|0.17.77|
* Inserters can now catch fish (not documented)}}

{{history|0.15.0|
* Fish can be collected by robots
* Amount of fish collected at once increased from 1 to 5
* Amount of health restored by fish increased from 20 to 80}}

{{history|0.6.0|
* New fish graphics}}

{{history|0.1.0|
* Introduced}}

{{IntermediateNav}}
{{C|Resources}}

Artillery turret

2021-03-01T01:44:35Z

Misacek01: /* Limitations */

{{Languages}}{{:Infobox:Artillery turret}}
The '''artillery turret''' is a super-long-range static defense structure added in game version 0.16. It fires [[Artillery shell|artillery shells]], relatively slow-moving projectiles that explore chunks of terrain they travel across. The turret has both automatic and manual (even longer-ranged) firing modes. Projectiles have sufficient damage to destroy spawners and any type of worm with a single hit, and have a modest area of effect. Infinitely-stacking research upgrades are available for range and firing speed, but not damage.

The [[Artillery wagon|artillery wagon]] is essentially the same weapon, only mounted on a train car and therefore mobile.

== Mechanics ==
Artillery turrets have a massive range, outranging other fixed fortifications by a factor of 10 or more. There are no special limits on how many may be built or where and, being ammunition-based, these turrets do not require electric power to operate.

In automatic mode, they function much the same as other turrets, automatically scanning for valid targets within range and firing on them. Automatic mode can only target [[Military units and structures|enemy structures]] (spawners and worms), not mobile units (biters and spitters); shells do, however, damage mobile units in the vicinity of impact normally.

In manual mode, an [[artillery targeting remote]] is used to point-and-click anywhere in the world, map, or zoomed-in map; each click corresponds to one shell delivered to that location, so long as any working artillery turrets and / or wagons are in range. Targeting remotes show the number of fire-ready (loaded and, for wagons, stationary) artillery pieces in range of cursor position when held. Manual fire can be ordered on unexplored areas; shells will explore all chunks they travel across (but no surrounding chunks).

Range in automatic mode is 224 tiles (7 chunks); in manual mode, 560 tiles (17.5 chunks). Infinite [[Artillery shell range (research)|research]] is available to increase range, at +30% of base range per level, applied to both automatic and manual range.

== Limitations ==
Aside from the considerable expense of research and assembly for both turrets and shells, there are certain considerations that make a base defense based purely on these turrets unwise, despite their phenomenal range.

Artillery shelling will antagonize enemy mobile units in the vicinity of the impact into rushing the turret emplacement, regardless of their normal "aggro radius". Artillery turrets are relatively slow-firing, although infinite [[Artillery shell shooting speed (research)|research]] is available to improve firing speed, at +100% per level, affecting both stationary turrets and wagons and applying to both automatic and manual mode. They also cannot target mobile units in automatic mode. Importantly, artillery has a ''minimum'' range as well, which is 32 tiles.

Together, these limitations mean that an artillery turret needs to be defended by other means. Any conventional approach such as walls, gun, laser, and / or flamethrower turrets, or the personal intervention of the player will do. However, players should keep in mind that extensive shelling of large biter-infested areas will produce massive attack waves centered on the position of the artillery piece at time of firing, and should plan close-range defenses accordingly.

Logistic considerations are also important, as artillery shells have a stack size of 1, meaning any-size container can only hold a modest supply and an inserter will only ever move a single shell at a time. Players may wish to consider on-site assembly for permanent and semi-permanent emplacements. The turret itself can hold 15 shells, and the wagon version can hold a full 100, providing a buffer of some size when continuous supply is not available.

== Gallery ==
<gallery widths=236px heights=162px>
File:artillery_turret_firing_anim.gif|Animation of the turret seeking a target, then firing.
</gallery>

== History ==

{{history|0.16.0|
* Introduced}}

== See also ==
* [[Artillery wagon]]
* [[Artillery shell]]
* [[Artillery targeting remote]]

{{CombatNav}}
{{C|Defense}}

Enemies

2020-08-08T15:58:08Z

Misacek01: /* Advanced: Evolution factor components and computation */ minor grammar edits

{{Languages}}
[[File:biter_intro.png|175px|right]]'''Enemies''' (also commonly called '''biters''') are creatures that want to harm the [[player]]. They are the native inhabitants of the extraterrestrial world in the form of arthropods living in organic nests, coexisting with each other peacefully. They are encountered in three species: Biters, spitters and worms. The species are further distinguished in four stages of growth, and thus strength. Enemies and nests show up on the map as red dots. Much like the player, enemies can slowly regain lost health.

== Achievements ==
Enemies are directly connected to the following achievements:
{{Achievement|it-stinks-and-they-dont-like-it}}
{{Achievement|steamrolled}}

==Creatures==
===Biters===
Biters are one of two main antagonists in the game. They come in four sizes: small, medium, big and behemoth. In the beginning of a game, there will only be the small ones. With increasing [[pollution]], they will become bigger, related to the enemy's [[#Evolution|evolution]]. As common sense may suggest, their method of attack is a straightforward charge to "bite" things.

{| class="wikitable"
|-
! Picture !! Name !! Info
|-
| [[File:small_biter.png|center]] || Small Biter
| Weakest of biters, can be easily killed with a pistol.
* Health: 15
* Damage: 7 Physical
* Attack speed: 1.71/s
* Speed: 43.2km/h
* Range: 1
* Pollution to join attack: 4
|-
| [[File:medium_biter.png|center]] || Medium Biter
| Stronger and slightly faster than the small biter. Can pose a problem for and even kill weaker players.
* Health: 75
* Damage: 15 Physical
* Attack speed: 1.71/s
* Speed: 51.8km/h
* Range: 1
* Pollution to join attack: 20

[[Damage#Resistance|Resistances]]:
*Explosion: 0/10%
*Physical: 4/10%
|-
| [[File:big_biter.png|center]] || Big Biter
| Dangerous, resistant to small arms. Can attack through walls, hitting objects directly behind them.
* Health: 375
* Damage: 30 Physical
* Attack speed: 1.71/s
* Speed: 49.7km/h
* Range: 2
* Pollution to join attack: 80

Resistances:
*Explosion: 0/10%
*Physical: 8/10%
|-
| [[File:behemoth_biter.png|center]] || Behemoth Biter
| Extremely durable and nearly immune to small arms, except for the strongest ordnance. Can attack through walls, hitting objects directly behind them.
* Health: 3000
* Damage: 90 Physical
* Attack speed: 1.2/s
* Speed: 64.8km/h
* Range: 2
* Pollution to join attack: 400

Resistances:
*Explosion: 12/10%
*Physical: 12/10%

|}

===Spitters===
'''Spitters''' are much like [[Enemies#Biters|biters]] and only appear slightly later on in the game as the evolution factor increases. Their main difference from biters is their ranged attack. Using predictive aiming, they spit a stream of acid at enemies which leaves behind a puddle of acid where it hits the ground. Due to the spitters' predictive aiming, the acid stream can be dodged by suddenly changing walking directions or standing still.[https://factorio.com/blog/post/fff-279] Both the stream and the puddle of acid deal damage of time and slow down players and vehicles. Most entities of the game have a much lower resistance to acid than other damage types (including [[turret]]s and [[armor]]), so spitters are effectively more potent against the player and his factories. Their behaviour and size classification are the same as with biters, but their health is universally lower and they are resistant exclusively against explosives, with no physical resistance.

{| class="wikitable"
|-
! Picture !! Name !! Info
|-
| [[File:small_spitter.png|center]] || Small Spitter
| Weakest of spitters. Easy to kill with any weapon, but attacks at range.
* Health: 10
* Range: 13
* Pollution to join attack: 4
* Speed: 40.0km/h

Acid projectile:
* Area of effect size: 1
* Damage (on contact): 12 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 7.2 Acid/second
* Applies effect (on contact):
** Movement/vehicle speed modifier: 60%
** Duration: 2 seconds

|-
| [[File:medium_spitter.png|center]] || Medium Spitter
| Stronger and slower than the smaller version. Can pose a problem for and even kill weaker players.
* Health: 50
* Range: 14
* Pollution to join attack: 12
* Speed: 35.6km/h

Acid projectile:
* Area of effect size: 1.25
* Damage (on contact): 24 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 28.8 Acid/second
* Applies effect (on contact):
** Movement/vehicle speed modifier: 50%
** Duration: 2 seconds

Resistances:
*Explosion: 0/10%
|-
| [[File:big_spitter.png|center]] || Big Spitter
| An even bulkier spitter and so can take more damage.
* Health: 200
* Range: 15
* Pollution to join attack: 30
* Speed: 32.4km/h

Acid projectile:
* Area of effect size: 1.35
* Damage (on contact): 36 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 130 Acid/second
* Applies effect (on contact):
** Movement/vehicle speed modifier: 40%
** Duration: 2 seconds

Resistances:
*Explosion: 0/15%
|-
| [[File:behemoth_spitter.png|center]] || Behemoth Spitter
| The bulkiest of the spitters and so can take even more damage.
* Health: 1500
* Range: 16
* Pollution to join attack: 200
* Speed: 32.4km/h

Acid projectile:
* Area of effect size: 1.75
* Damage (on contact): 60 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 360 Acid/second
* Applies effect (on contact):
** Movement/vehicle speed modifier: 30%
** Duration: 2 seconds

Resistances:
*Explosion: 0/30%
|}

===Worms===

The Worms are natural allies of biters and spitters and will attack the player if they get close enough with an attack similar to spitters'. They act like static [[turret]]s and will not follow attackers. They rely on high damage, great range and splash damage to keep the player away from the worms and the nests they protect, but either one of these advantages can be overcome. Unlike other enemies, they are also highly resistant to fire. They will spit acid at the player, which can also leave acidic puddles on the ground that can still damage players and vehicles, as well as slow them both down and leave a brief acidic, damaging effect for a few seconds. However, placed buildings and tiles are unaffected by the acid puddles, but still take damage normally by the acid projectile.

Worms come in 4 sizes, their power increasing with size. Like biters and spitters, behemoth, big and medium worms spawning is influenced by the evolution factor. Worms are only created during enemy expansion when a certain evolution factor requirement is fulfilled. This is 0.3 for the medium worm, 0.5 for the big worm and 0.9 for the behemoth worm. Below these evolution factors, worms can only be created by the map generation. In map generation, the game restricts higher tier worms behind the distance from the starting point. The further away the player goes from the starting area, the stronger the worms become.

{| class="wikitable"
|-
! Picture !! Name !! Info
|-
| [[File:Small worm.png|center]] || Small Worm
| A weak worm. It is still capable of killing the player unless it is targeted as priority.
* Health: 200
* Range: 25

Acid projectile:
* Area of effect size: 1.4
* Damage (on contact): 36 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 21.6 Acid/second
* Applies effect (on contact):
** Duration: 2 seconds
** Movement/vehicle speed modifier: 60%
|-
| [[File:Medium worm.png|center]] || Medium Worm
| Medium worms are dangerous to even more advanced players. They should be handled with care.
* Health: 400
* Range: 30

Acid projectile:
* Area of effect size: 1.55
* Damage (on contact): 48 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 57.6 Acid/second
* Applies effect (on contact):
** Duration: 2 seconds
** Movement/vehicle speed modifier: 50%

Resistances:
*Explosion: 5/15%
*Fire: 2/50%
*Physical: 5/0%
|-
| [[File:Big worm.png|center]] || Big Worm
| Big worms are not as much more dangerous as resilient. They are almost immune to common gunfire of any sort.
* Health: 750
* Range: 38

Acid projectile:
* Area of effect size: 1.75
* Damage (on contact): 72 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 259 Acid/second
* Applies effect (on contact):
** Duration: 2 seconds
** Movement/vehicle speed modifier: 40%

Resistances:
*Explosion: 10/30%
*Fire: 3/70%
*Physical: 10/0%
|-
| [[File:Behemoth worm.png|center]] || Behemoth Worm
| Behemoth worms are the most dangerous of worms. They are just as resilient as Big worms, with much greater range.
* Health: 750
* Range: 48

Acid projectile:
* Area of effect size: 2
* Damage (on contact): 96 Acid

Acid puddle:
* Lifetime: 32 seconds
* Damage: 691 Acid/second
* Applies effect (on contact):
** Duration: 2 seconds
** Movement/vehicle speed modifier: 30%

Resistances:
*Acid: 0/100%
*Explosion: 10/30%
*Fire: 3/70%
*Physical: 10/0%
|}

{| class="wikitable"
|-
! Picture !! Description
|-
| [[File:worm.gif]] || A worm's attack animation.
|-
|}

==Nests==

The spawn points of biters and spitters. While nests themselves are generally defenseless, the enemies they release over time effectively serve as a form of guards to distract the player and any nearby turrets, and are often accompanied by worms. Nests exposed to pollution will use it to send enemies to join attacks. Enemies not engaged in combat may seek out the nearest nest for protection.

The nests are highly resistant to fire and otherwise generally more resilient than a medium worm.

{| class="wikitable"
|-
! Picture !! Name !! Description
|-
| [[File:biter_nest.png]] || Biter's nest
|
* Health: 350

Resistances:
*Explosion: 5/15%
*Fire: 3/60%
*Physical: 2/15%
|-
| [[File:spitter_nest.png]] || Spitter's nest
|
* Health: 350

Resistances:
*Explosion: 5/15%
*Fire: 3/60%
*Physical: 2/15%
|}

=== Expansions ===
Every 4-60 minutes, a group of 5-20 biters/spitters will leave their base to create a new base which will consist of as many worms/nests as there are members in the group. This group will search for a suitable spot that's 3-7 chunks away from existing bases. The interval between enemy expansions is global, and the higher enemy evolution, the shorter the interval is on average. Furthermore, with higher evolution, the groups are bigger on average.

Once they have found a suitable spot, each biter/spitter in the group dies and forms a new nest or worm. There is a delay between each member sacrificing itself for to create a worm/nest, so creating the new base from the expansion group can take quite a long time, depending on the group size. Medium worms are only formed if the current evolution is higher than 0.3, big worms only if the current evolution is higher than 0.5 and behemoth worms are only formed if current evolution is higher than 0.9. The game randomly chooses whether to form a new biter nest, spitter nest, small worm, or bigger worm if the evolution factor is high enough. [https://gist.github.com/Bilka2/aa88490c23124a6f214c02c73a368aa7]

==Defense==
Nests spawn biters and spitters "for free". However, biters and spitters will only aggressively engage the player's factory if the pollution cloud of the factory reaches a nest because pollution is consumed to send biters or spitters to join the next attack. Every 1 to 10 minutes (random) the mustered biters launch an attack. If not all biters have arrived at the rendezvous point by that time, they will wait up to an additional 2 minutes for stragglers. The attack then proceeds to their target over the shortest path possible, accounting for terrain, but not for player entities that could pose an obstacle (like [[wall]]s).

If there is a clear path somewhere around those obstacles, the biters will attempt to go around. If there is no clear passage or a clear passage would mean deviating too far from the original course, the biters will attack whatever is in their way to go through. This can be exploited to an extent; creating mazes at regular intervals along a barrier can direct the biters through a gauntlet not dissimilar to tower defense.

However, if a biter comes in proximity of a [[Military units and structures|military unit or structure]], it will prioritize these and attempt to immediately attack them instead, again trying to reach the new target over the shortest possible path with no too great detours, if possible.

==Evolution==
[[File:Evolution Biters.png|thumb|right|400px|Spawn chances of biters from biter spawners by evolution factor.]]
[[File:Evolution Spitters.png|thumb|right|400px|Spawn chances of spitters from spitter spawners by evolution factor.]]
[[File:Evolution Weights.png|thumb|right|400px|Weight graph of both spawners by evolution factor. The values shown are primarily for indicating when certain types start and stop spawning, for actual chances refer to the tables or other charts.]]
The evolution factor is a global variable that determines what kind of biters will be spawned. You can check the variable in the dev console via the following command (does not disable achievements):

/evolution

The evolution factor goes from 0 (not evolved at all) to 1 (maximal evolution). At the moment the evolution factor can only increase.

Besides choosing what kind of biter will be spawned, the evolution factor also influences the spawning interval. This interval (<code>spawning_cooldown</code> in the <code>enemy-spawner</code> definition) is interpolated between 360 (0 evolution) and 150 (1 evolution) game ticks (= 6 to 2.5 seconds).

=== Methods of increasing ===

The evolution factor is increased by three kinds of events:

* The passage of time very slightly increases the evolution factor.
* The global [[Pollution|pollution production]] increases the evolution factor.
* Destroying [[Enemies#Nests|nests]] significantly increases the evolution factor.

All these values are set in <code>game.map_settings.enemy_evolution</code>. From there they can be changed or modded.

The default settings are:

{| class="wikitable"
!Source per
!Variable in <code>enemy_evolution</code>
!Percent increase
|-
| [[Time#Seconds|Second]] || <code>time_factor</code> || 0.0004%
|-
| 1 Pollution unit || <code>pollution_factor</code> || 0.00009%
|-
| Destroyed enemy spawner || <code>destroy_factor</code> || 0.2%
|}

Pollution production is the total pollution produced by [[Pollution#Polluters|buildings]] per tick, not the pollution spreading on the map, so it is not reduced by trees or other absorbers.
e.g. : 10 boilers produce 300 pollution in one minute, raising the evolution factor by around 0.027%.

The percentages are applied on the base of <code>1 - current_evolution_factor</code>. So for instance destroying enemy spawners in the beginning of the game results in increase of evolution factor by 0.005 (half a percent) while doing this when the evolution factor is 0.5 the increase is only 0.0025 (quarter a percent).

This also means that the evolution factor approaches 1 asymptotically - generally, increases past 0.9 or so are ''very'' slow and the number never actually reaches 1.0.

=== Spawn chances by evolution factor ===

The probability charts show the chances of each type of biter/spitter for each spawner at all evolution levels.

<div id="evoChecker"></div>

=== Advanced: Evolution factor components and computation ===
<div class="toccolours mw-collapsible mw-collapsed" style="width:calc(100%-400px); overflow:auto;">
This section has charts plotting the individual evolution factor components and discusses possibilities for manually estimating the evolution factor.
<div class="mw-collapsible-content">

[[File:Evolution_factor_by_time.png|400px|thumb|right|1. Single-component evolution factor increase with time]]
[[File:Evolution_factor_by_pollution.png|400px|thumb|right|2. Single-component evolution factor increase with pollution]]
[[File:Evolution_factor_by_spawners.png|400px|thumb|right|3. Single-component evolution factor increase with destroyed spawners]]

'''Notes'''

* Data from version 0.16.51.

* All charts end at approximately an evolution factor of 0.99.

*To simplify calculation, the time and pollution charts are calculated using steps of 1,000 seconds / 1,000,000 pollution units - in both cases 1,000 times larger than the unit the game uses for the calculation. Because of the recursive nature of the calculation, this makes the values in the charts somewhat '''higher''' than those the game would obtain in the same calculation; however, the difference is fairly minimal (less than 1 percentage point). The spawners chart is calculated 1-to-1 and therefore accurate.

*While time passed is shown on save files and spawners destroyed can be retrieved from player statistics, the game does not currently report the total pollution released by the player. Also, none of the well-known Factorio calculators show pollution generated by a particular factory. Therefore, to make use of the pollution chart the player's pollution output would need to be manually estimated.

*Given that the game reports the actual evolution factor (console: <code>/evolution</code>) whenever the player wishes, these charts are intended primarily to help estimate the impact of planned base expansions and similar activities on the evolution factor's future development.

'''Comments'''

These charts (click to enlarge) represent the situation where each evolution factor component (time, pollution, destroyed spawners) is the ''only'' component contributing to the evolution factor in that entire game. They are therefore '''not realistic''', as in a typical game all three components will contribute, some at varying times and intensities.

Because of how contributions to the evolution factor (hereinafter, EF) are calculated (multiplied by <code>(1 - current EF)</code>), it is '''not''' possible to simply add the values indicated by these charts for a game's time passed, pollution generated, and / or spawners destroyed so far to retrieve the total evolution factor.

For example, if 20 hours have passed (single-component EF =~ 0.25), 10 million pollution units were released (single-component EF =~ 0.15), and 200 spawners were destroyed (single-component EF =~ 0.35), the actual evolution factor will '''not''' be (0.25 + 0.15 + 0.35 =) ~0.85.

However, the evolution factor will always be '''less''' than the sum of all individual components as indicated by these charts, and '''at least''' as high as the highest individual component. Thus, using the values from above, the EF will be ''at least'' 0.35 and ''less than'' 0.85. A smarter approach is required to compute the amount of pollution released.

'''Computation of actual evolution factor'''

The actual EF can be computed as follow :

<code> 1 - EF = (1 - E[t]) * (1 - E[p]) * (1 - E[s])</code>, where ''E[t]'', ''E[p]'', and ''E[s]'' are the single-component values from the pollution, time, and spawner charts, in that order.

A key observation in understanding where this formula comes from is that each incremental change of the evolution factor is effectively a multiplication of <code>1 - EF</code> by a constant (depending on the nature of the change). For example, another way of saying that killing a biter nest augments evolution by 0.2% of <code>1 - EF</code>, is to say that killing a biter nest multiplies <code>1 - EF</code> by 0.998.

So, like multiplication, evolution is, barring rounding errors, associative and commutative. The commutativity means that the order in which you take evolution-increasing actions does not matter, and along with the associativity results in the formula above.

That knowledge can also be applied to compute the above charts exactly, or to compute a component of evolution without having to refer to the chart at all. For example, pollution as a function of time only is <code>1 - 0.999996 ^ t</code> where t is the time in seconds.

For the values from above, we can deduce the evolution factor <code>1 - EF = (1 - 0.25) * (1 - 0.15) * (1 - 0.35) = 0.75 * 0.85 * 0.35 = 0.41</code>, which gives an evolution factor of <code>0.59</code>.

This formula can also be used to estimate impact of future player activities on the EF: a set of actions that is known to bring the evolution factor of a world from 0 to EF(2) (eg using the above chart and formula) will bring it from EF(1) to <code>1 - (1-EF(1)) * (1-EF(2))</code>

For example, if the player planned to spend the next 20 hours building up their base, releasing 10 million pollution and destroying 200 spawners in the meantime (i.e., the same numbers as in the example above), and the EF at the start of this period were, say, 0.55, then the estimated EF at its end will be <code>1 - (1 - 0.55) * (1 - 0.59) = 0.81</code>.
</div></div>

== Gallery ==
<gallery widths=270px heights=140px>
File:player_near_enemy_nests.png|The player near some enemy nests and worms.
File:player_worms_acid.png|The player among acid puddles created by attacking worms.
File:player_attacked_by_biters.png|Both the player and some buildings getting attacked by biters.
File:enemy_nests_mapgen.png|Enemy nests seen in a map generation preview (deathworld setting).
File:turret_wall_biters.png|Line of gun turrets defending against biters.
</gallery>

== History ==
{{history|0.17.0|
* Behemoth worm added.}}

{{history|0.15.0|
* Increased the damage, range, and health of worms.
* Decreased health and resist of Behemoth biters.}}

{{history|0.13.10|
* Biters and other units won't become aggressive as a result of friendly-fire.}}

{{history|0.13.0|
* Big and behemoth enemies now spawn 50% slower.}}

{{history|0.12.26|
* Running biters over with a vehicle will now anger them in peaceful mode.}}

{{history|0.12.0|
* Updated sounds for enemies.}}

{{history|0.11.17|
* Items dropped by enemies([[alien artifact|*]]) are now collected automatically and from longer distances.}}

{{history|0.11.6|
* Range of spitters is now 15, less than turrets.}}

{{history|0.11.0|
* Spitters added.
* Drawing of enemies optimised, so adding new colors does not impact VRAM.
* Blood splashes on death are now procedural.}}

{{history|0.9.0|
* Turrets no longer search for enemies when none are near.
* Biters can no longer destroy the shipwreck in the 3rd new hope campaign.}}

{{history|0.8.1|
* Further improvement to enemy AI.}}

{{history|0.8.0|
* Decreased the range of medium worm from 25 to 20.}}

{{history|0.7.2|
* Biter AI improved.}}

{{history|0.7.1|
* Peaceful mode added for freeplay.}}

{{history|0.7.0|
* Enemy creepers were replaced by small, medium and big biters.
* Enemy turrets were replaced by small, medium and big shooting worms.
* Enemies move and attack in groups.
* Enemies wander around their base when they have nothing to do.
* Enemies call for help when attacked.
* Enemies can create new bases.
* Enemies can now destroy all player creations they find.}}

{{history|0.1.0|
* Introduced, called 'creepers'}}

== See also ==
* [[Damage]]
* [[Pollution]]

Lab

2019-07-05T22:15:33Z

Misacek01: /* Production requirements */ typo

{{Languages}}
{{:Infobox:Lab}}
[[File:Simplescience.png|thumb|right|Science packs put into the front lab will be passed to labs behind it.]]
'''Labs''' are buildings that perform [[research]] for [[technologies]] by consuming [[science pack]]s. Use of a lab is required to progress in Factorio.

When [[productivity module]]s are used in labs, the productivity bonus is directly calculated and applied each [[game-tick|tick]] so the productivity bar is simply cosmetic. This means that it does not matter that the productivity bar resets when the research is changed, no productivity bonus is lost. [https://forums.factorio.com/26860]

The player can only research one technology at a time, but can use multiple labs for faster results. The speed bonus of labs when [[lab research speed (research)|lab research speed]] is researched and modules are present can be calculated using this formula: <code>research_bonus × module_bonus = speed_bonus</code>; the percentage bonuses have to be converted to decimals (e.g. +140% = 2.4) before the formula is used.

==Production requirements==
Calculating the number of science packs needed per second is straightforward:
* <code>ERS = (1 + B[r] ÷ 100) × (1 + M[r] ÷ 100)</code>
* <code>ACT = T[r] ÷ ERS</code>
* <code>PPS = N ÷ ACT</code>

Where:
*'''''ERS''''' is "effective lab research speed"
*'''''B[r]''''' is the Lab Research Speed bonus as reported by the game, in percent
*'''''M[r]''''' is the sum of all module speed effects (Speed modules - positive; Productivity modules - negative), in percent
*'''''ACT''''' is "adjusted cycle time"
*'''''T[r]''''' is the research cycle time as displayed in the research screen
*'''''PPS''''' is "packs per second"
*'''''N''''' is the number of labs available.

Thus, for a 10-lab setup, researching Nuclear Power (30 second cycle time) with Lab Research Speed 4 (140% bonus) and no module effects, the calculation is:
*<code>ELRS = 1 + (140 ÷ 100) = 2.4</code>
*<code>ACT = 30 ÷ 2.4 = 12.5 s</code>
*<code>PPS = 10 ÷ 12.5 = 0.8</code>

This means 0.8 science packs per second, of each type, would need to be produced to continuously supply the labs.

=== Equation simplification ===
Assuming all labs have the same ''B[r]'' (which they always will unless they are affected by different module configurations), the above calculations can be combined into one equation:

* <code>PPS = N × (1 + [B[r] ÷ 100]) × (1 + [M[r] ÷ 100) ÷ T[r]</code>

Thus for the numerical example:
* <code>PPS = 10 × (1 + [140 ÷ 100]) × 1 ÷ 30</code> = <code>(10 ÷ 30) × (1 + 1.4)</code> = <code> (1 ÷ 3) × 2.4</code> = <code> 2.4 ÷ 3</code> = <code>0.8</code> packs per second

== History ==

{{history|0.12.6|
* The research speed of a lab is now not dependent on its electricity consumption, and can be scripted.}}

{{history|0.12.0|
* Lab research is now continuous; Science packs now have progress bars.}}

{{history|0.9.2|
* Labs are now named after early access backers when built from [[blueprint]]s.}}

{{history|0.7.2|
* Changed the recipe of Lab to require 4 transport belts, down from 5.}}

{{history|0.6.0|
* New graphics.}}

{{history|0.2.7|
* Contents of the Lab is now shown in the entity info. }}

{{history|0.1.0|
* Introduced }}

==See also==
* [[Electric system]]
* [[Crafting]]

{{ProductionNav}}
{{C|Producers}}

Research

2019-07-05T22:12:30Z

Misacek01: /* Mechanics */ Math error + minor clarifications

{{Languages}}
[[File:Technology_Screen.png|400px|thumb|The technology screen]]
'''Research''' is used to unlock [[technologies]], offering new recipes and bonuses. Research is performed by [[lab|labs]] consuming different types of [[science pack|science packs]].

== Mechanics ==

In singleplayer games, only one technology can be researched at a time, the same is true for every [[Multiplayer#PvP|force]] (team of players) in a multiplayer game. In multiplayer games with multiple forces, each force has its own technology tree and research status, so different forces can research independently in [[Multiplayer#PvP|PvP]] games.

The technology to be researched is selected from the technology screen, opened by pressing {{Keybinding|T}}. The currently active research can be changed at any time from the technology screen; if another research is in progress, that progress will be saved. Multiple technologies can be partially researched like this at any one time.

Research progress for a technology is divided into ''units''. Each unit has a time and a science pack cost. When research is in progress, labs with the required amount of science packs for one unit will consume the amount and contribute towards research progress.

[[File:res.png|frame|The progress bar shown in the top right corner of the screen when research is in progress]]

The time ''T'' it will take to research a particular technology is given by:

*<code>T = (T[0] × P) ÷ (L × S)</code> seconds,

where:
*'''''T[0]''''' is the time cost per unit (as shown in Research screen)
*'''''P''''' is the price of the research, in units (as shown in Research screen)
*'''''L''''' is the number of labs used
*'''''S''''' is lab speed, which is given by:
**<code>(1 + B[r]) × (1 + M[r])</code>, where
**'''''B[r]''''' is the total research speed modifier from [[Lab research speed (research)|lab research speed]] research, expressed as a decimal (% value divided by 100); and
**'''''M[r]''''' is the sum of all module effects (Speed modules with <code>+</code> sign, Productivity modules with <code>-</code> sign), expressed as a decimal

''Note that ''P'' represents the research price '''in units''', not in individual science packs summed across all their types. For example, a research that costs 100 [[automation science pack]]s and 100 [[logistic science pack]]s, grouped into 100 units of 1 each of automation and logistic science packs, would have a ''P'' of 100, ''not'' 200.''

Unlike most bonus effects, the lab research speed bonus gained from research is ''multiplicative'' with module speed effects, not additive. However, different module effects (Speed vs. Productivity, beacon vs. in-lab) are additive with each other.

=== Automation ===
[[File:5_5_Labs_R_G_packs.png|400px|thumb|right|A simple lab setup using [[automation science pack]]s and [[logistic science pack]]s, [[belt transport system|belts]], and [[inserters]]]]

Crafting science packs by hand is not feasible, mainly because of the amount of resources and time needed to craft them. Some science packs also require ingredients that cannot be handcrafted, such as [[oil processing|oil products]]. Science pack production automation is the primary incentive for factory development throughout the game.

The insertion of science packs into labs may be automated using [[inserters]] and [[transport belt]]s, as shown to the right, or using [[Robotic network#Robots|robots]] and the [[logistic network]].

Note that inserters can take science packs from labs and hand them to other labs, making a lab chain a feasible solution. Other options include using 3 belts (before space science packs are needed), or a [[Glossary#S|sushi belt]].

=== Research queue ===
[[File:Research_Screen_Queue.png|400px|thumb|right|The technology screen with some technologies queued.]]
The research queue allows players to automatically research more technologies after a research finishes. The research queue is by default unlocked when the first rocket is launched. Alternatively it can be unlocked in the map generation settings in the 'advanced' category, or via [[Console#Enable_Research_Queue|console commands]] (note that this disables achievements for the save).

Once the research queue is enabled, a technology can be added to the queue by pressing the "Start Research" button.

Technologies in the queue are displayed in the upper left corner of the interface. If a technology is added to the queue, the technologies that depend on it may become available to be added to the queue as well and those technologies are displayed in orange. For example adding the [[Logistics_(research)|logistics]] and [[Logistic_science_pack_(research)|logistic science pack]] technologies to the queue allows the technology [[Logistics_2_(research)|logistics 2]] to be queued.

To remove a technology from the queue, the technology's image must be hovered in the queue display in the upper left corner and the red button that appears must be pressed.

== Achievements ==

{{Achievement|Tech-maniac}}
* Completing infinite technologies of any level is not required for '''Tech maniac'''. All non-infinite levels of technologies that have infinite continuations are still required.

== History ==
{{History|0.17.0|
* Research UI overhauled.
* Research Queue added.}}

{{History|0.15.0|
* Research system overhauled
** There are now 7 science pack types instead of 4, research prices have been changed to compensate.
** Top-tier science pack is no longer obtained by destroying alien nests, but by launching rockets with satellites.
**"Infinite research" mechanic introduced.}}

== See also ==
* [[Technologies]]
* [[Science pack]]

[[Category: Technology]]
{{TechNav}}

Lab

2019-07-05T22:08:46Z

Misacek01: /* Production requirements */ Changed equations to reflect that module and research lab speed changes are multiplicative, not additive. Example calculation doesn't use modules; is unaffected.

{{Languages}}
{{:Infobox:Lab}}
[[File:Simplescience.png|thumb|right|Science packs put into the front lab will be passed to labs behind it.]]
'''Labs''' are buildings that perform [[research]] for [[technologies]] by consuming [[science pack]]s. Use of a lab is required to progress in Factorio.

When [[productivity module]]s are used in labs, the productivity bonus is directly calculated and applied each [[game-tick|tick]] so the productivity bar is simply cosmetic. This means that it does not matter that the productivity bar resets when the research is changed, no productivity bonus is lost. [https://forums.factorio.com/26860]

The player can only research one technology at a time, but can use multiple labs for faster results. The speed bonus of labs when [[lab research speed (research)|lab research speed]] is researched and modules are present can be calculated using this formula: <code>research_bonus × module_bonus = speed_bonus</code>; the percentage bonuses have to be converted to decimals (e.g. +140% = 2.4) before the formula is used.

==Production requirements==
Calculating the number of science packs needed per second is straightforward:
* <code>ERS = (1 + B[r] ÷ 100) × (1 + M[r] ÷ 100)</code>
* <code>ACT = T[r] ÷ ERS</code>
* <code>PPS = N ÷ ACT</code>

Where:
*'''''ERS''''' is "effective lab research speed"
*'''''B[r]''''' is the Lab Research Speed bonus as reported by the game, in percent
*'''''M[r]''''' is the sum of all module speed effects (Speed modules - positive; Productivity modules- negative), in percent
*'''''ACT''''' is "adjusted cycle time"
*'''''T[r]''''' is the research cycle time as displayed in the research screen
*'''''PPS''''' is "packs per second"
*'''''N''''' is the number of labs available.

Thus, for a 10-lab setup, researching Nuclear Power (30 second cycle time) with Lab Research Speed 4 (140% bonus) and no module effects, the calculation is:
*<code>ELRS = 1 + (140 ÷ 100) = 2.4</code>
*<code>ACT = 30 ÷ 2.4 = 12.5 s</code>
*<code>PPS = 10 ÷ 12.5 = 0.8</code>

This means 0.8 science packs per second, of each type, would need to be produced to continuously supply the labs.

=== Equation simplification ===
Assuming all labs have the same ''B[r]'' (which they always will unless they are affected by different module configurations), the above calculations can be combined into one equation:

* <code>PPS = N × (1 + [B[r] ÷ 100]) × (1 + [M[r] ÷ 100) ÷ T[r]</code>

Thus for the numerical example:
* <code>PPS = 10 × (1 + [140 ÷ 100]) × 1 ÷ 30</code> = <code>(10 ÷ 30) × (1 + 1.4)</code> = <code> (1 ÷ 3) × 2.4</code> = <code> 2.4 ÷ 3</code> = <code>0.8</code> packs per second

== History ==

{{history|0.12.6|
* The research speed of a lab is now not dependent on its electricity consumption, and can be scripted.}}

{{history|0.12.0|
* Lab research is now continuous; Science packs now have progress bars.}}

{{history|0.9.2|
* Labs are now named after early access backers when built from [[blueprint]]s.}}

{{history|0.7.2|
* Changed the recipe of Lab to require 4 transport belts, down from 5.}}

{{history|0.6.0|
* New graphics.}}

{{history|0.2.7|
* Contents of the Lab is now shown in the entity info. }}

{{history|0.1.0|
* Introduced }}

==See also==
* [[Electric system]]
* [[Crafting]]

{{ProductionNav}}
{{C|Producers}}

Research

2019-07-05T22:00:19Z

Misacek01: /* Mechanics */ Changed lab speed equation to reflect the fact that researched and module-based lab speed effects are multiplicative, not additive. Previous formulation gave bogus results.

{{Languages}}
[[File:Technology_Screen.png|400px|thumb|The technology screen]]
'''Research''' is used to unlock [[technologies]], offering new recipes and bonuses. Research is performed by [[lab|labs]] consuming different types of [[science pack|science packs]].

== Mechanics ==

In singleplayer games, only one technology can be researched at a time, the same is true for every [[Multiplayer#PvP|force]] (team of players) in a multiplayer game. In multiplayer games with multiple forces, each force has its own technology tree and research status, so different forces can research independently in [[Multiplayer#PvP|PvP]] games.

The technology to be researched is selected from the technology screen, opened by pressing {{Keybinding|T}}. The currently active research can be changed at any time from the technology screen; if another research is in progress, that progress will be saved. Multiple technologies can be partially researched like this at any one time.

Research progress for a technology is divided into ''units''. Each unit has a time and a science pack cost. When research is in progress, labs with the required amount of science packs for one unit will consume the amount and contribute towards research progress.

[[File:res.png|frame|The progress bar shown in the top right corner of the screen when research is in progress]]

The time ''T'' it will take to research a particular technology is given by:

*<code>T = (T[0] × P) ÷ (L × S)</code> seconds,

where:
*'''''T[0]''''' is the time cost per unit (as shown in Research screen)
*'''''P''''' is the price of the research, in units (as shown in Research screen)
*'''''L''''' is the number of labs used
*'''''S''''' is lab speed, which is given by:
**<code>(1 + B[r]) × M[r]</code>, where
**'''''B[r]''''' is the total research speed modifier from [[Lab research speed (research)|lab research speed]] research; and
**'''''M[r]''''' is the sum of all module effects (Speed modules with <code>+</code> sign, Productivity modules with <code>-</code> sign)

''Note that ''P'' represents the research price '''in units''', not in individual science packs summed across all their types. For example, a research that costs 100 [[automation science pack]]s and 100 [[logistic science pack]]s, grouped into 100 units of 1 each of automation and logistic science packs, would have a ''P'' of 100, ''not'' 200.''

Unlike most bonus effects, the lab research speed bonus gained from research is ''multiplicative'' with module speed effects, not additive. However, different module effects (Speed vs. Productivity, beacon vs. in-lab) are additive with each other.

=== Automation ===
[[File:5_5_Labs_R_G_packs.png|400px|thumb|right|A simple lab setup using [[automation science pack]]s and [[logistic science pack]]s, [[belt transport system|belts]], and [[inserters]]]]

Crafting science packs by hand is not feasible, mainly because of the amount of resources and time needed to craft them. Some science packs also require ingredients that cannot be handcrafted, such as [[oil processing|oil products]]. Science pack production automation is the primary incentive for factory development throughout the game.

The insertion of science packs into labs may be automated using [[inserters]] and [[transport belt]]s, as shown to the right, or using [[Robotic network#Robots|robots]] and the [[logistic network]].

Note that inserters can take science packs from labs and hand them to other labs, making a lab chain a feasible solution. Other options include using 3 belts (before space science packs are needed), or a [[Glossary#S|sushi belt]].

=== Research queue ===
[[File:Research_Screen_Queue.png|400px|thumb|right|The technology screen with some technologies queued.]]
The research queue allows players to automatically research more technologies after a research finishes. The research queue is by default unlocked when the first rocket is launched. Alternatively it can be unlocked in the map generation settings in the 'advanced' category, or via [[Console#Enable_Research_Queue|console commands]] (note that this disables achievements for the save).

Once the research queue is enabled, a technology can be added to the queue by pressing the "Start Research" button.

Technologies in the queue are displayed in the upper left corner of the interface. If a technology is added to the queue, the technologies that depend on it may become available to be added to the queue as well and those technologies are displayed in orange. For example adding the [[Logistics_(research)|logistics]] and [[Logistic_science_pack_(research)|logistic science pack]] technologies to the queue allows the technology [[Logistics_2_(research)|logistics 2]] to be queued.

To remove a technology from the queue, the technology's image must be hovered in the queue display in the upper left corner and the red button that appears must be pressed.

== Achievements ==

{{Achievement|Tech-maniac}}
* Completing infinite technologies of any level is not required for '''Tech maniac'''. All non-infinite levels of technologies that have infinite continuations are still required.

== History ==
{{History|0.17.0|
* Research UI overhauled.
* Research Queue added.}}

{{History|0.15.0|
* Research system overhauled
** There are now 7 science pack types instead of 4, research prices have been changed to compensate.
** Top-tier science pack is no longer obtained by destroying alien nests, but by launching rockets with satellites.
**"Infinite research" mechanic introduced.}}

== See also ==
* [[Technologies]]
* [[Science pack]]

[[Category: Technology]]
{{TechNav}}

Talk:Car

2019-03-07T18:41:15Z

Misacek01: Car seems faster in 0.17 -- can anyone test & update?

Are the materials outdated?

: of course. The stacks, too. [[User:Ssilk|Ssilk]] ([[User talk:Ssilk|talk]]) 00:23, 23 May 2014 (CEST)

== speed ==

any info on how fast it goes/how quick it accelerates on various fuels? [[User:Paulbrock|Paulbrock]] ([[User talk:Paulbrock|talk]]) 11:02, 22 May 2017 (UTC)

== Faster in 0.17 ==
Hi,

the car seems faster in 0.17 than it used to be. Tested with nuclear fuel on grass, gets up to 146.9 kph. (Which is more than the wiki currently lists.) Since nuke fuel speed and accel bonus is still listed at same magnitude (15% / 150%), I'm guessing the car's base max speed has been upped?

Can someone test more rigorously to update the tables?

Also, the car seems to handle better (turn quicker), and might have higher accel. (However, if default accel is calculated relative to max speed, then that may be simply due to the max speed increase.)

Unfortunately, its braking performance is still terrible, and with the new higher max speeds stopping without ramming something can be a problem. That's a bit off-topic though, since it's not a change. Still, here's hoping this gets buffed -- either directly or by making Braking force apply to all vehicles. (BTW the tank could use a brake buff too.)

[[User:Misacek01|Misacek01]] ([[User talk:Misacek01|talk]]) 18:41, 7 March 2019 (UTC)

Archive:Character logistic trash slots (research)

2019-03-07T18:25:59Z

Misacek01: added 0.17 changes: 3 new levels

{{Languages}}
{{:Infobox:Character logistic trash slots (research)}}

Allows the player to get rid of unneeded items from his inventory. These items are taken away by the logistic robots. Each level of research increases the character's logistic trash slots by 6.

==Levels==

{| class="wikitable"
! Technology !! Cost !! Effects !! Cumulative effect
|-
| {{icontech|character-logistic-trash-slots-research|1|Character logistic trash slots (research)}} Character logistic trash slots 1 || {{icon|time|30}}{{Icon|Automation science pack|1}}{{Icon|Logistic science pack|1}} ✖ <big>100</big> || +6 slots || 6
|-
| {{icontech|character-logistic-trash-slots-research|2|Character logistic trash slots (research)}} Character logistic trash slots 2 || {{icon|time|30}}{{Icon|Automation science pack|1}}{{Icon|Logistic science pack|1}}{{Icon|Chemical science pack|1}} ✖ <big>100</big> || +6 slots || 12
|-
| {{icontech|character-logistic-trash-slots-research|3|Character logistic trash slots (research)}} Character logistic trash slots 3 || {{icon|time|60}}{{Icon|Automation science pack|1}}{{Icon|Logistic science pack|1}}{{Icon|Chemical science pack|1}}{{Icon|Utility science pack|1}} ✖ <big>100</big> || +6 slots || 18
|-
| {{icontech|character-logistic-trash-slots-research|4|Character logistic trash slots (research)}} Character logistic trash slots 4 || {{icon|time|60}}{{Icon|Automation science pack|1}}{{Icon|Logistic science pack|1}}{{Icon|Chemical science pack|1}}{{Icon|Utility science pack|1}} ✖ <big>200</big> || +6 slots || 24
|-
| {{icontech|character-logistic-trash-slots-research|5|Character logistic trash slots (research)}} Character logistic trash slots 5 || {{icon|time|60}}{{Icon|Automation science pack|1}}{{Icon|Logistic science pack|1}}{{Icon|Chemical science pack|1}}{{Icon|Production science pack|1}}{{Icon|Utility science pack|1}} ✖ <big>500</big> || +6 slots || 30
|}

== History ==
{{History|0.17.0|
* Levels 3-5 added. Maximum number of trash slots is now 30 (up from 12).
}}

== See also ==
* [[Research]]
* [[Technologies]]

{{TechNav}}

Kovarex enrichment process

2019-02-28T21:15:08Z

Misacek01: /* History */ added that prod modules can now be used with enrichment // src: release notes at https://forums.factorio.com/viewtopic.php?f=3&t=65070

{{Languages}}
{{:Infobox:Kovarex enrichment process}}

The '''Kovarex enrichment process''' is a method for reprocessing uranium in a [[centrifuge]]. Although the process requires a large amount of (much rarer) [[Uranium-235]] to start, it can be a good way to get more use out of the available [[uranium ore]].

== Purpose ==
[[Uranium processing]] takes 10 uranium ore and returns 1 Uranium-235 with 0.007 (0.7%) probability, or 1 [[Uranium-238]] with 0.993 (99.3%) probability, leading to an [[:Wikipedia:Binomial_distribution|expected]] (though not guaranteed) 1 unit of Uranium-235 per approximately 143 processing cycles (or about a 1:142 ratio of U-235 to U-238). This is currently the only probability-based crafting recipe in the game.

Uranium-235 is necessary to create [[Uranium fuel cell]]s and [[Atomic bomb]]s, in considerable quantities for the latter, but the probability distribution of uranium processing leads to it being produced slowly and creating large stockpiles of U-238 as a byproduct. The Kovarex process thus provides the player with a considerably faster (and deterministic) method of producing U-235, as well as a use for the surplus U-238.

It should be noted that U-238 is not useless; it is necessary (and sufficient) to manufacture [[Uranium rounds magazine]]s, [[Uranium cannon shell]]s, and [[Explosive uranium cannon shell]]s, and is required as a secondary ingredient in Uranium fuel cells. Therefore, it is not advisable to use the Kovarex process to convert ''all'' stockpiled U-238 into U-235. (Although, in case of shortage, [[Used up uranium fuel cell]]s can be [[Nuclear fuel reprocessing|reprocessed]] into a modest amount of U-238.)

== Requirements for initiation (Uranium processing) ==
Unlike all other crafting processes in the game, Uranium processing creates U-235 and U-238 based on probability, rather than in guaranteed deterministic amounts. Additionally, the Kovarex process requires a bulk stockpile of 40 units of the rare Uranium-235 isotope to initiate in a single centrifuge. Therefore, planning uranium mining and processing for the Kovarex process takes certain considerations not encountered elsewhere in the game.

=== Expected value ===
As U-235 is created in centrifuges running Uranium processing with ''p = 0.007'', the expected number of processing cycles to gain a single unit is ''E(1,p) = 1 ÷ p = ~143''. The expected number of cycles to gain 40 units is then ''E(40,p) = 40 × E(1,p)'' = '''~5,714 cycles'''. Note that running this many cycles requires mining 57,140 Uranium ore, a non-trivial task.

However, given the nature of probability, it is impossible to guarantee that 40 units will be reached in this number of cycles; as a matter of fact, some mathematics yields that the probability that 5,714 cycles will produce ''at least'' 40 units of U-235 is only about 52%.

=== Confidence levels ===
[[File:Kovarex-prob-chart.png|300px|thumb|right|Probability of reaching 40 U-235 from Uranium processing by number of cycles (click to enlarge)]]

Some further mathematics enables one to calculate the number of Uranium processing cycles one must run to obtain ''at least'' 40 units of U-235 (given ''p = 0.007'') with a given level of confidence (probability of achieving the set goal).

As discussed in the previous section, the level of confidence corresponding to 5,714 cycles (for which the ''expected value'' of U-235 gained is 40) happens to be about 52% (or, in other words, with this number of cycles, one can expect to fail to reach 40 U-235 a bit less than once out of every 2 tries).

Some further example confidence levels that may be of interest to players are given in the table below. Consult the chart to the right for custom values.

{| class="wikitable" style="text-align: center;"
!style="width: 120px;" |Confidence level
!style="width: 100px;" |Failures
!Cycles required
|-
| 10% || 9 out of 10 || 4,595
|-
| 50% || 1 out of 2 || 5,667
|-
| 90% || 1 out of 10 || 6,894
|-
| 95% || 1 out of 20 || 7,272
|-
| 99% || 1 out of 100 || 8,015
|-
|}

== Trivia ==
* The Kovarex enrichment process is named after [[development-team|Michal Kovařík]], lead designer of Factorio and co-owner of Wube, whose online nick is ''kovarex'' (which he usually spells lowercase). [https://www.reddit.com/r/factorio/comments/67bj3p/015_kovarex_uranium_enrichment_is_too_good_with/dgq2ij3/?context=1]

* In the real world, [[:Wikipedia:Uranium-235|Uranium-235]] is the only fissile isotope of uranium and makes up approximately 0.72% of naturally-occurring uranium, with the other 99.28% being [[:Wikipedia:Uranium-238|Uranium-238]]. The in-game representation is thus highly accurate in this regard. Uranium is commonly [[:Wikipedia:Enriched_uranium|enriched]] in centrifuges to increase the percentage of 235U for use in fission reactions.
* Uranium munitions are made from [[:Wikipedia:depleted uranium|depleted uranium]], a byproduct of uranium enrichment, which is mostly 238U whose natural admixture of the 235U isotope has been lowered even further through the enrichment process. Depleted uranium is minimally radioactive and the reason for its use in munitions is its very high density and other mechanical properties, not radioactivity / toxicity.

== History ==
{{History|0.17.0|
* Can be used with productivity modules once again.
* Use with productivity modules now gives correct amount of bonus items.}}

{{History|0.15.2|
* No longer usable with productivity modules.}}

{{History|0.15.0|
* Introduced}}

== See also ==
* [[Uranium-235]]
* [[Uranium processing]]

{{IntermediateNav}}
{{C|Components}}

2018-09-03T02:17:32Z

Misacek01: /* Infinite Research */

'''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 [[Factorio:Wiki rules|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 [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages]. In addition to the help provided by MW, we also provide a [[Factorio:Style guide|style guide]] that we enforce. 
If you're unsure where to begin, please see the [[Factorio:Editor_noticeboard|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. :) [[User:Gangsir|Gangsir]] ([[User talk: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:

=== 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 <code>J = 8,000 x N / T</code>, 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 <code>N = J x T / 8,000 = T x 6,800 / 8,000 = T x 17 / 20 = 0.85 T</code>. 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 <code>T[1] = L / 83</code> 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 <code>12.04 * (S / 100)</code> 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 <code>T = 40 / (12 * 2.31) =~ 1.44 s</code>, 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.''

Research

2018-09-03T02:10:25Z

Misacek01: /* 'Infinite' research */ style

Research

2018-09-03T02:04:25Z

Misacek01: added that inf research requires space packs, as it wasn't mentioned on the page before

User talk:Misacek01

2018-09-03T01:58:53Z

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 [[Factorio:Wiki rules|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 [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages]. In addition to the help provided by MW, we also provide a [[Factorio:Style guide|style guide]] that we enforce. 
If you're unsure where to begin, please see the [[Factorio:Editor_noticeboard|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. :) [[User:Gangsir|Gangsir]] ([[User talk:Gangsir|talk]]) - Admin 23:45, 19 September 2017 (UTC)

== Page Edits Under Construction (Please Don't Edit) ==

=== Infinite Research ===

=== 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 <code>J = 8,000 x N / T</code>, 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 <code>N = J x T / 8,000 = T x 6,800 / 8,000 = T x 17 / 20 = 0.85 T</code>. 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 <code>T[1] = L / 83</code> 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 <code>12.04 * (S / 100)</code> 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 <code>T = 40 / (12 * 2.31) =~ 1.44 s</code>, 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.''

User talk:Misacek01

2018-09-03T01:58:10Z

2018-08-29T23:00:09Z

Misacek01: Found table from Stack Size section at end of page (!) due to markup typo. Oops. Also, changed math terminology used in History ("dual numbers" is something else); +History style cleanup.

{{Languages}}
A stack is the basic element in Factorio to store items. One space in an inventory can hold one stack.

== Examples of stacks ==

* The [[player]]'s inventory
** Main inventory
** The toolbelt ([[Player#Quickbar|quickbar]])
** Tool, armor, weapon, and ammunition stacks
** Logistic trash slots
** The player's hand (is also a stack)
* [[Vehicle]]s
** [[Car]] (fuel, ammunition, and a full inventory)
** [[Tank]] (fuel, ammunition, inventory)
** [[Railway|Train]] (wagons, engines for fuel)
* [[Chests]]: The archetypal example of stacks outside the player's inventory; a chest is basically just a group of stacks.
* Devices
** [[Furnace]]: Burner stack ([[Stone furnace|stone]] and [[Steel furnace|steel]] furnace only), input and output stack
** [[Assembling machine|Assembling machines]] and [[Chemical plant|chemical plants]]: 1 to 6 input and 1 output stack, depending on item being assembled
** [[Lab|Labs]]
** Burner-based: [[Boiler]], [[burner mining drill]], [[burner inserter]]
** [[Roboport]] (filtered for robots and repair packs only)
** [[Gun turret]]
* Special
** [[Inserters]] and [[Robotic network#Robots|worker robots]] (Small, variable-size stacks allow these entities to move items between other stacks. See also the [[Inserter capacity bonus (research)|inserter]] and [[Worker robot cargo size (research)|robot]] stack size bonus research topics.)

== How do stacks work? ==

A stack can store a number of identical items.

The first inserted item determines which item-types can be stored. This also determines how many items can be stored (the number of items per stack depends on it's max stack size).

Only items can be stored within stacks, stacks cannot hold [[Fluid system|liquids]] or other inventories.

=== Stack size ===

The number of items a stack can store. Stack size depends on the item; existing stack sizes and (non-exhaustive) examples include (click to expand):

{| class="wikitable mw-collapsible mw-collapsed"
!style="width: 100px;" |Stack size
!Examples
|-
| 1 || [[Nuclear fuel]], [[artillery shell]]. No stacking. A rare stack size possessed by only a few item types.
|-
| 5 || [[Locomotive]], all [[Wagon|wagons]]. More common than no stacking, but still quite rare.
|-
| 10 || [[Roboport]], [[rocket fuel]], [[artillery turret]], [[atomic bomb]]. Also relatively uncommon.
|-
| 50 || All ores, [[stone]], [[coal]], all [[Module|modules]], [[electric mining drill]], [[electric furnace]], all [[Assembling machine|assemblers]], all [[Chest|chests]], all [[inserters]], [[gun turret]], [[laser turret]], all [[Electric_system#Distribution|power poles]] including [[substation]], both types of [[Robotic network|worker robots]], [[solid fuel]]. One of the more common stack sizes; probably the most common stack size among buildable entities.
|-
| 100 || [[Iron plate]], [[copper plate]], [[steel]], [[processing unit]], [[iron gear wheel]], [[stone brick]], all types of [[concrete]], both isotopes of [[Uranium processing|processed uranium]], [[pipe]] (regular), all [[Belt transport system|belts]], [[wall]], [[landfill]]. Likely the most common stack size.
|-
| 200 || [[Electronic circuit]], [[advanced circuit]], all types of [[Ammunition#Magazines|magazine]], all types of [[tank]] [[Ammunition#Tank shells|cannon shell]], [[copper cable]], both colors of circuit [[Circuit network|wire]], all types of [[science pack]] except space science pack. A somewhat-common stack size overall; typical stack size for [[ammunition]].
|-
| 2,000 || Unique to [[space science pack]], present to allow stacking up to 2 [[Rocket|rockets]]' worth of packs in the [[rocket silo]]'s single output slot.
|}

=== Filtered stacks ===

Stacks can be filtered either by default (in burner-type entities, [[Furnace|furnaces]], [[Roboport|roboports]], [[turrets]], [[Lab|labs]], and other entities that can only accept one or a few item types in a particular slot), or manually by the player (normally set via the middle mouse button / scroll-wheel click, see [[Keyboard bindings]]). Manual filtering is available for [[Cargo wagon|cargo wagons]], the [[Player#Quickbar|quickbar]], and the player inventory, but not for other types of containers (in particular, [[Chest|chests]] of any type).

This can be used to ensure only one item type goes into the inventory space. [[Inserters]] (or [[Robotic network|bots]], where applicable) will not attempt to insert anything except the allowed item type into filtered slots, and manual insertion of other item types by the player is also not allowed unless and until the filter is cleared.

=== Damaged items ===

Damaged items will stack together with other damaged items, and the health of the stack will be the average health of all items in it. Damaged items will not stack with undamaged items.

== Stack size bonuses ==

Inserters and logistic robots can be boosted with research to hold and transfer more items, see:

* [[Inserter capacity bonus (research)]],
* [[Worker robot cargo size (research)]]

== Stack limitation ==

[[File:Stack limiter.jpg|300px|thumb|frame|A [[wooden chest]] limited to three stacks. Once the third stack is full, inserters will no longer attempt to add items.]]

Optionally, the usable space in [[chests]] and [[Cargo wagon|wagons]] can be decreased below their default values. Typically, this is done to store a small amount of items in an automated process, without consuming the resources that would be required to fill the entire container.

To limit a container, click the red X at the end of the last stack. Then, click on one of the stacks to set the new limit. The unused stacks will be highlighted red (see right).

When full, inserters will no longer add to a limited container. However, the player is still free to manually place items in the unused (red) slots.

== Handling stacks ==

There are some [[Keyboard bindings|keyboard bindings]] to handle movement of stacks between inventories fast, like moving half of a stack to another stack.

== History ==

In game version 0.10, the number of items which can be stored in a stack changed for most items from powers of 2 to multiples of 10. This change was mainly made because most people find it more intuitive to calculate numbers in a base-10 system.

Example: Before the change, a stack could store 64 iron ore, while after the change it is 50. This created some controversy, as some players preferred the old stack sizes.

Stack

2018-08-29T22:50:08Z

Misacek01: /* Examples of stacks */ style cleanup, some links

{{Languages}}
A stack is the basic element in Factorio to store items. One space in an inventory can hold one stack.

== Examples of stacks ==

* The [[player]]'s inventory
** Main inventory
** The toolbelt ([[Player#Quickbar|quickbar]])
** Tool, armor, weapon, and ammunition stacks
** Logistic trash slots
** The player's hand (is also a stack)
* [[Vehicle]]s
** [[Car]] (fuel, ammunition, and a full inventory)
** [[Tank]] (fuel, ammunition, inventory)
** [[Railway|Train]] (wagons, engines for fuel)
* [[Chests]]: The archetypal example of stacks outside the player's inventory; a chest is basically just a group of stacks.
* Devices
** [[Furnace]]: Burner stack ([[Stone furnace|stone]] and [[Steel furnace|steel]] furnace only), input and output stack
** [[Assembling machine|Assembling machines]] and [[Chemical plant|chemical plants]]: 1 to 6 input and 1 output stack, depending on item being assembled
** [[Lab|Labs]]
** Burner-based: [[Boiler]], [[burner mining drill]], [[burner inserter]]
** [[Roboport]] (filtered for robots and repair packs only)
** [[Gun turret]]
* Special
** [[Inserters]] and [[Robotic network#Robots|worker robots]] (Small, variable-size stacks allow these entities to move items between other stacks. See also the [[Inserter capacity bonus (research)|inserter]] and [[Worker robot cargo size (research)|robot]] stack size bonus research topics.)

== How do stacks work? ==

A stack can store a number of identical items.

The first inserted item determines which item-types can be stored. This also determines how many items can be stored (the number of items per stack depends on it's max stack size).

Only items can be stored within stacks, stacks cannot hold [[Fluid system|liquids]] or other inventories.

=== Stack size ===

The number of items a stack can store. Stack size depends on the item; existing stack sizes and (non-exhaustive) examples include (click to expand):

{| class="wikitable mw-collapsible mw-collapsed"
!style="width: 100px;" |Stack size
!Examples
|-
| 1 || [[Nuclear fuel]], [[artillery shell]]. No stacking. A rare stack size possessed by only a few item types.
|-
| 5 || [[Locomotive]], all [[Wagon|wagons]]. More common than no stacking, but still quite rare.
|-
| 10 || [[Roboport]], [[rocket fuel]], [[artillery turret]], [[atomic bomb]]. Also relatively uncommon.
|-
| 50 || All ores, [[stone]], [[coal]], all [[Module|modules]], [[electric mining drill]], [[electric furnace]], all [[Assembling machine|assemblers]], all [[Chest|chests]], all [[inserters]], [[gun turret]], [[laser turret]], all [[Electric_system#Distribution|power poles]] including [[substation]], both types of [[Robotic network|worker robots]], [[solid fuel]]. One of the more common stack sizes; probably the most common stack size among buildable entities.
|-
| 100 || [[Iron plate]], [[copper plate]], [[steel]], [[processing unit]], [[iron gear wheel]], [[stone brick]], all types of [[concrete]], both isotopes of [[Uranium processing|processed uranium]], [[pipe]] (regular), all [[Belt transport system|belts]], [[wall]], [[landfill]]. Likely the most common stack size.
|-
| 200 || [[Electronic circuit]], [[advanced circuit]], all types of [[Ammunition#Magazines|magazine]], all types of [[tank]] [[Ammunition#Tank shells|cannon shell]], [[copper cable]], both colors of circuit [[Circuit network|wire]], all types of [[science pack]] except space science pack. A somewhat-common stack size overall; typical stack size for [[ammunition]].
|-
| 2,000 || Unique to [[space science pack]], present to allow stacking up to 2 [[Rocket|rockets]]' worth of packs in the [[rocket silo]]'s single output slot.
|-}

=== Filtered stacks ===

Stacks can be filtered either by default (in burner-type entities, [[Furnace|furnaces]], [[Roboport|roboports]], [[turrets]], [[Lab|labs]], and other entities that can only accept one or a few item types in a particular slot), or manually by the player (normally set via the middle mouse button / scroll-wheel click, see [[Keyboard bindings]]). Manual filtering is available for [[Cargo wagon|cargo wagons]], the [[Player#Quickbar|quickbar]], and the player inventory, but not for other types of containers (in particular, [[Chest|chests]] of any type).

This can be used to ensure only one item type goes into the inventory space. [[Inserters]] (or [[Robotic network|bots]], where applicable) will not attempt to insert anything except the allowed item type into filtered slots, and manual insertion of other item types by the player is also not allowed unless and until the filter is cleared.

=== Damaged items ===

Damaged items will stack together with other damaged items, and the health of the stack will be the average health of all items in it. Damaged items will not stack with undamaged items.

== Stack size bonuses ==

Inserters and logistic robots can be boosted with research to hold and transfer more items, see:

* [[Inserter capacity bonus (research)]],
* [[Worker robot cargo size (research)]]

== Stack limitation ==

[[File:Stack limiter.jpg|300px|thumb|frame|A [[wooden chest]] limited to three stacks. Once the third stack is full, inserters will no longer attempt to add items.]]

Optionally, the usable space in [[chests]] and [[Cargo wagon|wagons]] can be decreased below their default values. Typically, this is done to store a small amount of items in an automated process, without consuming the resources that would be required to fill the entire container.

To limit a container, click the red X at the end of the last stack. Then, click on one of the stacks to set the new limit. The unused stacks will be highlighted red (see right).

When full, inserters will no longer add to a limited container. However, the player is still free to manually place items in the unused (red) slots.

== Handling stacks ==

There are some [[Keyboard bindings|keyboard bindings]] to handle movement of stacks between inventories fast, like moving half of a stack to another stack.

== History ==

In v0.10, the number of items which can be stored in a stack changed for most items from dual numbers to decimal (base 2 vs. base 10). This change was mainly made because it is easier to calculate numbers based on the base-10-system.

Example: before that change, a stack could store 64 iron ore, after the change only 50. This change created a lot of controversy as some players preferred the old stack sizes.

Stack

2018-08-29T22:25:58Z

Misacek01: /* Stack size */ apparently not. table shows in section preview but not on actual page. please advise / assist? thanks.

{{Languages}}
A stack is the basic element in Factorio to store items. One space in an inventory can hold one stack.

== Examples of stacks ==

* The player's inventory
** Main inventory
** [[Player#Quickbar|Toolbelt]] (or quickbar)
** Tool-, armor-, weapon- and ammunition stacks
** Logistics trash slots
** The player's hand (is also a stack)
* [[Vehicle]]s
** [[Car]] (fuel, ammunition, and a full inventory)
** [[Tank]] (fuel, ammunition)
** [[Railway|Train]] (wagons, engines for fuel)
* [[Chests]]: Best example outside the player's inventory; a chest is bascially just a group of stacks.
* Devices
** [[Furnace]]: Burner-, incoming and outgoing stack
** [[Assembling machine]]s and [[Chemical plant]]s: Several in- and one outgoing stacks, depending on the item assembled
** [[Lab]]s
** Burner-based: [[Boiler]], [[Burner mining drill]], [[Burner inserter]]
** Roboport (filtered for robots and repair packs only)
** [[Gun turret]]s
* Special
** Inserter and Robots (they have some limited stacks, see stacksize bonus), so that they are able to move some items between stacks at once.

== How do stacks work? ==

A stack can store a number of identical items.

The first inserted item determines which item-types can be stored. This also determines how many items can be stored (the number of items per stack depends on it's max stack size).

Only items can be stored within stacks, stacks cannot hold [[Fluid system|liquids]] or other inventories.

=== Stack size ===

The number of items a stack can store. Stack size depends on the item; existing stack sizes and (non-exhaustive) examples include (click to expand):

{| class="wikitable mw-collapsible mw-collapsed"
!style="width: 100px;" |Stack size
!Examples
|-
| 1 || [[Nuclear fuel]], [[artillery shell]]. No stacking. A rare stack size possessed by only a few item types.
|-
| 5 || [[Locomotive]], all [[Wagon|wagons]]. More common than no stacking, but still quite rare.
|-
| 10 || [[Roboport]], [[rocket fuel]], [[artillery turret]], [[atomic bomb]]. Also relatively uncommon.
|-
| 50 || All ores, [[stone]], [[coal]], all [[Module|modules]], [[electric mining drill]], [[electric furnace]], all [[Assembling machine|assemblers]], all [[Chest|chests]], all [[inserters]], [[gun turret]], [[laser turret]], all [[Electric_system#Distribution|power poles]] including [[substation]], both types of [[Robotic network|worker robots]], [[solid fuel]]. One of the more common stack sizes; probably the most common stack size among buildable entities.
|-
| 100 || [[Iron plate]], [[copper plate]], [[steel]], [[processing unit]], [[iron gear wheel]], [[stone brick]], all types of [[concrete]], both isotopes of [[Uranium processing|processed uranium]], [[pipe]] (regular), all [[Belt transport system|belts]], [[wall]], [[landfill]]. Likely the most common stack size.
|-
| 200 || [[Electronic circuit]], [[advanced circuit]], all types of [[Ammunition#Magazines|magazine]], all types of [[tank]] [[Ammunition#Tank shells|cannon shell]], [[copper cable]], both colors of circuit [[Circuit network|wire]], all types of [[science pack]] except space science pack. A somewhat-common stack size overall; typical stack size for [[ammunition]].
|-
| 2,000 || Unique to [[space science pack]], present to allow stacking up to 2 [[Rocket|rockets]]' worth of packs in the [[rocket silo]]'s single output slot.
|-}

=== Filtered stacks ===

Stacks can be filtered either by default (in burner-type entities, [[Furnace|furnaces]], [[Roboport|roboports]], [[turrets]], [[Lab|labs]], and other entities that can only accept one or a few item types in a particular slot), or manually by the player (normally set via the middle mouse button / scroll-wheel click, see [[Keyboard bindings]]). Manual filtering is available for [[Cargo wagon|cargo wagons]], the [[Player#Quickbar|quickbar]], and the player inventory, but not for other types of containers (in particular, [[Chest|chests]] of any type).

This can be used to ensure only one item type goes into the inventory space. [[Inserters]] (or [[Robotic network|bots]], where applicable) will not attempt to insert anything except the allowed item type into filtered slots, and manual insertion of other item types by the player is also not allowed unless and until the filter is cleared.

=== Damaged items ===

Damaged items will stack together with other damaged items, and the health of the stack will be the average health of all items in it. Damaged items will not stack with undamaged items.

== Stack size bonuses ==

Inserters and logistic robots can be boosted with research to hold and transfer more items, see:

* [[Inserter capacity bonus (research)]],
* [[Worker robot cargo size (research)]]

== Stack limitation ==

[[File:Stack limiter.jpg|300px|thumb|frame|A [[wooden chest]] limited to three stacks. Once the third stack is full, inserters will no longer attempt to add items.]]

Optionally, the usable space in [[chests]] and [[Cargo wagon|wagons]] can be decreased below their default values. Typically, this is done to store a small amount of items in an automated process, without consuming the resources that would be required to fill the entire container.

To limit a container, click the red X at the end of the last stack. Then, click on one of the stacks to set the new limit. The unused stacks will be highlighted red (see right).

When full, inserters will no longer add to a limited container. However, the player is still free to manually place items in the unused (red) slots.

== Handling stacks ==

There are some [[Keyboard bindings|keyboard bindings]] to handle movement of stacks between inventories fast, like moving half of a stack to another stack.

== History ==

In v0.10, the number of items which can be stored in a stack changed for most items from dual numbers to decimal (base 2 vs. base 10). This change was mainly made because it is easier to calculate numbers based on the base-10-system.

Example: before that change, a stack could store 64 iron ore, after the change only 50. This change created a lot of controversy as some players preferred the old stack sizes.