This description uses "track-type" to refer to all 3 of "rail-type", "road-type" and "tram-type".

Motivation / Problem

Currently NewGRF vehicles can define a single track-type for their vehicles, which then decides what track-type they can drive on, and whether they are powered.

However, things are not always that binary. Dual-powered vehicles are compatible to multiple track-types and have different poweredness on them.
This extends from simple things like raising a pantograph when there is catenary, to changing vehicle power depending on whether there is electrification or whether the vehicle uses a secondary diesel engine.

Currently vehicle NewGRF can query the track-type of the current tile via var 4A. But this information is only usable when the NewGRF knows every track-type in existence.
This PR adds some variables to query some properties about the track-type on the current tile, so the vehicle NewGRF can essentially query the knowledge of the track-type NewGRF about track-type compatibility and poweredness.

Description

This PR adds two methods to solve above problems. A simple one for simple NewGRF, and a complex one for NewGRF which want to deal with the full complexity of track-type compatibility.

• Variable 4A is extended with a flag, that reports whether there is catenary on the current tile. This is usable in simple visual effects, like raising a pantograph, when the vehicle NewGRF is not interested in dabbling in complex track-types with different AC/DC voltages, i.e. whether the catenary actually provides usable power.
• A new variable 63 is added, that allows the NewGRF to query the track-type NewGRF about compatibility and poweredness wrt. track-types they both know about.
  • The parameter is an index into the vehicle NewGRF's track-type translation table. I.e. specifies a track-type that the vehicle NewGRF knows.
  • The result value reports everything the track-type NewGRF knows about this track-type in relation to the track-type on the current tile.
  • Bit 0: Set if the track-type NewGRF also knows the queried track-type.
  • Bit 1: Set if vehicles of the queried track-type are compatible to the track on the current tile.
  • Bit 2: Set if vehicles of the queried track-type are powered on the current tile.
  • Bit 3: Set if the queried track-type is equivalent to the track-type on the current tile.

Notes:

• If the queried track-type in unknown to the track-type NewGRF, the variables return 0. All flags unset.
• Bit 2 is the major use-case. Bit 1 is added for completeness sake, and is usable for exotic multi-gauge-compatible vehicles (?!), who knows... I am sure someone wants that.
• Road vehicles do not distinguish compatibility and poweredness, so bit 1 and 2 always have the same value. This is consistent with other variables.
• Bit 3 is different to comparing the track-type from variable 4A with a fixed track-type, since it also considers alternate labels of equivalent track-types.
• I did consider changing variable 4A to also check alternate labels, and return an equivalent track-type, when the vehicle NewGRF does not know the actual track-type. But I decided against it, since the vehicle NewGRF may know multiple track-types that are considered equivalent. Picking any one of them would mislead the vehicle NewGRF in believing those track-types were distinct, and would probably result in unintentional behavior, that would be hard to fix by the vehicle NewGRF.

Limitations

See description.

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 affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • PR must be added to API tracker