A train can deliver valuable cargo and still show a red payment. A feeder truck can show a healthy transfer credit without putting that money into your company account. Neither number, by itself, tells you whether the complete route deserves to survive.
First prove that the cargo reaches its destination. Then separate the payment for that delivery from the way OpenTTD divides credit between vehicles. Only after those checks should you decide whether to change the service or sell a vehicle.
This guide builds a one-way coal route using manual cargo distribution: trucks carry coal from a mine to a rail hub, then a train carries it to a power station. The same troubleshooting method applies to other manual freight chains. It is not a recipe for forcing transfer orders onto a two-way passenger network with automatic distribution.
Draw the three stops before buying more vehicles
Call the mine stop A, the transfer hub B and the receiving station C. There are two services, not one vehicle with three stops: the trucks repeat A–B, while the train repeats B–C.
At A, the station must collect coal from the mine. At C, the station must actually accept coal for delivery. Being visually close to the power station is not enough: inspect the station's cargo acceptance. Use coal-capable trucks and wagons, and ensure both services can reach their destinations.
At B, the truck loading bay and railway platforms must belong to the same logical station. Combined station components share a cargo pool. Two separate stops a short distance apart do not hand cargo across that gap merely because they look like one terminal.
Open each component and confirm that both lead to the same station window and cargo list. If they are separate, rebuild or join the relevant component as part of the intended station, within the station-spread rules. Do not demolish a working terminal just to experiment; save first and preserve the existing routes. The important result is a shared station, not a particular construction shortcut.
Give each stop a job
For this simple, coal-only chain, use the following loading and unloading settings. Select the relevant station order before changing it; an option attached to A does not repair B.
| Vehicle and stop | Loading setting | Unloading setting | Intended result |
|---|---|---|---|
| Truck at A, the mine | Full load all cargo | No unloading | Collect a coal load |
| Truck at B, the hub | No loading | Transfer | Leave coal for the train and return empty |
| Train at B, the hub | Load if available | No unloading | Collect waiting coal and continue |
| Train at C, the power station | No loading | Unload if accepted | Deliver coal, then return to B |
The train's initial loading choice deliberately makes the first delivery easy to observe. After the route works, you can choose a full-load condition at B if avoiding lightly loaded trips is worth the wait. A train waiting for a full load is not necessarily broken, but that wait belongs in your service plan.
Transfer and loading are separate decisions. Transfer does not mean “drop this cargo and never touch it again.” Without the no-loading setting, the feeder can pick cargo back up, including cargo it just deposited. At the final destination, use normal acceptance-based delivery rather than another forced transfer.
Follow the first load all the way through
Start with enough vehicles to demonstrate the chain, not an entire fleet. Watch one truck reach B. It should lose its coal load, the hub should gain waiting coal, and the truck should leave empty. Next, watch the train load from that same pool and carry coal to C.
At C, confirm that the coal is delivered rather than left waiting for another vehicle. Then confirm that the train returns to B. Your first success condition is a completed delivery cycle, not a yellow transfer figure at the hub.
If a step fails, stop diagnosing downstream symptoms. A train cannot solve cargo sitting in a different station's pool. Extra trucks cannot repair a train ordered to leave the hub without loading. Work forward from the last step that visibly succeeded.
Once that cycle works, watch several arrivals. A single successful transfer proves the connection; repeated cycles reveal whether the onward service keeps up.
Case 1: the truck returns with the coal
Suppose the truck reaches B and a transfer credit appears, but it heads back toward A carrying coal. Meanwhile, the train keeps leaving B empty.
Inspect the truck's B order first. If it permits loading, set that stop to transfer with no loading. Watch its next visit: the truck should depart empty and leave coal available at B. Do not add a second train to compensate for a truck that keeps taking its delivery away.
If the truck now leaves empty but the train still loads nothing, inspect the station identity. Coal under the road stop's name is not available at a separate railway station. If the station is genuinely shared, inspect the train's cargo capability and loading instruction next. These are different faults with the same outward symptom, so change only the setting or connection your observation identifies.
Case 2: the final train shows a red delivery figure
Transfer credits allocate part of the journey's apparent earnings to intermediate vehicles. They are not additional cash paid into the company account. At final delivery, OpenTTD calculates the actual cargo payment and subtracts the previously assigned feeder credits when attributing income to the delivering vehicle.
That attribution can be negative without the cargo delivery itself taking money out of the company.
Here is an illustrative accounting example, not a predicted payout for a particular map:
| Entry for the same cargo | Amount | Meaning |
|---|---|---|
| Earlier credit assigned to feeder vehicles | 1,450 | Virtual allocation, not extra company cash |
| Actual payment on final delivery | 1,200 | Delivery revenue received by the company |
| Income attributed to the final vehicle | −250 | 1,200 minus the earlier 1,450 credit |
The allocations reconcile: 1,450 − 250 = 1,200. Do not count the transfer credit and final delivery revenue as two separate earnings. Equally, do not conclude that the delivery lost 250 just because that is the final vehicle's attributed amount.
This still does not establish profit. Suppose the vehicles incurred 700 in running costs over the same measured period and earned 1,200 in actual delivery revenue. That leaves 500 before other relevant expenses. If their running costs were 1,350 instead, the route would be 150 behind before those other expenses. Construction, infrastructure costs and unrelated company activity also prevent a casual bank-balance glance from being a clean route-profit test.
Compare completed deliveries and costs over a consistent period. A reporting boundary can split a transfer and its later delivery between periods, so avoid judging the chain from a snapshot taken while much of its cargo is still travelling.
Case 3: every handoff works, but the hub keeps filling
Now suppose trucks leave empty, the train picks up coal and C accepts it, yet the pile at B grows across repeated train visits. The orders are doing their jobs. The next question is how much coal the onward service removes between feeder arrivals.
Watch the train's departure load. If it repeatedly leaves full while coal remains, examine its capacity and return interval. More suitable wagons or another train may help, provided the route and terminal can accommodate them. If it sits behind traffic or waits at an occupied platform, resolve that delay before sending another vehicle into the queue.
If the train repeatedly departs partly empty while coal remains in the same pool, revisit its cargo capability and order settings rather than assuming a capacity shortage. If the hub empties just after each train visit and then builds up again, you may be seeing normal batch collection rather than an ever-growing backlog. Compare the pile at the same point in successive cycles.
Your goal is not an empty hub at every moment. It is a chain that delivers its incoming cargo without a worsening queue or excessive waiting. Increasing feeder traffic alone can make the bottleneck larger while making the first leg look busier.
Repair the journey, not just the colour of the accounts
Cargo payment depends on cargo type, quantity, transit distance and time in transit. A longer piece of track is not a promise of higher earnings: detours and waiting can make a relay less useful. Before buying faster vehicles, look for time spent standing still and for unnecessary backtracking between the source, hub and destination.
The feeder-payment percentage changes how credit is allocated to intermediate vehicles. Lowering it may leave a healthier-looking amount for the final vehicle, but it does not repair a missed transfer, shorten a queue or remove running costs. Treat it as an accounting choice, not a route upgrade.
If automatic distribution is enabled
For cargo using automatic distribution, destinations and transfers are handled differently: cargo follows available connections toward assigned destinations, and ordinary connected services can transfer it without this manual one-way pattern. Inspect the station's next-hop information and the distribution network instead of copying the table above onto every stop.
Keep the distinction clear: manual freight handoffs need explicit intentions; automatic networks need usable connections and sufficient service along the journey.
Before selling the supposedly loss-making vehicle, answer three questions: does its cargo reach an accepting destination, is the red number an allocation or a real operating shortfall, and does the whole chain clear its workload? Those answers tell you what to fix—and whether removing that vehicle would break the delivery entirely.
Latest comments
Log in to join the conversation
Log InNo comments yet. Be the first to share your thoughts!