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

Jump to bottom

stub order management #4440

Closed
DorpsGek opened this issue Jan 24, 2011 · 2 comments
Closed

stub order management #4440

DorpsGek opened this issue Jan 24, 2011 · 2 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

alocritani opened the ticket and wrote:

a bug report and two suggestions.

first suggestion: if a stub order should be inserted after last not-stub order at the moment it's inserted as first order.
maybe the order could be added indeed as the last one

second suggestion: add possibility to convert stub (automatic) order to normal order, maybe ctrl+click on the order or something similar.

bug, now: in attached savegame a bit of confusion arises with maintenance order: when skipped, stub order is created at first position, since maintenance order is the last one.
while not skipped, stub order is created just before maintenance order. for a while, until one of the orders disappears, you have duplicate orders

Attachments

Reported version: trunk
Operating system: All

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

Rubidium wrote:

Suggestion 1 seems void; stub orders are added before the "current" order. This is the most logical for insertions at least; you reach a station that you didn't go to. For removal the station would simply be removed when the station is removed which leaves the route changing as only other case, which with the current method is guaranteed to get fixed by the second "cycle". When you add stub orders after all automatic orders, as you suggest, then it will add those orders but remove them again when it reaches the next ordered station. Something similar will happen with adding stub orders before all stub orders as you said it behaves (but doesn't).

Ctrl is used to go to the location of the station/order, so that doesn't quite work. Maybe some button can be reused for that, but not sure how that will end up.

The actual bug is somewhat tricky and I don't really have a clue (yet) how to solve this particular case. In any case it is quite a corner case that can also be (easily) fixed by moving the depot; after all moving that far when it is due for a service is "asking" for (breakdown) trouble. I'm not even sure whether to classify it as a bug of the system or a bug of the network design.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4440#comment9533

@DorpsGek
Copy link
Member Author

frosch closed the ticket.

Reason for closing: Fixed

in r21933

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

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

No branches or pull requests
1 participant
@DorpsGek