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

[Bug]: Inflation breaks negative cargo payments #9440

Closed
2TallTyler opened this issue Jul 13, 2021 · 3 comments
Closed

[Bug]: Inflation breaks negative cargo payments #9440

2TallTyler opened this issue Jul 13, 2021 · 3 comments

Comments

@2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Jul 13, 2021

Version of OpenTTD

OpenTTD 1.11.2, Windows 10

Expected result

My NewGRF industry set, Industries of the Caribbean, uses negative cargo rates set in the NML properties (not the profit callback, where a known issue exists).

When Inflation is disabled, this works as intended. A cargo delivery like that in the savegame attached below costs the company about -£50.

Actual result

When Inflation is enabled, that -£50 cargo delivery instead gives £205 million.

Steps to reproduce

A user provided this savegame illustrating the issue.
IOTC_inflation_bug.zip

When a new map is started with Inflation disabled and the same set of NewGRFs, the profit works as intended.

@James103
Copy link
Contributor

@James103 James103 commented Jul 13, 2021

Can you please check the cargo payment rates graph as well pre- and post-inflation and post your findings?

Loading

@2TallTyler
Copy link
Member Author

@2TallTyler 2TallTyler commented Jul 13, 2021

As intended, without inflation:
no_inflation

With inflation:
inflation

Loading

@James103
Copy link
Contributor

@James103 James103 commented Jul 13, 2021

I can tell that the erratic cargo payment rate is highly dependent on the least significant bits (i.e. fractional part) of the inflation income factor. If the inflation income factor is an integer, normal behavior is exhibited, but if the inflation income factor is not an integer, that very easily leads to the erratic behavior shown. For example, there is an overflow in the cargo payment rates for imported cargoes that is triggered when the inflation income factor is greater than 0.5 (modulo 1.0):

For comparison, cargo payment rates where the inflation income factor is set to exactly 1.00000:
image

Cargo payment rates where the inflation income factor is set to exactly 1.00003:
image

Cargo payment rates where the inflation income factor is set to exactly 1.50000:
image

Cargo payment rates where the inflation income factor is set to exactly 1.50003:
image

Cargo payment rates where the inflation income factor is set to exactly 1.99999:
image

Cargo payment rates where the inflation income factor is set to exactly 2.00000 is the same as with 1.00000, just the magnitudes are doubled.

...

Cargo payment rates where the inflation income factor is set to exactly 10,000.501:
image
(notice that the absolute value of the highest / lowest paying cargo is within 0.1% of the other extreme-case graphs)

Loading

rubidium42 added a commit to rubidium42/OpenTTD that referenced this issue Jul 22, 2021
Cargo payments were stored as unsigned integer, but cast to int64 during
application of inflation. However, then being multiplied with a uint64
making the result uint64. So in the end the payment that should have been
negative becomes hugely positive.
rubidium42 added a commit that referenced this issue Aug 2, 2021
Cargo payments were stored as unsigned integer, but cast to int64 during
application of inflation. However, then being multiplied with a uint64
making the result uint64. So in the end the payment that should have been
negative becomes hugely positive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants