Difference between revisions of "Overflow"
From #openttdcoop wiki
(Started an article on overflows, based on V's ABR 8-To be expanded) |
|||
| Line 1: | Line 1: | ||
| + | {{stub}} | ||
| + | |||
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. | 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. | ||
| Line 10: | Line 12: | ||
The very main disadvantage is that we have a depot that is accessible. Some accidental click on “Send to depot” or “Send for servicing” could wreak havoc on our network. Another issue could emerge when trains stack up in the overflow, and then leave it all at once, creating a massive wave (usually caused by a jam on the ML). Many of these disadvantages can be rid of by using the correct designs. | The very main disadvantage is that we have a depot that is accessible. Some accidental click on “Send to depot” or “Send for servicing” could wreak havoc on our network. Another issue could emerge when trains stack up in the overflow, and then leave it all at once, creating a massive wave (usually caused by a jam on the ML). Many of these disadvantages can be rid of by using the correct designs. | ||
Use overflows, but do not abuse them. Storing 50 trains is not the purpose of an overflow, and a waste. | Use overflows, but do not abuse them. Storing 50 trains is not the purpose of an overflow, and a waste. | ||
| − | + | ||
| + | ==Characteristics of an Overflow== | ||
| + | |||
| + | Mechanisms such as overflows can do various things, and thus have to be made of various sub-mechanisms, defining how it works in total. In overflows there quite a few parts in particular. | ||
Revision as of 13:25, 3 April 2012
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
The very main disadvantage is that we have a depot that is accessible. Some accidental click on “Send to depot” or “Send for servicing” could wreak havoc on our network. Another issue could emerge when trains stack up in the overflow, and then leave it all at once, creating a massive wave (usually caused by a jam on the ML). Many of these disadvantages can be rid of by using the correct designs. Use overflows, but do not abuse them. Storing 50 trains is not the purpose of an overflow, and a waste.
Characteristics of an Overflow
Mechanisms such as overflows can do various things, and thus have to be made of various sub-mechanisms, defining how it works in total. In overflows there quite a few parts in particular.
