【Factorio】Three Principles for Chain Signal Placement

Chain train signals in Factorio might look like there's a lot to learn, but the actual placement rules are quite simple. For beginners to intermediate players building intersections in Factorio 2.0 vanilla or Space Age, just remember these three principles: place chain signals at entrances, regular signals only where trains can safely stop, and use chain signals for exits on short blocks or consecutive intersections—and you'll avoid most major mistakes.

I got stuck early on with my first T-junction, with trains constantly stopping in the middle of the intersection and thinking "why is this jammed?" But the moment I switched the entrance to a chain signal and cleared enough space after the intersection for a full train length, the flow stabilized dramatically.

This article walks through these three principles with practical examples, so you can understand not just where to place signals, but why they go there.

Three Principles for Chain Signal Placement in Factorio

To cut to the chase: the most practical way to think about chain train signals is "signals you place before entering an intersection," and regular signals as "signals you place after exiting an intersection, only if trains can safely stop there." Once this click for you, you stop second-guessing yourself on T-junctions and cross-intersections. For reference, I'm drawing from the official "Chain train signal" explanation on Factorio Wiki, though official pages do get updated—verify the current content and URL before publishing. https://wiki.factorio.com/Rail_chain_signal

Principle 1: Entrances Use Chain Signals

Place chain signals at the entrance of any branch, merge, or intersection. This is the most important of the three principles. The reason is simple: you want trains to decide before entering whether they can actually exit, rather than entering first and then figuring it out.

Put a regular signal at the entrance, and trains will move forward if just the next block is clear. They'll poke their head into the intersection, get stuck when the exit is jammed, and then tie up following trains and cross-traffic too. Honestly, this is the classic beginner mistake—I definitely made it. I kept thinking "I placed signals, why is it still gridlocked?" but swapping the entrance to a chain signal made that problem practically disappear.

Chain signals look ahead to the next signal condition before deciding to enter. So if the exit is blocked, they hold trains before the intersection rather than letting them pile up inside. In other words, chain signals prevent the intersection from becoming a parking lot. The principle is the same for branches and merges: always look ahead before entering any place where trains could collide.

If you can place signals inside the intersection, the standard move is to link the internal blocks with chain signals too. This lets you separate non-crossing paths into finer control units, making the flow much more stable when traffic is heavy. The difference really shows on double-track cross-intersections or junctions with mixed turning traffic.

Principle 2: Regular Signals Only Where Trains Can Stop

Regular signals belong only in places you can honestly say "if a train stops here, it won't block the wider network." To put it another way, **use regular signals to define where trains should stop**.

The classic setup is a straight run after the intersection with enough space that a stopped train won't reach back into the convergence zone. That's why we say "exit with regular signals"—though more precisely, it's "regular signals only if there's a safe stopping zone on the exit side."

Flip that around: place a regular signal where trains shouldn't stop, and that spot becomes their default waiting point. Then they exit the intersection but their tail is still sticking into the crossing, blocking following trains. Deadlocks often look complicated until you realize that a huge chunk of them trace back to "regular signal placed somewhere trains actually can't be stopped."

This principle really matters once traffic picks up. The more trains running, the more your signal placement is your throughput. A regular signal is a declaration that "trains may stop here"—once you internalize that, placement mistakes drop off fast.

Principle 3: Short Exits and Consecutive Intersections Use Chain Signals

"Exit with regular signals" is the baseline, but it's not always right. When the space after an intersection is short or another intersection/branch/signal comes right after, chain signals on the exit are more stable.

The problem that shows up is: you placed a regular signal at the exit, so trains act like "I'm clear of the intersection." But the space ahead is too short to fit a full train, so the train ends up with its body still partly in the previous intersection. It looks like it exited, but operationally it's still blocking. This becomes the bottleneck.

Consecutive T-junctions or a cross-intersection with a merge right on the other side trigger this all the time. I built a pre-station merge and placed a regular signal on the exit—the result was trains in mid-position, partial-blocking, and the whole network dragging. Switching the exit to a chain signal so it says "only if I can reach the real safe stop point" made the flow clean again.

There are two scenarios where you want chain signals instead: one is no stopping room for a full train outside the intersection, and the other is decision point comes right after. The first prevents overhang, the second keeps blocks in sequence under unified control. Community examples treat these as exceptions to "regular signal on exit," and that understanding is way more useful than pure rote memorization. Chain on entrance, chain-or-regular in the middle, regular only where there's real stopping space—build that way and even large networks stay stable.

Background: Regular and Chain Signal Differences

Terminology: Blocks (Sections) and Reservation Logic

Understanding this first makes the regular vs. chain signal split land much faster. I'm talking vanilla Factorio 2.0, and the same logic holds in Space Age since both launched the same day with signal fundamentals intact.

Train signals divide track into blocks (or sections)—regions between signals, or areas containing junctions. A train already inside a block normally blocks any other train from entering. By reservation, think of a train claiming the route it's about to take. Early on, I just thought "red = stop, green = go," which is why my intersections jammed so badly—I didn't grasp the reservation part at all.

Regular signals mainly check if the very next block is free. Chain signals look further: they check whether the path ahead stays clear all the way to the next signal. The official Factorio Wiki tutorial on signals builds around this—chain signals for intersection entry management. In one sentence: regular signals check "is the next block free?" while chain signals check "can I make it all the way to the next safe point?"

Space Age

wiki.factorio.com

Logic Difference: Entry vs. Condition Checking

Regular signals excel at marking "a safe place to wait." If the next block is open, they let trains in—great for straightaways and station queues. But put one at an intersection entrance and the logic is too short-sighted. The moment there's any gap in the intersection, trains nudge in, and if the exit jams, they stop mid-crossing. This is the root cause of jam-happy entrances.

Chain signals do the opposite—they're cautious about entry. They check not just the next block but whether the path stays valid all the way to the next signal condition. If not, they make trains wait at the entrance. That's the magic: intersections don't become parking lots. Once you see this, "entrance = chain, exit = regular" clicks into place instantly. Entrance judges entry, exit marks where stopping is okay.

A vivid failure mode: regular signal entrance, train tip slides in, exit space too tight, train stops inside the intersection. Now the train behind it can't enter, trains from other directions can't use it either—one mistake cascades. I've definitely done this on T-junctions and been very confused. The issue wasn't the signal itself—it was what I designated as a waiting area.

Think of intersections as bulk reservation. Chain signals mean "if I enter, I commit to staying clear from the intersection all the way to the real safe stopping point." That's why mid-intersection stops vanish. Of course, if the exit is super short and then another intersection, swapping that exit to regular signals will mark that short zone as a waiting spot. But if you need the logic further out, chain signals on the exit push the reservation check deeper.

Color Displays and Pre-Intersection Waiting

Signal colors are easier to read when you think of them as results of reservation, not just "go/stop." Regular signals are basically green=proceed or red=stop. Chains add blue, which trips up beginners. Blue roughly means the path ahead exists, but with forward-looking conditions. See blue on an intersection? You're seeing "keep moving but looking ahead."

The bigger concept for intersection design is pre-intersection waiting. Don't make trains stop inside—make them stop before. This changes jam stability more than any signal detail. Picture it like this:

Regular signal at entrance
→ Next intersection block is empty, so enter
→ But exit is jammed, stop inside

   [Regular]
----S------X****Intersection****X---[Jammed]
             ↑
           Stops here (bad)

Chain signal at entrance
→ Check all the way to exit
→ If exit is full, wait before the intersection

   [Chain]
----C------X****Intersection****X---[Jammed]
      ↑
   Waits here (good)

This "wait in front" design pairs with bulk reservation. Intersections are for passing through, waiting happens outside. On multiplayer networks, this principle alone cuts accidents hard. It sounds basic, but breaking it makes even elaborate intersections jam immediately.

On signal basics, the official Wiki tutorial is solid, but community examples like "Getting Started with Factorio Railways (Chain Signals)" and the factorio@jp Wiki layout examples are really intuitive. Once you see intersections as "places where entry is allowed only when all conditions line up to get completely through," regular vs. chain use becomes self-evident.

Principle 1: Chain Signals at Junctions, Branches, and Merges

This is the hardest principle to mess up. Branches, merges, and intersections get chain signals on the way in. Lock this in and your signal design confusion drops sharply. Why? Because chain signals can say: "maybe the entrance is clear, but if the exit is jammed, don't go in." Another way to say it: don't use the intersection as a waiting area.

I definitely thought early on "if the entrance is green, isn't the train allowed to go?" Not quite—a regular entrance doesn't look past the intersection entry, so trains poke their head in and get stuck if the exit backs up. Once one train stops, cross traffic jams, turning traffic jams, and one small signal mistake creates a network-wide shutdown. Swap to chain at the entrance and you get blue-light waiting before the crossing, then green all the way through once conditions line up. The transition is visibly dramatic—flow jumps from stuttering to smooth.

As the official Wiki on chain signals explains, they manage entry based on full-path conditions. At intersections, think "only enter if I can reserve a path through and out cleanly." Nail this and placement errors become rare.

T-Junction: Where to Place the Chain Signal

On a T-junction, this principle is almost self-explanatory. A T has a main line and a side line feeding in, and every entrance that could lead into the crossing gets a chain signal. Main line before it enters the crossing, side line before it enters, both. The goal is no room for mid-crossing stops.

T-Junction visual

        Side
         |
        [C]
         |
==****Crossing****==
   [C]        [Exit]
Main →

The mindset: "before entering the T-junction block, check if I can clear it." Chain signals make trains look all the way past the crossing to see if the exit clears. If not, they wait before the crossing. Regular signals would enter if the crossing's first block was open, miss the fact that the exit is jammed, and stop inside. This gets frustrating fast.

Bad-case vibes: main line comes in with a regular signal, enters, side merges in, exit is jammed, train sits in the middle. Now side-line trains can't move. Back-line trains pile up. One T-junction kills both directions. I burned hours on this. Swap to chain at both entrances, and trains queue outside, and when the path clears, they shoot through clean.

Cross-Intersection: Every Entrance is a Chain Signal

Chain signals become truly critical at cross-intersections. Because now you have four possible directions and every one can cross every other, even one regular entrance at the wrong spot makes the odds of mid-crossing stops shoot up.

Cross-intersection mental model

        [C]
         |
==****Crossing****==
[C]             [C]
         |
        [C]

Why all four? A cross-intersection isn't "is my route open?"—it's "do my needs matter more than the other three?" Say an eastbound train with a regular entrance decides to go west straight through. It stops mid-intersection. Now north-south traffic is blocked, northwest and southeast turns are blocked. That one train in the middle blocks four separate flows. This is why pre-intersection deadlock happens so easily.

Chain signals on all four entrances flip this: trains see the crossing as "I only enter if my full path to the other side clears." In practice, trains queue neatly outside, and when one path opens up, that train glides through. The difference is night-and-day—regular entrances look random and clunky, chain entrances look orchestrated.

The tutorial on rail signals even defaults to this. Cross-intersections are where you apply the chain-signal philosophy most directly, so getting comfortable there makes odd-shaped crossings much clearer.

Y-Branches and Merges: Chain Before the Split/Merge

Y-junctions are deceptive because they look gentle, but they're still intersections. Place chain signals before the split or before the merge—i.e., right before the fork, or right before two paths become one.

Y-branch split

      ↗ Out A
---[C]<
      ↘ Out B

Y-merge

In A ↘
      >[C]--- Combined
In B ↗

Chain before a split: if one output is jammed, don't let trains in. Regular here, trains nose into the fork before realizing they're stuck, then block the other outlet. Y's look less dramatic than crosses, so it's easy to think "stopping mid-fork is fine," but it really blocks everything. You get one train partly in, one direction blocked, the other direction waiting—not great.

Merge is the same: if the merged path is full, don't let either input in. If one side sticks its nose in and stops, the other side can't merge. Even worse on a main-line merge; one support train getting stuck mid-merge will slow the main line noticeably. I've built exactly this and watched trains "halfway-commit" to killing the entire network. Chain signals make that hesitation disappear.

The community blog "Getting Started with Factorio Railways (Chain Signals)" has practical examples of entrance chain + exit regular as baseline. Y-junctions are just intersections in different dress—same rules apply. Chain before you split or merge, and placement uncertainty drops way down.

Principle 2: Regular Signals Only Where Trains Safely Stop

Thinking About Train Length

Here's the thing: saying "exit uses regular signals" doesn't mean regular signals work on every exit. The condition is one: the exit space must fit your longest train completely. Gloss over this and chain entrances won't save you from mid-intersection stops.

Longest train thinking is straightforward in practice. Measure from engine front to last car back. That's your benchmark—not "typical trains," but the single longest train in the network. If you run 2-4 mostly but occasionally a 2-8 supply train, size for the 2-8. The exit waiting zone must fit that full length and not feel squeezed around the signals.

Measuring on an actual train is better than guessing. Plop a train on a straightaway, count the tiles from nose to tail, and you've got your magic number. I learned this the hard way: thinking "it'll fit" but having the last car still in the intersection is the worst—because that fraction still counts as the intersection being occupied.

The blog "Getting Started with Factorio Railways (Chain Signals)" drives this home: regular exits only work if there's enough exit space. So the exact rule is **entrance = chain, exit = "regular *only if there's stopping room"***. Get this condition right and even unusual branches work cleanly.

Checklist for Regular-Signal Exit Placement

Wondering if an exit can use a regular signal? Look at one thing: do trains past this signal stay fully outside the intersection? If yes, regular works. If no, keep it chain.

Checklist flow:

1. Is there a zone past the exit where trains might stop?
2. Does your longest train fit completely in that zone?
3. Even fully parked, is the back still out of the intersection?

All three—go regular. Any fail—stick with chain. Regular at an exit is "trains may stop here"—true only if stopping there doesn't jam upstream. This is how deadlock gets born: regular looks like it's on the exit, but actually reserves space in the intersection.

This logic shows up in the Wiki and community builds too. Signal names matter less than whether this block is actually a safe stopping zone. An exit that looks outbound but has nowhere to wait is still partly in the intersection.

Chain train signal - Factorio Wiki

wiki.factorio.com

Short Exit Problems and Fixes

Short exits cause the ugliest failure: trains exit the intersection but can't fit, so they end up partly stuck in the crossing. That one train now blocks following trains, cross-directions, everything. On a cross-intersection, multiple routes go down.

I lived this with 2-4 trains. Put a regular on the exit, immediate zone's short, train noses out and stops inside. Looks tiny, breaks everything. Switched the exit to chain and set up a proper stacker—instant stability. The difference was real.

Bad example: one short block after the exit with a regular signal and you've accidentally made the intersection part of a waiting area. Better: extend the exit waiting zone properly, or add a stacker outside the crossing, or keep the exit chained to the next real clearing point. The intersection's throughput isn't just the crossing shape—it's where you're allowed to wait. When flow is weird but not obviously jammed, the exit zone is often the culprit.

Principle 3: Link Consecutive Intersections with Chain Signals

Consecutive Intersections Demand Chain Exits

Here's where beginners get most confused: if an intersection exit is immediately followed by another signal or intersection, a regular exit doesn't work. Applying principle 2 naively, you'd say "that's an exit, use regular." But short consecutive sections change the math.

Why? Trains exit the first crossing but the next block is so tight that if they stop there, they're still blocking the first crossing. And on consecutive intersections, just seeing one crossing ahead isn't enough. You need to see the next block, possibly the one after, and only stop at a real safe point. I built exactly this—first crossing exits to a short zone, second crossing right after, regular at the first exit = trains stopping in the sandwich zone between crossings. Whole network crawls. Swap to chain at the first exit, reserve through to a real stop point, and flow smoothens.

The mental move: treat an exit not as "the exit" but as "part of a longer path." If the next signal or crossing is close, the exit itself is still intersection-business. Chain on the exit extends the reservation logic forward.

Two big situations call for chained exits: no full-train stopping room outside and decision point comes immediately after. The first prevents overhang, the second keeps logic sequential. Community examples treat this as the normal exception to "regular on exit"—understanding it beats memorizing rules.

There's also the internal block splitting pattern. In 2.0+, examples show good results from dividing intersections internally, but verify the mechanics (patch notes, official Wiki) before deploying, since there have been updates.

Conceptually:

No split
[Entrance Chain] → [Intersection as one block] → [Exit]

Split version
[Entrance Chain] → [Internal block A] → [Internal block B] → [Exit]
                    \______Non-crossing paths can share______/

When split correctly, what was "one train in = all stop" becomes "non-colliding paths flow at once." I used this on jammed sequential crossings: one direction's clear but everything jammed, until I segmented the interior with chain signals and suddenly non-conflicting routes moved in parallel. The difference is subtle visually but huge operationally.

The trick: internal blocks only help when genuinely separate routes exist downstream. If all paths merge back together, extra blocks add complexity without benefit. So frame it as separating non-colliding flows, not "cut everything into pieces." That mental model makes the decision clearer.

For intuition, the factorio@jp Wiki intersection examples and "Getting Started with Factorio Railways (Chain Signals)" explain this well. Entrance + exit is phase one, internal flow-separation is phase two. Once you see "where do non-crossing paths diverge?" the block placement clicks.

Internal Splits for Parallel Non-Crossing Routes

The real trick with internal splitting is building in space for signals before deciding to split. Otherwise you want to divide but lack placement room, and you backslide to one giant block. Learn from my pain: think signal placement into your layout first.

The pattern: don't just stare at the intersection center. After a path branches or a crossing ends, reserve space for the next chain signal. This makes internal blocks feasible. If you cram curves and branches too tight for signals, you kill parallelism.

Practical approach:

1. Spot which routes never crash into each other
2. Leave room for a chain signal at each non-crossing boundary
3. Use this to separate non-colliding routes into their own blocks

Think ahead, signal placement becomes viable, and same-time flow becomes possible. Big multiplayer networks benefit hugely—being able to say "this path and that path never cross" and then have them both run at once is huge. Over-split intersections get unreadable, though. Aim for just enough splits so non-colliding routes are obvious, not "split everywhere."

Schematic thinking:

Bad
Path A ──┐
          ├─ Intersection (all one block)
Path B ──┘
→ Either path blocks the other

Good
Path A ──[Block 1]──┐
                    ├─[Block 2]
Path B ────────────┘
→ Non-crossing sections are separate, so Path A and Path B can move together

This helps most on consecutive or short-space intersections. Even well-done chain entrance/exit still bogs if internal competition is huge. Opening up the insides to parallel flows is the next lever.

Examples: T-Junctions, Cross-Intersections, and Sequences

T-Junction: Basic Chain-Entrance, Regular-Exit Form

T-junctions are the perfect place to lock down entrance-chain, exit-regular baseline. Self-evidently linear, and the idea that chain looks ahead before entering clicks fast. I finally understood "chain stops mid-crossing attempts" by watching a T-junction transform.

The bad version (regular entrances) is what happens most:

Bad
      S
      |
---- S+---- S
      |
      S

Trains slip in if the immediate next block is free, then wedge diagonally, blocking both the straight-through and the merge. One problem spawns three frozen directions. Upgrading just the entrances:

Better
      C
      |
---- C+---- S
      |
      S

Logic: see past the intersection on entry, stop outside if the path ahead is blocked. T-junctions get smooth. And I'm not exaggerating—the difference between bad and better is the single visible change in train behavior.

But T-junctions have an exception: if the exit immediately precedes another signal/crossing:

Bad: Short exit before the next crossing
      C
      |
---- C+---- S -- C+--
      |
      S

The train that exits T and enters the short zone stops mid-short-zone, still blocking T.

Fix: chain the T exit too, tying it to a real clear point:

Better: T exit also chained
      C
      |
---- C+---- C -- C+-- S
      |
      S

Now the T-exiting train doesn't enter until it can fully clear. This exception—chaining the "exit" when it's too short—is half the advanced pattern right there.

Cross-Intersection: Split Interior for Parallel Routes

Cross-junctions strain because you can have four directions and many pairs don't crash. But if interior is one block, any train blocks all non-crossing routes. Let me walk through bad → good.

Bad: one-giant-block interior:

Bad
        C
        |
--------[  Intersection  ]--------
        |
        C
        Output is S

C=chain, S=regular, [ ]=block boundary

North-south running? South can't go north, east can't go west, even when safe. Throughput tanks. Better: split interior:

Better
          C
          |
------[A]---[B]------
          |
          C
        Output is S

[A] and [B] are now separate blocks.

Visual on routes:

        North
        C
        |
West C --[A]--[B]-- C East
        |
        C
        South

N→S and E→W often collide.
N→E and S→W often collide.
But some sequences (like N→E then W→S) don't always overlap fully.

The magic: if you can separate routes that don't actually collide, they can move together. N→E and W→S, if your geometry allows, can run parallel because they don't share path.

The thing is: splits only help if truly independent downstream paths exist. If everything funnels back, more blocks just add puzzle-solving. So ask "do these routes actually avoid each other?" If yes, segment. If no, one block is fine.

I test this by pulling signals out entirely (back to one huge block), running trains, and watching them all freeze. Then re-add splits strategically and see non-colliding routes suddenly run together. It's a neat before-and-after that drives home the concept.

Consecutive Junctions: Chain Exit to Hold Back Until Safe

Consecutive junctions are the "original rule broke down" case. Temptation: first exit regular because "that's an exit." Reality: if the next junction is close, short-zoning trains between junctions paralyzes both.

Bad:

Bad: Junction A exit is regular
---- C + A + S ---- C + B + S ----

Train from A enters short zone, B blocks it, that train still blocks A.

Better:

Better: Junction A exit is also chain
---- C + A + C ---- C + B + S ----

The exiting train from A doesn't step into the risky zone until B's exit is clear. Consecutive junctions flow in sequence rather than getting wedged.

If interior splits help, even better:

Best: Interior split too
---- C + A + [Mid1] C [Mid2] + B + S ----

Non-colliding routes between A and B can now run parallel. The zone between A and B isn't a single giant "pass through or bust" block—it has breathing room.

Before/after is telling: bad = first train to enter A waits for B to fully open, and back-log starts; better = A and B have independent entry checking, so trains queue more naturally.

Common Mistakes and Fixes

Mid-Intersection Stops: Regular Entrance or Short Exit

Trains stopping in intersections usually have two causes: regular signal at entrance or not enough exit clearing space. Even if it looks like trains are past the exit, if they can't fit fully outside, that stop blocks the crossing.

Regular at entrance: trains see the crossing's first gap and enter. Exit full? Mid-intersection stop, and now everything downstream jams. Fix: swap entrance to chain, so pre-entry checking prevents the entry itself.

Short exit: even with chain entrance, if the exit only has room for a partial train, that partial stop blocks the first crossing. Fix: build bigger clearing space after the exit, or extend the chain signal further ahead, or add a stacker outside the intersection.

The mental flip: think about where trains actually end up parked. If a train parks inside the intersection, you've lost. If it parks outside, you're fine.

Non-Crossing Routes Also Frozen: Interior Too Coarse

"This pair of trains never collide, why do they queue?" usually means interior is one giant block. Routes that honestly don't touch each other still can't run together.

Solution: split interior blocks where non-colliding routes separate. Careful not to over-segment (clogs the map view), but enough so parallel paths are obvious. Interior blocks aren't about pretty—they're about letting simultaneous non-conflicting traffic flow.

See signal colors first—those are usually right. Blame the lack of speed on interior block size.

Bidirectional-Line Deadlock: Suggest One-Way Dual-Track

Bidirectional lines are convenient for short branches, but add train count and they're disaster. Mutual blocking (each direction waiting for the other) is classic bidirectional death. Multiplayer makes it worse—someone adds a station and suddenly the now-busy single line stalls everything.

I've seen this on servers: a bidirectional single-line merge blocks itself. Train A enters from one side, train B enters from the other, both approach the shared zone, and neither backs up. Full stop. Manual un-wedging works briefly, then repeats.

Realistic fix: convert the main line to one-way dual track. Direction fixed = no opposing-train waits, signal logic simplifies, deadlock-patterns drop off. Merges and branches become "same-direction flow management," not "also handle the reverse."

Throughput goes up, stability improves, and design pain drops. Bidirectional is cute while it works, but at scale it's fragile. One-way dual tracks is the safe scaling path.

Short Output Block: Fit Longest Train, or Don't Use Regular

Short output blocks are easy to miss and high-impact. Train looks like it exited but fully doesn't—rear is still in the intersection. This half-parked train becomes the network's anchor.

Especially bad on consecutive intersections or station-front branches: small clearing zone, regular signal, and trains sneak in, stop short, and paralyze both crossings.

**Fix: make clearing zones long enough for your longest train, or don't use regular signals.** Base this on actual measurements, not guesses. Multiplayer: if one player brings a 2-8 supply train and you designed for 2-4, that one train jams everything.

A reasonable safety margin: longest train + a signal-block width. If you can't fit that, make it a stacker outside the intersection, or chain further down the line. Intersection throughput is determined partly by intersection shape, partly by where trains are allowed (and not allowed) to stop.

Advancing Further: 2.0+ Interior Splitting and Next Steps

Interior Block-Splitting

Summary and Next Actions

Chain signal placement stabilizes on the three principles: chain signal at entries, rail signal at exits, chain signal to bridge short exits or consecutive intersections. This isn't the only valid approach, but it's powerful as a starting baseline. I also wandered off-course early on by layering exceptions, but once I locked in the baseline, deadlock causes became immediately visible. In practice, swapping intersections following the article's procedures cleared logistics backlogs in minutes on multiple occasions.

Checklist: Entry Chain / Exit Rail Verification

• Do all branches, merges, and intersection entries have chain signals?
• If the stretch after an intersection is long enough for a train to stop, is there a rail signal?
• If the exit is short or the next intersection is close, are chain signals bridging them?

Start with One T-Junction, Then Expand to Crossroads and Consecutive Intersections

Rather than fixing the entire main line at once, start with a single T-junction rebuilt to spec. Observe how trains stop there, then expand to crossroads and consecutive intersections. This minimizes mistakes.

Consider One-Way Double Track for Persistent Congestion

If congestion remains even after signal fixes, it's better to consider one-way double track rather than pushing signal placement further. Deciding "where to absorb jams" at the network level rather than the intersection level brings stability.