Add: Support for NewGRF badges.

[PeterN]

Add support for NewGRF badge feature in OpenTTD/OpenTTD#13073

Use badge_table { } to create the translation table.
Use badges property to assign a list of badges to an entity.

See 042_badges.nml for slightly more info.

[PeterN]

The regression test 042_badges will add a badge to the "Chaney 'Jubilee' (Steam)" engine, which will appear like so:

[WenSimEHRP]

Checking badges on a nearby tile for now would require something like this

switch(FEAT_STATIONS, SELF, _sw_check_yard_p1n1, [
    STORE_TEMP(1, 0x100),
    STORE_TEMP(bitmask(4), 0x101),
    var[0x79, 0, 0x1, 0xF1]]){return;}

better if we can simplify it to

nearby_tile_has_badge(x, y, badge, features)

whereas features is bitmask(FEAT_1, FEAT_2, ...)

[andythenorth]

action 0 flags...
badge_flags.patch

[andythenorth]

badge_error_line_num.patch

More than happy to push these patches to my fork for cherrypick, but eh, they're tiny.

[frosch123]

Most of the variables are missing from NFO docs. This one is also missing from OTTD implementation at least for rail/road/tram types.

[andythenorth]

This appears to be implemented now (Iron Horse uses has_badge on railtypes).

[andythenorth]

Been using this for Iron Horse since the PR opened, works for me.

[audigex]

No warning/error is thrown when creating a FEAT_BADGES item, whereby the label is not in the badgetable. Unless I'm msissing something here, I can't think why I would define a badge item that isn't in the badge table (and therefore isn't used on a vehicle?

I'm not sure if that should be considered an error, but it certainly feels like something that should trigger a warning since it's most likely a typo

[audigex]

A similar "A warning would be nice" situation

If I have a badge eg "power/steam", but no "power" badge defined, the "power/steam" badge does show up in the newGRF debug menu but doesn't show up in the purchase menu as either a sprite or text. If the user's intention was to add text that's kinda obvious ("Power: steam" can't displayed if "Power" doesn't exist to have text), but it's a little counter-intuitive if the user is mostly thinking about adding a sprite but didn't want text

I assume this is a limitation of the implementation in OpenTTD rather than NML, but it would be good if NML threw a warning if a nested badge was defined without a parent badge already being defined

[PeterN]

No warning/error is thrown when creating a FEAT_BADGES item, whereby the label is not in the badgetable. Unless I'm msissing something here, I can't think why I would define a badge item that isn't in the badge table (and therefore isn't used on a vehicle?

I'm not sure if that should be considered an error, but it certainly feels like something that should trigger a warning since it's most likely a typo

Much like defining railtypes and roadtypes, there's no requirement to use badges when defining them. Maybe you wanted to make a collection of badges to be used in other NewGRFs. A badge table is only required to use badges, not to define them.

It's also not an error to not define a class badge.

[audigex]

No warning/error is thrown when creating a FEAT_BADGES item, whereby the label is not in the badgetable. Unless I'm msissing something here, I can't think why I would define a badge item that isn't in the badge table (and therefore isn't used on a vehicle?

I'm not sure if that should be considered an error, but it certainly feels like something that should trigger a warning since it's most likely a typo

Much like defining railtypes and roadtypes, there's no requirement to use badges when defining them. Maybe you wanted to make a collection of badges to be used in other NewGRFs. A badge table is only required to use badges, not to define them.

It's also not an error to not define a class badge.

Lots of other NML warnings aren't really errors, either ... that's the point of a warning, surely? "You might be doing this intentionally but there's a good chance you aren't, maybe take a look?"

[PeterN]

Fixed the naming of flag BADGE_FLAG_USE_COMPANY_COLOUR (previously was BADGE_FLAG_NAME_USE_COMPANY_COLOUR)
Added new flag BADGE_FLAG_NAME_SKIP

[Rito13]

Why the limit here is only 64000 and not UINT16_MAX like the other limits?
Especially when the badge_id in the OpenTTD source code is uint16_t.

[rubidium42]

Because if you ever need an extra 'special' ID for some feature, having a range of IDs that are unused is way easier than lowering the limit as you need to write extra logic to remove the badges with that special ID.

Even then, if 64000 seems way too much to me. The idea it to be able to filter with them, and if you need more than a few hundred I'd argue that the categories are way too fine grained.

[audigex]

Because if you ever need an extra 'special' ID for some feature, having a range of IDs that are unused is way easier than lowering the limit as you need to write extra logic to remove the badges with that special ID.

Even then, if 64000 seems way too much to me. The idea it to be able to filter with them, and if you need more than a few hundred I'd argue that the categories are way too fine grained.

The original intention/idea may have been for filtering, but as with anything else in the newGRF spec, authors have rapidly found other uses (abuses) for them - eg using them to identify train classes, coupler types, special coaches etc to affect push pull, running costs, and other special functionality

64000 is still probably plenty, but people will use more than you intuitively think if you expect them to mostly be used for filtering

Resolved

[2TallTyler]

Several people have tested this over the last few months, and 15.0 is out now. I think it's time for a YOLO approval. (Someone smarter than me can decide whether to do a YOLO merge. 😉)

Also, someone will need to add to NML docs. Does not have to be @PeterN. 🙂