Action0/Global Settings

Introduction

Global variables can be set in one of two ways. (This) action 0 using feature 8, or Action D. Variables in arrays will usually be set using an action 0, whereas action D will most commonly set single variables.

In addition to global variables, this action can also set some general grf-specific variables.

Properties

Number	Size	Version	Description
08	B	0.6 2.5	Cost base multipliers
09	D	0.6 2.5	Cargo translation table
0A	W	0.6 2.5	Currency display names
0B	D	0.6 2.5	Currency multipliers
0C	W	0.6 2.5	Currency options
0D,0E	D	0.6 2.5	Currency symbols
0F	W	0.6 2.5	Euro introduction dates
10	12*32*B	0.6 2.5	Snow line height table
11	2*D	0.7	GRFID overrides for engines
12	D	0.7	Rail type translation table
13,14	V	1.1  GRFv7	Gender/case translation table
15	B	1.1  GRFv7	Plural form

Descriptions

Cost base multipliers (08)

TTD has 49 base costs (66 in OpenTTD currently) which govern how much everything costs. Each cost is calculated from a (fixed) factor times the base cost, which is adjusted by inflation every month.

Setting this property allows changing these base costs by factors of two. The default value of the property is 08 which leaves the base cost unchanged. Adding one to the property doubles the base cost, subtracting one halves it.

Using math: NewBaseCost = OldBaseCost * 2^(n-8), where n is the value of property 08.

Modifying the base costs incurs a small rounding error every time the game is saved, because the costs have to be set back to the default in the savegame. However, this error is unnoticable until many years of inflation have passed and should therefore be of little concern.

1.0  In OpenTTD rounding happens towards 1 or -1 depending on the old base cost; i.e. if the old base cost is positive round towards 1, if negative round towards -1. This prevents the base cost to be zero.

Cargo translation table (09)

To aid with coding vehicle grf files that wish to support more than the standard cargo types, the easiest way is to install a cargo translation table using this property.

The cargo translation table is a list of cargo labels. Each entry means that the corresponding cargo is meant when using this ID in an action 3 or for a bit in the vehicle's refit mask.

In other words, if for example the fourth entry (number 03) in the list is "MAIL", then defining graphics for cargo 03 will define graphics for mail, and bit 3 in the refit mask will be for mail as well.

This way, the vehicle grf file doesn't need to know or care which cargo slot and cargo bit a certain cargo type uses, it can define its own ID for each cargo that it wishes to support, and thus be independent of both what cargo types are really available in the game and what slots/bits they use.

Because the refit mask contains only 32 bits, only the first 32 entries in the translation table can make use of the refit mask. Other cargo types have to be added via the cargo classes, so put the cargos that need exceptions to the cargo class based refitting first so that they can go in the refit mask.

Note that this property cannot be set incrementally, you must set all types in a single action 0 starting from ID 0.

See below for an example.

Example

// Cargo translation table
  1 * 169      00 08 01 29 00 09
          "COAL" "WATR" "RUBB" "MAIL" "OIL_" // 0-4
          "LVST" "GOOD" "CERE" "GRAN" "WHET" // 5-9
          "MAIZ" "WOOD" "WODT" "IORE" "CORE" // 10-14
          "STEL" "PLAS" "VALU" "GOLD" "DIAM" // 15-19
          "PAPR" "FOOD" "FRUT" "FISH" "WOOL" // 20-24
          "POTA" "SAND" "GLAS" "WDPR" "DYES" // 25-29
          "FERT" "OLSD" "RFPR" "VEHI" "PETR" // 30-34
          "BRCK" "SULP" "CMNT" "FICR" "LIME" // 35-39
          "MILK" // 40
// Train wagon that has special graphics for grain (8),
// wheat (9), maize (10) and cereals (7)
  2 * 29       03 00 01 1B 04
          08 <grain-cid> 09 <wheat-cid> 0A <maize-cid>
          07 <cereals-cid> <default-cid>
// Train wagon that has graphics for water (1), rubber (2),
// oil (4), petrol (34) and milk (40)
  3 * 31       03 00 01 1C 05
          01 <water-cid> 02 <rubber-cid> 04 <oil-cid>
          22 <petrol-cid> 28 <milk-cid> <default-cid>

Currency display names (0A)

This and the following properties can be used to modify currencies. Each of them can have IDs 0-18 (decimal), the IDs being ordered the same as in the Currency drop-down list.

This property allows changing currency names that are displayed in the Currency drop-down in the Game Options window. This property is a textID, and if you need to supply your own text, it must be a DCxx one.

Currency multipliers (0B)

The equivalent of 1 British pound in this currency, multiplied by 1000. For example, 1 GBP=2 USD, so this should be 2000 for US dollars. The multiplication by 1000 allows you to have decimals in the multiplier without requiring floating-point calculations. This value is used for display purposes only, TTD always uses British pounds for internal calculations.

Currency options (0C)

The low byte of this word specifies the thousands separator to be used for this currency ( usually dot "." or comma ","). The high byte should be zero if the currency symbol should be in front of the number ($123,456) and should be 1 if the currency symbol should be shown after the number (123,456$). The symbol placement can be overridden by the TTDPatch settings.

Currency symbols (0D,0E)

These doublewords are interpreted as a string of up to 4 characters. If you need fewer characters, the remaining bytes should be zero. Property 0D is printed before the number, property 0E is printed after the number. These two usually differ only if the symbol is separated by a space from the number (for example, "$ " vs. " $"). You should specify both properties since the player can override your preferred symbol placement.

Euro introduction dates (0F)

This value allows you to have Euro introduced instead the currency at a given time. If this value is zero, the currency is never substituted with the Euro (USD, for example). If it's nonzero, it gives the year when the currency is replaced by Euro (for example, 2002 for DM).

Snow line height table (10)

This property allows you to specify the snow line height for every day of the year. The only ID you can set is 0, and the value must be 12*32=384 bytes long. To simplify things for the patch, every month has 32 entries, and the impossible combinations (like 32th January or 31th April) will never be read. The entries should be a multiply of 8 or else some visual glitches may appear. Values below 10h and above EFh may result in overflow and should not be used. Since the highest possible land is 78h high, giving 88h or above will effectively disable the snow line.

 2.5 If the temperate snow line is enabled, this table applies on temperate as well.

WARNING: Some code in TTD assumes that the snow line will remain constant: Some industries are built only above/below snowline and assume that the snow line won't move when they're already built. Similarly, snowy houses on arctic will still appear snowy even when the snow disappears around them. If you want to use this feature, make sure to counter these effects by overriding arctic houses and industries with snow-aware versions.

GRFID overrides for engines (11)

Allows you to provide a list of 'source' and 'target' GRFIDs to let engines in the source GRF override those in the target GRF, when dynamic engines is enabled. Each entry is 8 bytes, containing two GRFIDs. Multiple entries can be used, and different GRFs can be set to override the same 'target' GRF, but only the last instance of a 'source' GRF is active. GRFIDs that are not present will have no effect.

The scope of this feature is quite limited and it should be used only for sets that modify data of another set, for example the DBSetXL ECS addon for DBSetXL, or the censored version of LV4.

Rail type translation table (12)

Provides ability to specify rail types via a translation table, similar to using a cargo translation table. Each rail type label is a DWord. The default labels are RAIL, ELRL, MONO and MGLV. If a table is installed, then changing engine traction type will not affect the rail type.

Gender/case translation table (13,14)

Provides ability to specify genders or cases via a translation table. These map NewGRF internal IDs for the genders or cases to the genders or cases as defined in OpenTTD's language files so NewGRF strings and OpenTTD strings can interact on eachother's gender or cases. Property 13 is for mapping genders whereas property 14 is for mapping cases.

The ID used for these translation tables is the Action 4 (GRF version 7 or higher) language-id, i.e. this mapping only works with GRF version 7 or higher. Language-id 7F (any) is not allowed. You can can define an ID multiple times in which case the new mappings are simply appended to the already known mappings.

The format is simply a 00 terminated list of mappings:

(<id> <name>)+ 00

Size	Name	Meaning
B	id	NewGRF internal ID for the gender or case name, may not be 00
V	name	A 00 terminated string with the gender or case name as in OpenTTD's translation

An NewGRF internal ID may be mapped multiple times for the same language as may an OpenTTD gender or case name be (reverse) mapped multiple times. This can be used for coping with OpenTTD translators adding or removing genders or cases over time. The NewGRF internal ID may not be 00 as this ID will be used in the Action 4 strings which may not contain 00 except for terminating the string.

These mappings are used for StringCodes 9A 0E, 9A 0F, 9A 13 and 9A 14. How the mapping is used precisely can be found there.

Plural form (15)

Defines the plural form for a language. The ID used is the Action 4 (GRF version 7 or higher) language-id, i.e. this only works with GRF version 7 or higher. Language-id 7F (any) is not allowed. More information about the different valid plural forms can be found on the StringCodes page. This property is used for StringCode 9A 15.