Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
I forget exactly how, but when editing the blueprint, you can change the behavior of a click-and-drag, so that dragging snaps to a fixed distance relative to where you started dragging (or to snap to a global grid).
I think the default distance is so that you are laying copies of the blueprint as adjacent tiles. But you can also adjust the offset so that adjacent copies will overlap or have gaps.
Of course, you still have to wait for bots to place the signals. Or manually place the signals in the ghosts the blueprint makes.
Best to just make a blueprint with both rail and signals and make it absolute grid snapping from the start.
I don't really mind setting up chain signals on complicated junctions myself, that's satisfying work in many cases, but I think the devs really ought to consider a vanilla implementation of the signal spacing feature on straightaways, maybe using the upgrade planner or something which currently has no effect on rails anyway
The important thing is regularity. The idea being that if you have two trains, one following another, and they don't run into any obstacles, then signals should never cause the rear train to have to stop for a red signal.
E.g. if you had a pattern if having 4 car lengths between signals, and then had one block that was 5 car lengths long... that would cause a stop if the rear train happened to be following behind with a gap between 4 and 5 car lengths.
By avoiding this, you keep trains running, rather than losing a lot of throughput by having trains randomly stop and have to accelerate from zero, just because they coincidentally packed a little too closely together earlier up the line.
(OpenTTD had more tools to keep traffic flowing when the short signal spacing couldn't be observed, namely elevation and bridges/tunnels, so Factorio networks can't quite achieve the same level of efficiency that OpenTTD ones can)
The main specific thing that "one full train" spacing does is, when combined with the "regular signal immediately at the exit of an intersection" style, it guarantees that a train won't enter the intersection unless it can clear the intersection.
And if you want to guarantee behavior, I don't think that's the only solution. E.g. you could put a chain signal at the exit and then the normal signal afterwards, spaced far enough to ensure that the path doesn't open unless there is enough space to clear the intersection.
I know from multiplayer that it's much harder to get someone to measure exit blocks than "chain in, rail out" even though you will deadlock without it. I believe this is because the UI tools for doing it are so painful.
It is hard to get people to take this seriously. In multiplayer I would tell people that deadlock takes manual labor to fix, so it's against the spirit of the game. We are trying to make the factory run by itself. More recently I thought of the concept that signals only inform the front of the train, that trains don't know their length, the game in general has no way to talk about the full length of a train, and measuring the exit blocks is the only way to trick the game into doing it. I haven't tried telling it to anyone yet to see if it helps.
If on the other hand there's a long straight after it is better to cram the trains closer by opening the way sooner, which you accomplish with a short exit block. Sure it is theoretically possible that it causes deadlocks, but if your trains are backed up all the way from wherever it starts to that junction there's another primary cause, and the deadlock just meant you found out about your error sooner.