Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vehicles without orders can create links but can't serve them #5670

Closed
DorpsGek opened this issue Jul 26, 2013 · 7 comments
Closed

Vehicles without orders can create links but can't serve them #5670

DorpsGek opened this issue Jul 26, 2013 · 7 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

fonsinchen opened the ticket and wrote:

A train or road vehicle without orders will randomly visit stations around the map. It won't create any implicit orders as we don't know when it "wraps around" its order list. For each pair of subsequent visits it will create a link in the link graph between the stations it has visited. That may lead to cargo being routed along that link. However, even if the vehicle by chance visits the same link again it won't be able to pick up the cargo waiting for it as, due to the missing implicit orders, the order prediction algorithm cannot determine where it's going.

There are two possible solutions to that:

  1. Always set last_loading_station to INVALID_STATION if a vehicle has no orders. That will prevent the creation of links.
  2. Do create implicit orders for vehicles without explicit ones. That will enable the order prediction algorithm to correctly assign cargo to the vehicle.

Option 1 is pretty straight forward and easy. Option 2 is IMO the "right" way of doing it, but not trivial.

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/5670
@DorpsGek
Copy link
Member Author

fonsinchen wrote:

Allowing implicit orders in absence of explicit ones is surprisingly easy:

ulfhermann/openttd@5d38a4a

The first implicit order is added to the end rather than the beginning of the list, but this doesn't matter as order lists are cyclic by definition.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12449

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

The problem with creating implicit orders when there are no explicit ones is making sure that they're properly removed when the route changes. There is some code removing implicit orders that have seemingly been "skipped" on the way to the next explicit one. That would have to be extended to also "wrap around" the order list for implicit-only lists.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12453

@DorpsGek
Copy link
Member Author

frosch wrote:

I think there will always be a case where this fails.
If the trains drives in a circle, it needs every stop once.
If the train operates ping-pong on a line, it needs the stops in the middle twice.
If the train operates in more complicated shapes, it might need some stops four times, or about any number.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12454

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

The same case can be made for vehicles with explicit orders. You just need the complicated shape between explicit orders. We don't regard this as failure, though.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12455

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

It's true that with explicit orders you can have multiple implicit ones to the same station between two explicit ones. This is because the next explicit order provides a stopping point for the search algorithm.

ulfhermann/openttd@4a87b7f extends the previous patch so that the search wraps around even if there are no explicit orders and thus allows only one order to each station in the whole order list. This of course does not support e.g. "ping-pong" lines. In order to support those the wrap-around operation when searching for equal orders could be penalized a bit. One might wrap around only if the number of orders exceeds a certain value, expecting the orders to be truely random then. A good starting maximum number of "non-random" implicit orders may be 32. This is few enough to still scroll them but many enough to allow for pretty complicated orders. I could make that a setting.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12459

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

ulfhermann/openttd@705572a

This will do. If you have an implicit-only order list it will treat the last order in the list like an explicit one until it reaches a defined number of orders, currently 32 (I didn't make it a setting as hardly anyone will ever encounter that). If it reaches that number it will wrap around the list and also look for previous orders pointing to the same station. If one such order is found, the order index jumps to that order and deletes any orders it skips by that. You can have ping-pong or any kind of complicated implicit order lists like that as long as the total number of orders doesn't surpass 32. If it does it may still work, but every station can only occur once in the list then.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670#comment12460

@DorpsGek
Copy link
Member Author

fonsinchen closed the ticket.

Reason for closing: Fixed

In r25735


This comment was imported from FlySpray: https://bugs.openttd.org/task/5670

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Cargodist labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant