FS#5671 - When facing undecidable orders vehicles may reload cargo they've just transfered at the same station

Attached to Project: OpenTTD
Opened by fonsinchen (fonsinchen) - Friday, 26 July 2013, 09:28 GMT
Last edited by fonsinchen (fonsinchen) - Sunday, 20 October 2013, 13:58 GMT
Type Bug
Category Vehicles → Cargodist
Status Closed
Assigned To fonsinchen (fonsinchen)
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Undecidable orders are orders that depend on load percentage. If Cargodist is enabled there is no general way of getting the loading algorithm right for vehicles whose next order depends on load percentage. Imagine a vehicle that has an order list like this:

1 Go to A and full load
2 Go to B
3 if load percentage > 50 jump to 6
4 Go to C
5 Jump to 1
6 Go to D

Now imagine the vehicle's cargo isn't accepted at B, so any cargo it carries goes either to C or D. Let the Cargo distribution algorithm decide that 60% of its cargo choose C as next hop at B, while the remaining 40% choose D. The vehicle could either transfer the cargo for C at B, then keep the cargo for D and actually go to C because of order 3. Or it could transfer the cargo for D, keep the cargo for C and go to D. Whatever it does is wrong.

As a pragmatic solution for half of this problem, when loading the vehicle will just load anything waiting at B for either C or D. The reasoning is that most of the time it's better to move the cargo than to let it sit in the station. The solution for unloading and transferring, however, is different. There the vehicle draws a random next hop from all available ones and acts as if it was going there. That is inconsistent, leading to cargo being reloaded.

In order to make loading and unloading/transferring consistent, the vehicle should keep all cargo going to either C or D and not transfer any of that at B.
This task depends upon

Closed by  fonsinchen (fonsinchen)
Sunday, 20 October 2013, 13:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r25891