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

Diagonal income disparity #6121

Closed
DorpsGek opened this issue Sep 21, 2014 · 5 comments
Closed

Diagonal income disparity #6121

DorpsGek opened this issue Sep 21, 2014 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

Aphid opened the ticket and wrote:

Trains can travel on diagonals, and so can ships and aeroplanes. By the pythagorean theorem we know that the speed of a train on a diagonal is about 0.707v horizontal and vertical where v is its nominal speed when travelling orthogonally.

However, income is calculated based on manhattan distance. Thus a train that travels diagonally will have its effective earning capacity increased by about 41.4%. This means that the topology of the land has an undocumented significant effect on the efficiency and profitability on railroad networks. When using newGRF to balance the game more tightly this effect becomes more pronounced. It is also very pronounced when trying to optimize gameplay, such as on the many popular 'goal' servers.

I consider this a 'bug' of sorts because it is weird, 'gamey' behaviour.

This patch adds a setting which allows you to select 'manhattan' or 'balanced' income settings. The 'balanced' will calculate distance like how a plane flies (minus circling the airports).
This patch has no effect on perfectly orthogonal railway lines, while diagonal lines will have their income reduced to match that of equally long straight lines.

Attachments

Reported version: trunk
Operating system: All


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

Alberth wrote:

The patch just does not completely eliminate the problem, it reduces the impact from 41.4 to 8.9 percent. Also, the optimal 'profit' position moves.

import math

best = -1
for dx in range(100):
for dy in range(100):
# real distance
rd = math.sqrt(dxdx + dydy)
md = min(dx, dy)
# plane distance
pd = math.sqrt(2) * md + (max(dx, dy) - md)
assert pd >= rd
dv = pd - rd
if dv > best:
bx, by, best = dx, dy, dv
print(dx, dy, best)

The above program gives 45 99 8.892196544438136


This comment was imported from FlySpray: https://bugs.openttd.org/task/6121#comment13531

@DorpsGek
Copy link
Member Author

Alberth wrote:

There is a small calculation error in my percentages, dx=45, dy=99 gives a real distance of 108, reducing the 8.9% above to 8%.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6121#comment13537

@DorpsGek
Copy link
Member Author

Aphid wrote:

The above math fails to account for the fact that all vehicles in openTTD can move only in 8 directions.

Thus the minimum distance from A to B is actually given by the sum of the lengths of two line sections; a section at angle of 45 degrees and a straight section, and not the pythagorean theorem. As long as the profit calculation distance equates to the minimum distance map topology no longer has an effect on income. As a matter of fact, using the true euclidian distance would actually result in purely orthogonal or diagonal lines being better than lines that have to 'mix' the two track pieces to get to their destination due to not being able to build freeform track sections.

For example, a train that travels 50 squares north, and 100 squares east, will not travel 111.803 squares, because it is not possible to lay a direct rail. Instead, it will travel at least 120.711 squares (50 * sqrt(2) + 50). That's where the strange 'plane distance' formula comes in.

I'm still not happy with how this behaves with road vehicles though. But having RVs on the old calculation and trains on the new opens possibilities of exploits. (dumping all cargo on a road station for a diagonal line, then using road vehicles to deliver one more tile and get the diagonal bonus for trains again).


This comment was imported from FlySpray: https://bugs.openttd.org/task/6121#comment13541

@DorpsGek
Copy link
Member Author

Aphid wrote:


This comment was imported from FlySpray: https://bugs.openttd.org/task/6121#comment13542

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 2, 2017

andythenorth closed the ticket.

Reason for closing: Won't implement

Changing the original core gameplay is not a current goal for OpenTTD.

Flyspray clean up, there's no obvious way forward for this, so closing. Thanks Aphid.


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

@DorpsGek DorpsGek closed this as completed Sep 2, 2017
@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Development

No branches or pull requests

1 participant