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]: Houses try to produce and receive Mail, even when no Mail cargo type exists in GRF #9715

2TallTyler opened this issue Nov 24, 2021 · 3 comments


Copy link

@2TallTyler 2TallTyler commented Nov 24, 2021

Version of OpenTTD


Expected result

When using a NewGRF industry set which does not define a Mail cargotype (Action0, Property 18 = 02) or have a cargo in the typical mail cargo ID of 2, houses do not attempt to produce Mail.

Actual result

When the game loads, the game calculates last month's cargo production for houses and industries, and shows the calculated mail generation in the town GUI — see #9714. Note that this only seems to happen for the months before the game is loaded, and not for any in-game months.


When using the land area information tool on houses, NewGRF houses which use cargolabels show cargo acceptance of mail as <invalid cargo> despite no MAIL cargo being defined. Other cargolabels like GOOD, if not defined, do not show up:


Vanilla houses have cargo acceptance hardcoded using cargo IDs instead of cargolabels, and show all accepted cargos whether or not it exists in the industry set, such as Goods:


This may be a separate issue, but it seems closely connected to me.

Steps to reproduce

  1. Use an industry set which doesn't define a Mail cargo, like Minimalist Industries, attached:
  2. Open the Town GUI for any town to see the calculated mail production. Note that this only seems to happen for the months before the game is loaded, and not for any in-game months.
  3. Use the (?) land area information tool to see the cargo acceptance of houses. For my bug report, I used my own Improved Town Layouts (available on Bananas).
Copy link
Member Author

@2TallTyler 2TallTyler commented Nov 24, 2021

Also, stations appear to monitor cargo acceptance for Mail and send a message when nearby houses provide 8/8 acceptance.



Copy link

@nielsmh nielsmh commented Nov 25, 2021

In my opinion, undefining the MAIL cargo type is distinctly moving into "don't do that" territory. There are some assumptions deep in the game about there being Passengers, Mail, Goods and Valuables cargo types, and then a series of variable other freight cargo types. Removing one of the core cargo types will have to be done in a total conversion style mod, that replaces all default vehicles, all default industries, and all default town houses, all at once.

I vote for not a bug.


Copy link
Member Author

@2TallTyler 2TallTyler commented Nov 25, 2021

Well, I'm using it alongside my house replacement set, so I am replacing all industries, cargos, and houses at once — albeit not in the same file. I suppose I could set the mail multiplier to 0 and use the production callback to produce mail, thus using the cargo label MAIL instead of the cargo ID 2.

Cargo acceptance of NewGRF houses uses cargo labels, but I've let some houses inherit cargo acceptance instead of defining it myself. That would fix this issue.

I disagree however that Passengers, Mail, Goods, and Valuables are all crucial to OpenTTD economies. Passengers, sure, because you can't have a game without houses, and while it would be theoretically possible to have houses with population but no passengers, I haven't found a compelling game design reason to attempt such silliness. 😛 But I haven't seen a NewGRF industry set which uses Valuables, and even Goods aren't used in several FIRS economies. I would argue that making Mail optional would be a useful goal for NewGRF development, and will likely try to close parts of these issues myself.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants