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

Add: Option for a new transfer feeder payment algorithm #7935

Merged

Conversation

JGRennison
Copy link
Contributor

The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.

The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.

The feeder share setting applies in the existing way for both modes.

@ldpl
Copy link
Contributor

ldpl commented Jan 14, 2020

Doesn't need an option IMO. If it works better just use it, not like anyone would miss an old algorithm. Those profits are virtual anyway.

@michicc
Copy link
Member

michicc commented Jan 14, 2020

Indeed, as the transfer payment only affects vehicle statistics and not the real company profits, a setting is superfluous.

Either it is better (by some metric) than current, then it can just replace it, or it is worse. And if it would be worse, adding it is pointless.

The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.

The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.

The feeder share setting applies in the existing way.
@JGRennison
Copy link
Contributor Author

The setting has been removed, the savegame bump is no longer required.
The diff is now a bit shorter.

Copy link
Member

@LordAro LordAro left a comment

Choose a reason for hiding this comment

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

Just a bit shorter

@michicc michicc merged commit 2fee030 into OpenTTD:master Jan 28, 2020
@JGRennison JGRennison deleted the transfer-payment-profit-mode-setting branch January 9, 2024 19:17
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

5 participants