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

trains enter depot automatically even if they have "make jump if service (not) required"-order #6159

Closed
DorpsGek opened this issue Oct 29, 2014 · 7 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

deep42thought opened the ticket and wrote:

Hi,

for large capacity tracks I use a combination of waypoints and a conditional jump for servicing (see attached screenshot: waypoint "...# 3" is only reachable if the train goes through a depot).
However, if there's no "go to depot"-order in the orderlist of the train, it goes to automatic service.

I think, function Vehicle::HasDepotOrder() in order_cmp.cpp should return true, even if there's "only" a jump with a condition on "needs service".

Right now I have two workarounds:

  1. Make some unreachable depot-order (some orders; "allways jump to the order after the next"; go to any depot; more orders), which is a horrible hack.
  2. Put a "go to next depot"-order after the conditional jump, which leads to blocking of the tracks in some cases:
    Assume both depots are accessable, so the train picks depot A. But then (before it can reserve a path into depot A) a train from depot A moves out. Although depot B is free, it won't enter. Note, that there can be a lot of trains in both depots.

greetings,
Erich

P.S.: I am aware, that the screenshot is from a patched game, but openttd 1.4.4 shows the same effect.

Attachments

Reported version: 1.4.4
Operating system: All


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

planetmaker wrote:

Use once in the order list an order of "Service at depot XX" instead of "Service, if necessary".
Use of conditional orders (whatever condition) is not supposed to influence that the path finder at any other point of time than when the condition is evaluated (which is right after the previous order was completed).


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13598

@DorpsGek
Copy link
Member Author

deep42thought wrote:

The problem is, that for really large tracks (e.g. 4 lanes in each direction) a single depot, each train may go to for service, is a huge bottleneck.
Thus I want to avoid "go to any place which is only one tile"-orders (e.g. to a depot) completely.

Why shouldn't the type of condition (not if it is fulfilled) influence the pathfinder as the type of go-to-order does?
Because apparently in Vehicle::HasDepotOrder() it is evaluated, if any order is a go-to-depot-order, but not if any order is a condition on "needs service".


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13599

@DorpsGek
Copy link
Member Author

deep42thought wrote:

The attached patch leads to the desired behaviour.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13603

@DorpsGek
Copy link
Member Author

deep42thought wrote:

Now the comment is also updated.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13604

@DorpsGek
Copy link
Member Author

frosch wrote:

Trains go to depots when they are ordered. If they have no depot order in their orders, they do not intentionally go to a depot.
Your track layout uses "forced service" to make trains go to depot without being ordered.
A conditional order with condition "only when serviced" is in no correlation to a depot order. It makes absolutely no sense to prevent servicing only because there is a conditional order, except in your case of an "technically defect" track layout.

I think the correct solution for your problem is to insert a "go to nearest depot order" after the waypoint orders. This has the advantage that you can set the order to "only if service is needed", so you don't need "forced service". This is not possible with the "conditional order" + "forced service".

So, imho, your patch does not add functionality, but breaks some. What you are trying to achieve is already possible, even in a more flexible way, while the patch removes other options.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13605

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2014

deep42thought wrote:

It is correct, that you can put a "go to nearest depot"-order (with condition on "needs service" or with a conditional jump), but as explained above, trains ocassionally block the track even if there is an accessable depot (with the chosen layout there allways is).
I don't understand why a "only when needs service"-jump is in no correlation with going to depots. Can you give an example where you want to have such a jump but still automatically serviced vehicles?
I don't consider forced servicing a broken track layout, it is mentioned as a possible track layout in the wiki.

The attached screenshot illustrates the case, when the train blocks the main track:
Train 3 needs service and enters "the next" depot, which is "... # 3", from where train 1 leaves just after train 3 decides to go there. The same could happen with depot "... # 2", since there is train 2 waiting for departure.
The further the waypoint is from the depots, the more often the train chooses the wrong depot.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6159#comment13608

@DorpsGek
Copy link
Member Author

Alberth closed the ticket.

Reason for closing: Won't implement

Changing source code that affects a large number of players to fix a problem with a bad track layout doesn't seem a valid direction (ie if you have a bottleneck in depots, add more. If they go to the wrong one, add more or order them to specific depot)


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

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Vehicles 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