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

Orders: current order should be discard if orders are changed #5656

Closed
DorpsGek opened this issue Jul 17, 2013 · 6 comments
Closed

Orders: current order should be discard if orders are changed #5656

DorpsGek opened this issue Jul 17, 2013 · 6 comments
Labels
bug Something isn't working component: AI/Game script (squirrel) This issue is related to Squirrel (Scripting language) flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) needs triage This issue needs further investigation before it becomes actionable

Comments

@DorpsGek
Copy link
Member

krinn opened the ticket and wrote:

I have setup this as script bug, but it also affect humans, except humans can easy bypass this.

When openttd decide a vehicle should visit a depot, even if you change its orders openttd keep the order to visit the depot. And this has a nasty effect.

Vehicle cannot reach depot X
openttd decide to visit depot X
AI clear vehicle orders and look for a reachable depot
AI found depot Y to be reachable
AI sets orders to goto depot Y and stop
result: openttd keep sending vehicle to depot X, unreachable... And no, not even trying to SkipToOrder, or SendVehicleToDepot or any orders will force openttd to stop this crazyness.

For aircrafts, except loosing time, it also do that :
aircraft wish goes to airport at 10000m with a broken status (guess time to reach it)
ai change orders to send it to closest airport (say 100m away)
aircraft keep going 10000m away, visit the depot and then come back to where the AI ask it to go (but it was 100m away when ask, now aircraft is of course 10000m away from that point, at least it doesn't have the broken status because of the visit this time)
Of course 10000m isn't a real distance, but you get the picture. At least, aircraft will stop at a depot, not like bus & trucks that are lost for ever.

I guess trains would do the same, but it will be harder for a train to met that condition (having a non reachable depot in the line)

So if orders are changed, openttd should stop using depot visit order and get back to current order position or 0, anything but not keep that visit order.

Reported version: Version?
Operating system: All


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

Rubidium wrote:

OpenTTD won't decide that a vehicle goes to an unreachable depot. After all, it will only go to a depot when specifically ordered to, or when it is X pathfinder penalty from the depot. The former is the "user", the latter means it can't be unreachable unless you change the track layout.

If you do a go-to-depot order multiple times you'll cancel that depot order again, so I reckon you can cancel those orders by sending a depot order twice under the assumption that it didn't go that that depot, as then once should be enough.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5656#comment12423

@DorpsGek
Copy link
Member Author

krinn wrote:

When openttd decide to send a vehicle to a depot (even the vehicle have no depot order in its orders) because of depot visit for breakdown, if the depot became unreachable (easy, any collapse company can do that with bridge removed). Then openttd will keep sending that vehicle to this depot for ever.

As a human adding a goto depot order in its order list : no, openttd will keep the current order that is not in its order list to send it to that dead depot.
Only when the human hit goto depot order that current order will be cancel.

And it is not something an AI can do because of how AIVehicle.SendVehicleToDepot works :

- http://noai.openttd.org/docs/trunk/classAIVehicle.html# 5e332798a639b816c6efba170015ad8c
"If the vehicle has already been sent to a depot it continues with its normal orders instead. "
As you see, the vehicle is already going to a depot, an unreachable one but still a depot : so this won't works

- And the remain option is change orders in the vehicle order list, but as i say, this doesn't works for human, and doesn't for AI too : hence the "Current order should be discard if orders are changed".


This comment was imported from FlySpray: https://bugs.openttd.org/task/5656#comment12427

@DorpsGek
Copy link
Member Author

krinn wrote:

I must say it's strange but with openttd 1.3.2r(dunno) it seems fix, and openttd change current order and pickup another depot.

I was trying to build a savegame with proof of concept and change openttd version in between.
So it seems fix in that version.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5656#comment12428

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2013

krinn wrote:

Good (sad?) news, i have a savegame showing it:
Look at vehicle routier 214, 215, 14 & their brothers...

I'm sending you my current ai implementation so you could see the ai detect the problem, and change their orders to send them to a working (reachable) depot (Vichy 2), but alas, openttd discard those orders and keep sending the trucks to the unreachable depot.
(look at trucks orders, wait until the ai catch the orders are bad and redo the orders to a reachable depot)

I join my current ai implementation as i don't know if previous versions handle "unreachable target" in orders.
(i'm uploading the dependency to bananas)

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5656#comment12507

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) bug labels Apr 7, 2018
@andythenorth andythenorth added component: AI/Game script (squirrel) This issue is related to Squirrel (Scripting language) and removed Script labels Apr 13, 2018
@TrueBrain TrueBrain added needs triage This issue needs further investigation before it becomes actionable bug Something isn't working and removed bug from FlySpray labels Apr 14, 2018
@TrueBrain
Copy link
Member

To me, this sounds like a misunderstanding of mechanics. Click "goto depot" always cancels the going to depot. But we need to look at the savegame before jumping to any real conclusions :)

@andythenorth
Copy link
Contributor

Thanks for this. There's been no activity on this for some time, and as it stands, it doesn't look likely that it will go any further. I'm closing it as we try to keep the issue count low for OpenTTD, it helps us focus on things that are important and fun. Feel free to discuss in irc or request re-opening if you disagree. Thanks for contributing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component: AI/Game script (squirrel) This issue is related to Squirrel (Scripting language) flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) needs triage This issue needs further investigation before it becomes actionable
Projects
None yet
Development

No branches or pull requests

3 participants