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

Fix 2f9c48b: [Linkgraph] Delete links served only by stopped or crashed vehicles #9499

Merged
merged 1 commit into from Aug 20, 2021

Conversation

nchappe
Copy link
Contributor

@nchappe nchappe commented Aug 18, 2021

Motivation / Problem

Links served only by stopped (or crashed) vehicles are not deleted from the linkgraph, so cargoes routed through such a link pile up waiting for vehicles that will never come.

Description

This PR adds a simple check for stopped and crashed vehicles in the link refresher.

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

@michicc
Copy link
Member

michicc commented Aug 18, 2021

The commit reference in the commit message feels wrong as this PR only touches the actual code from that commit very indirectly.

I'd also not call it a Fix but a Change, because immediately deleting links with only stopped or crashed vehicles is not as clear cut as it seems. Such a state might be only temporary e.g. because the player stopped all vehicles on a route for some track rework or because they need a few minutes to rebuild a crashed aircraft, and they will not be pleased that all cargo is rerouted.

Ideally, this check would include some kind of timeout, i.e. only delete the link if the state is persisting for some to-be-decided number of ticks/days. No idea if this would be an easy change or cause a complete rework of the link graph, though 😄 .

@nchappe
Copy link
Contributor Author

nchappe commented Aug 20, 2021

Thanks for the feedback, I pushed a more conservative version of this PR that focuses on vehicles stopped in depot for a long time. A vehicle in depot is now excluded from the list of vehicles serving a link if it has been more than 1024 days + the total duration of its order list since it last served an order. A delay of 1024 days after entering the depot would be safer, but this value is not stored anywhere.

As you pointed out there is always the possibility of a track rework that lasts three years and causes cargo to be re-routed to low-capacity secondary paths, I hope 1024 days of timeout is enough to make this drawback acceptable.

@michicc
Copy link
Member

michicc commented Aug 20, 2021

I guess you could bikeshed endlessly over the exact time, but 1024 days seems plenty enough for me.

@nchappe
Copy link
Contributor Author

nchappe commented Aug 20, 2021

I just found Vehicle::date_of_last_service, which is exactly what I needed, so I pushed a cleaner patch.

src/station_cmd.cpp Outdated Show resolved Hide resolved
…epot

A stale link is not deleted if the link refresher finds a vehicle that still serves it.
This commit excludes vehicles stopped in depot for a very long time from the link refresher,
so that their stale links can be deleted.
Copy link
Member

@michicc michicc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the pedantry.

@michicc michicc merged commit b83820e into OpenTTD:master Aug 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants