VariationalAction2/Houses
Variational Action 2 Variables for Houses
Variational Action 2 Variables for Houses
{maketoc}
||Variable|Version*|Size|Content
40| |B|Construction stage and pseudo-random values
41| |B|Age of the building in years (or, strictly speaking, the difference between the current year and the year the building was built). Returns 255 for buildings older than 255 years.
42|2.0.1a43|B|Town zone where the building is situated.
43| |B|Terrain type: 0 normal, 1 desert, 2 rainforest, 4 on or above snowline
44|2.0.1a43|D|Building counts
45|2.0.1a38|B|Town expansion bits
46|2.0.1a67|B|Current animation frame
47|2.6r2020 / r14294|D|XY Coordinate of the building
60|2.0.1a56|D|Other building counts
61|2.0.1a56|D|Other building counts
62|2.0.1a72|D|Land info for nearby tiles
63|2.6r1665|B|Current animation frame of nearby house tiles
64|2.6r1672|B|Cargo acceptance history of nearby stations
65| / r13603|B|Distance of nearest house matching a given criteria
80+x|None defined, and none ever will because town buildings don't have an internal structure. Trying to access these variables crashes TTD.||
<nowiki>*</nowiki> Specified version is earliest known to support the variable in its current form. Some variables may have been available earlier.
Construction stage and pseudo-random values (40)
||Bits|Meaning
0..1|Construction state: 0..2: various states of construction, 3: construction finished
2..3|A pseudo-random value. It isn't actually random, but is derived from the position of the building. Old buildings use this value to randomize their colors. TTDPatch has a better way to randomize things, but you can still use that value to mimic unpatched TTD behaviour. Note that adjacent tiles aren't guaranteed to have the same pseudo-random bits||
Town zone (42)
Town zone where the building is situated. The value is between 0 and 4, where 0 is the outermost zone of the town. Smaller towns have fewer zones. Roads are plain in zone 0 and 1, paved in zone 2, have trees in zone 3 and streetlights in zone 4
Building counts (44)
Returns dword LLllCCcc, where cc means how many buildings of the current type can be found in the current town, while CC is the same for the whole map. ll and LL are similar to cc and CC, but contain the number of tiles that have the same class as the current one. For tiles that have no class, ll and LL are always zero. Overridden old types are considered to be the new type they were overridden with. During callback 17, the current building isn't on the map yet, and therefore isn't counted. In other cases, the building count is at least one, since the current building is counted as well.
During callback 17, the current building isn't on the map yet, and therefore isn't counted. In other cases, the building count is at least one, since the current building is counted as well.
Town expansion bits (45)
||Bit|Value|Meaning
0|1|Set if TTD is currently creating a random town, clear otherwise. PLEASE NOTE: while TTD is generating a random town, town variables 82 (town population) and B6 (number of buildings) are incorrect. The population counter contains the population of buildings generated _yet_, which means the final value may be larger than you get. The building count variable, on the other hand, is surely higher than the final value will be. If you want to check these variables during callback 17, you may need to check variable 45 as well and make adjustments if this bit is set.||
Other bits are currently reserved for future use.
Current animation frame (46)
The current animation frame being displayed. If you don't use animation callbacks, it's between zero and the value set in property 1A. Animation callbacks can set this to anything between 0 and 127.
Enabling animation on a house tile by setting properties 9, 1A and probably 1B ensures that property 46 will indeed change with time, and the building is redrawn every time property 46 changes. This means that you can use a variational action 2 to choose the current frame according to property 46. Please note that this kind of animation needs more CPU time and more sprites, so you should prefer palette animation if possible.
XY Coordinate of the building (47)
The coordinate of the tile this part of the building is located. If the building is not yet constructed, like during callback 17, the returned value will be the proposed location. The format of the var is YYYYXXXX.
Other building counts (60, 61)
For variable 60, the parameter is an old house type number. For variable 61, it is a new house type number defined in the current GRF file.
These variables work like variable 44, but they count the given house type instead of the current one.
Please note that, unlike random graphics, changes of deterministic building graphics don't automatically redraw the building (except when either the construction state or property 46 changes), resulting in temporary graphics glitches when a visible building changes its graphics. These glitches can be fixed by scrolling the building out of view, then back again.
Land info for nearby tiles (62)
This variable works exactly like var. 60 for industry tiles, except that bit 0 of the bb part is undefined.
Current animation frame of nearby house tiles (63)
The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7, 8h=-8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. Although you can query a 16x16 area with these parameters, it's currently useless to use offsets other than -1, 0 and +1; if you query a tile that doesn't belong to the same building as the current tile, the result is meaningless. It may even be junk if the queried tile isn't a house tile at all.
Cargo acceptance history of nearby stations (64)
The parameter of this variable is a cargo identifier. If your GRF is version 7 or later and has a cargo translation table, this is an index to that table; otherwise, it's a cargo slot number. Additionally, GRF register 100h should contain an offset relative to the current tile (use 0 for the current tile). The returned value looks like this:
||Bit number|Meaning
0|This cargo was accepted in a nearby station some time in the past
1|This cargo was accepted in a nearby station last month
2|This cargo was accepted in a nearby station this month
3|This cargo was accepted in a nearby station since the last periodic processing (which happens every 250 ticks)
4|This cargo is one of the types that triggered callback 148 (only during callback 148)
other bits|undefined;reserved for future use||
A station is considered nearby if the selected tile is inside its acceptance area. That's why you can give an offset - other tiles of your multi-tile building may have different stations "nearby".
The information required for this variable is stored in the station2 structure, and therefore works only if the station2 structure is present. The station2 structure is present if any of the following is true:
- Generalfixes is on, and miscmods.noextendstationrange is off
- Any of fifoloading, newcargos or irregularstations is on
If the station2 structure isn't present, the returned value is always zero.
Distance of nearest house matching a given criteria (65)
The parameter of this variable is composed of two parts.
Bits 0..5 indicate the radius of the search that is going to be performed, which will be the biggest (Manhattan-)distance the system will search. The maximum search radius is 63 while the minimum is 1. A radius of 0 is considered reserved - do not use.
Bits 6..7 indicate the type of search been conducted :
0 : Search by House type as defined in the grf file
1 : Search by building class
2 : Search by grfID
The system will perform a circular search around the current tile, trying to find another house that will match same house type, class or simply grf id. (Note: Other tiles of the originating house will not match.) Once if has found it, the var will give the Manhattan distance from that tile to the center tile.
If no house matching the criteria is to be found, the var will be set to 0.
AS any search variable, be aware that it is a CPU intensive one
