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

Change: Cargo type is label #11719

Merged
merged 1 commit into from Feb 4, 2024
Merged

Conversation

PeterN
Copy link
Member

@PeterN PeterN commented Jan 8, 2024

Motivation / Problem

CargoType is landscape specific, so values change depending on which climate is selected, and it is used for default cargos of engines, industries and houses.

These default cargo types are not mapped at all, so if a NewGRF disables a cargo slot, or moves it from one slot to another, incorrect or invalid cargo can be produced.

There are 4 ways to identify cargo types:

  • CargoType - climate specific cargo types, up to 12 per climate. Some climates have holes.
  • CargoLabel - FourCC labels, defined for default cargo types, and used for setting up cargo for each climate, but otherwise only used by NewGRFs.
  • bitnum - obsolete, nobody cares, except 0xFF is used to disable a cargo slot.
  • CargoID - game-dependent cargo types, up to 64 cargo types, varies depending on newgrf configuration.

This is too many.

Description

This PR completely removes CargoType. Default engines, industries and houses are defined in terms of their cargo label which, for convenience, are defined using the same names as the CargoType enum, e.g. instead of CT_PASSENGERS = 0, CT_PASSENGERS = 'PASS'.

This means that passengers no longer has to be defined as slot 0, nor mail as slot 2. Core cargo types can now be moved or undefined without causing invalid cargo to appear.

This is built on top of #11378, which already removes hardcoded town cargo types.

Limitations

Possibly breaks some ancient cargo NewGRFs that don't define labels?

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR touches english.txt or translations? Check the guidelines
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, game_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

src/newgrf.cpp Fixed Show fixed Hide fixed
Copy link
Member

@2TallTyler 2TallTyler left a comment

Choose a reason for hiding this comment

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

Do NewGRF cargos inherit from base game cargos based on the chosen ID? (Similar to houses, industrytiles, etc.) And if so, does this break anything related to this?

src/cargo_type.h Outdated Show resolved Hide resolved
src/cargo_type.h Outdated Show resolved Hide resolved
src/industry_gui.cpp Outdated Show resolved Hide resolved
@PeterN
Copy link
Member Author

PeterN commented Jan 8, 2024

Do NewGRF cargos inherit from base game cargos based on the chosen ID? (Similar to houses, industrytiles, etc.) And if so, does this break anything related to this?

Cargoes directly edit the base game cargoes (after being copied from the original const definitions to the runtime definitions) by slot number, rather than making copies, so I don't think there will be any breakages there.

@PeterN
Copy link
Member Author

PeterN commented Jan 9, 2024

Parts of this draft are now in #11720 in a revised form, and this draft should be considered as depending on that PR too—this breaks all the changes into more manageable logical pieces.

Comment on lines +100 to +103
{ CT_PASSENGERS, CT_COAL, CT_MAIL, CT_OIL, CT_LIVESTOCK, CT_GOODS, CT_GRAIN, CT_WOOD, CT_IRON_ORE, CT_STEEL, CT_VALUABLES, 33, },
{ CT_PASSENGERS, CT_COAL, CT_MAIL, CT_OIL, CT_LIVESTOCK, CT_GOODS, CT_WHEAT, CT_WOOD, 34, CT_PAPER, CT_GOLD, CT_FOOD, },
{ CT_PASSENGERS, CT_RUBBER, CT_MAIL, 4, CT_FRUIT, CT_GOODS, CT_MAIZE, 11, CT_COPPER_ORE, CT_WATER, CT_DIAMONDS, CT_FOOD, },
{ CT_PASSENGERS, CT_SUGAR, CT_MAIL, CT_TOYS, CT_BATTERIES, CT_CANDY, CT_TOFFEE, CT_COLA, CT_COTTON_CANDY, CT_BUBBLES, CT_PLASTIC, CT_FIZZY_DRINKS, },
Copy link
Contributor

@rubidium42 rubidium42 Feb 3, 2024

Choose a reason for hiding this comment

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

I'm not quite sure about this. I do not think the 33 and 34 ever meant something, so maybe use CT_INVALID instead?
The numeric tropic data seems to be respectively CT_OIL and CT_WOOD based upon https://newgrf-specs.tt-wiki.net/wiki/CargoDefaultProps. Or is there a good reason not to have them mapped?

Copy link
Member Author

@PeterN PeterN Feb 3, 2024

Choose a reason for hiding this comment

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

For tropic, they are labels that are reused, but the stats are different from the first definition. 33 & 34 map to be unused slots with different data, that NewGRF could rely on being set. (Unlikely but possible)

This should be set up the same way as before, if not that's a bug.

Copy link
Contributor

Choose a reason for hiding this comment

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

Looking further into this I've got the feeling this is a hot mess, but can't think of any reasonable solution to make it any better. Making it a variant at least helps a bit in noticing there might be vastly different behaviour.

rubidium42
rubidium42 previously approved these changes Feb 3, 2024
Comment on lines +100 to +103
{ CT_PASSENGERS, CT_COAL, CT_MAIL, CT_OIL, CT_LIVESTOCK, CT_GOODS, CT_GRAIN, CT_WOOD, CT_IRON_ORE, CT_STEEL, CT_VALUABLES, 33, },
{ CT_PASSENGERS, CT_COAL, CT_MAIL, CT_OIL, CT_LIVESTOCK, CT_GOODS, CT_WHEAT, CT_WOOD, 34, CT_PAPER, CT_GOLD, CT_FOOD, },
{ CT_PASSENGERS, CT_RUBBER, CT_MAIL, 4, CT_FRUIT, CT_GOODS, CT_MAIZE, 11, CT_COPPER_ORE, CT_WATER, CT_DIAMONDS, CT_FOOD, },
{ CT_PASSENGERS, CT_SUGAR, CT_MAIL, CT_TOYS, CT_BATTERIES, CT_CANDY, CT_TOFFEE, CT_COLA, CT_COTTON_CANDY, CT_BUBBLES, CT_PLASTIC, CT_FIZZY_DRINKS, },
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking further into this I've got the feeling this is a hot mess, but can't think of any reasonable solution to make it any better. Making it a variant at least helps a bit in noticing there might be vastly different behaviour.

Cargo types of default engines, industries and houses are now specified in terms of label.
@PeterN
Copy link
Member Author

PeterN commented Feb 3, 2024

Re-ordering of CalculateRefitMasks() and FinaliseEngineArray() broke automatic cargo types for default vehicles, so this has been put back to how it was before, and the mapping from default CargoLabel to CargoID is done in CalculateRefitMasks() instead.

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

4 participants