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

JGRennison commented Jan 14, 2020

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.

@JGRennison JGRennison force-pushed the JGRennison:transfer-payment-profit-mode-setting branch from fc21b0b to d1837ce Jan 28, 2020
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

JGRennison commented Jan 28, 2020

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

Copy link
Member

LordAro left a comment

Just a bit shorter

@michicc michicc merged commit 2fee030 into OpenTTD:master Jan 28, 2020
8 checks passed
8 checks passed
Commit checker
Details
OpenTTD CI Build #20200128.1 succeeded
Details
OpenTTD CI (Linux linux-amd64-clang-3.9) Linux linux-amd64-clang-3.9 succeeded
Details
OpenTTD CI (Linux linux-amd64-gcc-6) Linux linux-amd64-gcc-6 succeeded
Details
OpenTTD CI (Linux linux-i386-gcc-6) Linux linux-i386-gcc-6 succeeded
Details
OpenTTD CI (MacOS) MacOS succeeded
Details
OpenTTD CI (Windows Win32) Windows Win32 succeeded
Details
OpenTTD CI (Windows Win64) Windows Win64 succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.