Difference between revisions of "Overflow"
From #openttdcoop wiki
m (updated) |
m (Added to station category and merge proposal) |
||
| Line 1: | Line 1: | ||
| + | {{Merge|Station Cache}} | ||
{{stub}} | {{stub}} | ||
| Line 17: | Line 18: | ||
* [http://blog.openttdcoop.org/2012/06/28/advanced-building-revue-12-overflows-iii/ Advanced Building Revue 08] | * [http://blog.openttdcoop.org/2012/06/28/advanced-building-revue-12-overflows-iii/ Advanced Building Revue 08] | ||
* [http://blog.openttdcoop.org/2010/11/07/advanced-building-revue-08-overflows-ii/ Advanced Building Revue 12] | * [http://blog.openttdcoop.org/2010/11/07/advanced-building-revue-08-overflows-ii/ Advanced Building Revue 12] | ||
| + | |||
| + | |||
| + | [[Category:Stations]] | ||
Revision as of 07:40, 7 November 2013
 |
It has been suggested that this article or section be merged with Station Cache. (Discuss) |
This article is a stub. Please, if you can, expand it.
Overflows are a sometimes-handy feature of our networks. When they are used, they can save us a lot of work. On the other hand they have (of course) their disadvantages.
Purpose
Why do we build an overflow – our station tends to catch wave traffic and sometimes it just jams. The primal source of this are usually just jams on the network, making trains come in random intervals, randomizing also their required count to take all the cargo. So the first reaction on jammed station shouldn’t be to add an overflow, but unjam the network first. In some cases it is possible that the station gets trains just randomly even when our network isn’t jamming at all. The perfect examples are basically any conditional orders, where trains could jump to other orders, skipping/adding part of their journey, reaching random travel times.
Disadvantages
Overflows need space and sometimes additional logic. If they are built without a reverser, their depot is visible, which can ruin refit or train replacement games, and lead to problems in other games.
