Action0/Global Settings

Action 0 properties for general variables

Action 0 - Properties for general variables

{maketoc}

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|Version|Size|Description

08|2.0.1 alpha 40|B|Cost base multipliers

09|2.0.1 alpha 66|D|Cargo translation table

0A|2.0.1 alpha 69|W|Currency display names

0B|2.0.1 alpha 69|D|Currency multipliers

0C|2.0.1 alpha 69|W|Currency options

0D,0E|2.0.1 alpha 69|D|Currency symbols

0F|2.0.1 alpha 69|W|Euro introduction dates

10|2.0.1 alpha 74|12*32*B|Snow line height table

11|OpenTTD (r12924)|2*D|GRF ID overrides for engines

12|OpenTTD (r15416)|D|Rail type translation table||

-=Comments=-

Cost base multipliers (08)

TTD has 49 base costs 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[[]]NewBaseCost[[ = ))OldBaseCost[[]]OldBaseCost[[ * 2<nowiki><pre></nowiki>(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.

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=-

~pp~// 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>

~/pp~

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.

Currency display names (0A)
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.

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.

GRF ID overrides for engines (11)
(OpenTTD only) Allows you to provide a list of 'source' and 'target' GRF IDs 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 GRF IDs. 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. GRF IDs 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)
(OpenTTD only) 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.