https://newgrf-specs.tt-wiki.net/api.php?action=feedcontributions&user=Terkhen&feedformat=atomGRFSpecs - User contributions [en-gb]2024-03-29T12:11:01ZUser contributionsMediaWiki 1.35.13https://newgrf-specs.tt-wiki.net/index.php?title=NML:Bridges&diff=3362NML:Bridges2013-03-18T17:07:02Z<p>Terkhen: Specify that bridges are not implemented.</p>
<hr />
<div>Bridges are currently not implemented in NML.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=NML:Main&diff=3184NML:Main2012-05-11T16:38:02Z<p>Terkhen: Correct a typo.</p>
<hr />
<div><div style="float:right; padding-left:12px; background:none;">{{NMLNavMain}}</div><br />
<br />
;[[NML:Preface |Preface]]<br />
;[[NML:changes 0.3|Changes between NML 0.2 and head / 0.3]]<br />
;[[NML:Getting started|Getting started]]<br />
;[[NML:Graphic files|Graphics files]]<br />
<br />
;[[NML:Block syntax|Language structure and block syntax]]<br />
*[[NML:GRF|GRF]] and its parameters<br />
*[[NML:Item|Item]] (Properties, graphics, livery overrides)<br />
<br />
*;Defining sprites:<br />
**[[NML:Realsprites|Realsprites]]<br />
**[[NML:Template|Template]]<br />
**[[NML:Base Graphics|Base Graphics]]<br />
**[[NML:Spriteset|Spriteset]]<br />
**;Replacing sprites:<br />
***[[NML:Replace TTD sprites|Replace TTD sprites]]<br />
***[[NML:Replace new sprites|Replace new sprites]]<br />
***[[NML:Add font glyphs|Add font glyphs]]<br />
***[[NML:Alternative sprites|Alternative sprites]] (32bpp, zoom levels)<br />
**;Aranging and grouping sprites:<br />
***[[NML:Spritegroup|Spritegroup]] (Vehicles)<br />
***[[NML:Spritelayout|Spritelayout]] (Houses, industries, stations, airports)<br />
***[[NML:Recolour sprites|Recolour sprites]]<br />
<br />
*;Flow control<br />
**[[NML:Tilelayout|Tilelayout]]<br />
**[[NML:Switch|Switch]]<br />
**[[NML:Produce|Produce]]<br />
**[[NML:Random switch|Random switch]]<br />
<br />
*;Global scope<br />
**[[NML:Cargotable|Cargotable]]<br />
**[[NML:Railtypetable|Railtypetable]]<br />
**[[NML:Snow line|Snow line]]<br />
**[[NML:Setting base costs|Setting base costs]]<br />
**[[NML:Parameter assignment|Parameter assignment]]<br />
**[[NML:If|If/else]]<br />
**[[NML:While|While]]<br />
<br />
*;Interaction with other grfs<br />
**[[NML:Error|Error]]<br />
**[[NML:Disable items|Disable items]]<br />
**[[NML:Deactivate other NewGRFs|Deactivate other NewGRFs]]<br />
**[[NML:Testing for other NewGRFs|Testing for other NewGRFs]]<br />
**[[NML:Overriding vehicles in other NewGRFs|Overriding vehicles in other NewGRFs]]<br />
<br />
*;Misc<br />
**[[NML:Town names|Town names]]<br />
**[[NML:Town names parts|Town names parts]]<br />
<br />
;[[NML:Units|Units]]<br />
;[[NML:Expressions|Expressions]]<br />
*[[NML:Elementary values|Elementary values]]<br />
*[[NML:Builtin functions|Builtin functions]]<br />
;[[NML:Language files|Language files]]<br />
;[[NML:Properties and variables and callbacks|Lists of properties, variables and callbacks]]<br />
{|<br />
|[[NML:General|General]] || || [[NML:General#General variables|variables]] || <br />
|-<br />
|[[NML:Vehicles|Vehicles]] || [[NML:Vehicles#Properties common to all vehicle types|common properties]] || [[NML:Vehicles#Vehicle variables|variables]] || [[NML:Vehicles#Vehicle callbacks|callbacks]]<br />
|-<br />
| || [[NML:Vehicles#Train properties|train properties]] || || <br />
|-<br />
| || [[NML:Vehicles#Road vehicle properties|road vehicle properties]] || || <br />
|-<br />
| || [[NML:Vehicles#Ship properties|ship properties]] || || <br />
|-<br />
| || [[NML:Vehicles#Plane properties|aircraft properties]] || || <br />
|-<br />
|[[NML:Stations|Stations]] || [[NML:Stations#Station properties|properties]] || [[NML:Stations#Station variables|variables]] || [[NML:Stations#Station callbacks|callbacks]]<br />
|-<br />
|[[NML:Canals|Canals]] || [[NML:Canals#Canal properties|properties]] || [[NML:Canals#Canal variables|variables]] || [[NML:Canals#Canal callbacks|callbacks]]<br />
|-<br />
|[[NML:Bridges|Bridges]] || [[NML:Bridges#Bridge properties|properties]] || [[NML:Bridges#Bridge variables|variables]] || [[NML:Bridges#Bridge callbacks|callbacks]]<br />
|-<br />
|[[NML:Towns|Towns]] || || ||<br />
|-<br />
|[[NML:Houses|Houses]] || [[NML:Houses#House properties|properties]] || [[NML:Houses#House variables|variables]] || [[NML:Houses#House callbacks|callbacks]]<br />
|-<br />
|[[NML:Industries|Industries]]|| || [[NML:Industries#Common variables|common variables]] || <br />
|-<br />
| || [[NML:Industries#Industry properties|industry properties]] || [[NML:Industries#Industry variables|industry variables]] || [[NML:Industries#Industry callbacks|industry callbacks]]<br />
|-<br />
| || [[NML:Industries#Industry tile properties|tile properties]] || [[NML:Industries#Industry tile variables|tile variables]] || [[NML:Industries#Industry tile callbacks|tile callbacks]]<br />
|-<br />
|[[NML:Cargos|Cargos]] || [[NML:Cargos#Cargo properties|properties]] || [[NML:Cargos#Cargo variables|variables]] || [[NML:Cargos#Cargo callbacks|callbacks]]<br />
|-<br />
|[[NML:Airports|Airports]] || [[NML:Airports#Airport properties|properties]] || [[NML:Airports#Airport variables|variables]] || [[NML:Airports#Airport callbacks|callbacks]]<br />
|-<br />
| || [[NML:Airports#Airport tile properties|tile properties]] || [[NML:Airports#Airport tile variables|tile variables]] || [[NML:Airports#Airport tile callbacks|tile callbacks]]<br />
|-<br />
|[[NML:Objects|Objects]] || [[NML:Objects#Object properties|properties]] || [[NML:Objects#Object variables|variables]] || [[NML:Objects#Object callbacks|callbacks]]<br />
|-<br />
|[[NML:Railtypes|Railtypes]] || [[NML:Railtypes#Railtype properties|properties]] || [[NML:Railtypes#Railtype variables|variables]] || [[NML:Railtypes#Railtype callbacks|callbacks]]<br />
|}<br />
;[[NML:Warnings|Compiler Warnings]]<br />
;[[NML:Additional references|Additional references]]<br />
*[[NML:Animation speed|Animation speed]]<br />
*[[NML:Default industries|Default industries]]<br />
*[[NML:Default industry tiles|Default industry tiles]]<br />
*[[NML:Base cost table|Base cost table]]<br />
*[[NML:List of sound effects|List of sound effects]]<br />
*[[NML:List of default vehicle IDs|List of default vehicle IDs]]<br />
*[[NML:List of default house properties|List of default house properties]]<br />
*[[NML:List of town zones|List of town zones]]<br />
*[[NML:List of tile classes|List of tile classes]]<br />
*[[NML:List of default colour translation palettes|List of default colour translation palettes]]<br />
*[[NML:List of direction constants|List of direction constants]]<br />
*[[NML:List of tile slopes|List of tile slopes]]<br />
*[[NML:List of tiles|List of tiles]]<br />
*[[NML:Default TTD strings|Default TTD strings]]<br />
*[[NML:Deprecated syntax|Deprecated syntax]]<br />
;[[NML:NewGRF compatibility|NewGRF compatibility]]<br />
;[[NML:Old style callbacks|Old-style callbacks]]<br />
<br />
<br />
[[NML:Manual of style|Manual of style]]</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=NML:Cargos&diff=2508NML:Cargos2011-08-25T16:46:42Z<p>Terkhen: Correct conversion factor for the profit callback.</p>
<hr />
<div>{{NMLNavPropVarCB}}<br />
<br />
==Cargo properties==<br />
<br />
{| class="t"<br />
! name<br />
! value range<br />
! comment<br />
|-<br />
| number<br />
| 0..31<br />
| Number of the cargo for bitmasks.<br />
|-<br />
| type_name<br />
| string<br />
| TextID for the cargo type name. Example string: "Passengers"<br />
|-<br />
| unit_name<br />
| string<br />
| TextID for the name of one unit from the cargo type. Currently used for subsidies only (First Passenger service to..). Example string: "Passenger"<br />
|-<br />
| single_unit_text<br />
| string<br />
| TextID to be displayed for 1 unit of cargo. Example string: "{WORD_S} ton of Stuff"<br />
|-<br />
| multiple_units_text<br />
| string<br />
| TextID to be displayed for multiple units of cargo. Example string: "{WORD_S} tonnes of Stuff"<br />
|-<br />
| type_abbreviation<br />
| string<br />
| TextID for cargo type abbreviation. Example string: "{TINYFONT}XX"<br />
|-<br />
| sprite<br />
| sprite<br />
| TTD sprite number for the icon of the cargo. Alternatively, set to NEW_CARGO_SPRITE and use a graphics block to define a custom sprite.<br />
|-<br />
| weight<br />
| float 0..255<br />
| Weight of one unit of the cargo (in tons)<br />
|-<br />
| penalty_lowerbound<br />
| 0..255<br />
| Delivery time until penalty is applied<br />
|-<br />
| single_penalty_length<br />
| 0..255<br />
| Length of the interval where a single penalty is applied<br />
|-<br />
| price_factor<br />
| float<br />
| Payment for delivering 10 units of cargo across a distance of 20 squares (in British Pounds).<br />
|-<br />
| station_list_colour<br />
| 0..255<br />
|<br />
Colour for the station list window (index from the [[NML:Graphic files|DOS palette]])<br />
|-<br />
| cargo_payment_list_colour<br />
| 0..255<br />
|<br />
Colour for the cargo payment list window (index from the [[NML:Graphic files|DOS palette]])<br />
|-<br />
| is_freight<br />
| 0 or 1<br />
| Freight status (for the freighttrains switch); 0=not freight, 1=is freight<br />
|-<br />
| cargo_classes<br />
|<br />
bitmask([[#Cargo classes|cargo classes]])<br />
| Cargo classes<br />
|-<br />
| cargo_label<br />
| 4 letters<br />
| Cargo label, as used in the cargo table<br />
|-<br />
| town_growth_effect<br />
| TOWNGROWTH_XXX<br />
|<br />
Effect for town growth, see [[#Cargo effects on town growth|Cargo effects on town growth]]<br />
|-<br />
| town_growth_multiplier<br />
| float 0..255<br />
| Multiplier for town growth. To be used in conjuction with town_growth_effect, when that is not TOWNGROWTH_NONE. For example, a value of 4 makes your cargo have the same effect on town growth as 4 units of food/goods/etc.<br />
|-<br />
| callback_flags<br />
| bitmask(flags)<br />
|<br />
Do not set this, unless you use [[NML:Old style callbacks|old-style callbacks]].<br />
|}<br />
<br />
Cargo payment is computed from <code style="color:darkgreen">price_factor</code>, amount of cargo transported, distance, and a time delivery factor. Unit of the delivery time is 185 ticks, roughly 2.5 days. The factor is constant (with value 255) if delivery time is less than <code style="color:darkgreen">penalty_lowerbound</code>. It goes down with rate 1 between <code style="color:darkgreen">penalty_lowerbound + single_penalty_length</code>, and goes down with rate 2 if the delivery time is even longer. Time delivery factor is never less than 31.<br />
<br />
===Cargo classes===<br />
<br />
Available cargo classes are listed in the following table. Cargos may be in more than one class. To combine multiple cargo classes, use the builtin function bitmask. For example, <code style="color:darkgreen">bitmask(CC_EXPRESS, CC_REFRIGERATED)</code> is used for food.<br />
<br />
{| class="t"<br />
! name<br />
! type of cargo<br />
|-<br />
| CC_PASSENGERS<br />
| passengers, also tourists (ECS)<br />
|-<br />
| CC_MAIL<br />
| mail<br />
|-<br />
| CC_EXPRESS<br />
| express goods, also tourists (ECS)<br />
|-<br />
| CC_ARMOURED<br />
| valuables, diamonds, gold and alike<br />
|-<br />
| CC_BULK<br />
| coal, ore, grain,...<br />
|-<br />
| CC_PIECE_GOODS<br />
| containers, crates, livestock<br />
|-<br />
| CC_LIQUID<br />
| oil, milk, water, ...<br />
|-<br />
| CC_REFRIGERATED<br />
| food, milk, ...<br />
|-<br />
| CC_HAZARDOUS<br />
| chemicals?, uranium, ...<br />
|-<br />
| CC_COVERED<br />
| grain, cement, fruit, ...<br />
|-<br />
| CC_OVERSIZED<br />
| vehicles, ...<br />
|-<br />
| CC_SPECIAL<br />
| Special cargo, used for refit tricks. (e.g. regearing in NARS)<br />
|-<br />
| NO_CARGO_CLASS<br />
| Special value that you can used to instead of 0.<br />
|-<br />
| ALL_NORMAL_CARGO_CLASSES<br />
| Bitmask of all cargo classes except CC_SPECIAL. This is the same as <code style="color:darkgreen">bitmask(CC_PASSENGERS, CC_MAIL, ..., CC_OVERSIZED)</code>. Note: This is already a bitmask, don't use the <code style="color:darkgreen">bitmask(..)</code> function with this.<br />
|-<br />
| ALL_CARGO_CLASSES<br />
| Bitmask of all cargo classes. Same as <code style="color:darkgreen">ALL_NORMAL_CARGO_CLASSES | bitmask(CC_SPECIAL)</code> Note: This is already a bitmask, don't use the <code style="color:darkgreen">bitmask(..)</code> function with this.<br />
|}<br />
<br />
===Cargo effects on town growth===<br />
<br />
{| class="t"<br />
! value<br />
! effect<br />
|-<br />
| TOWNGROWTH_PASSENGERS<br />
| Affect towns as passengers do<br />
|-<br />
| TOWNGROWTH_MAIL<br />
| Affect towns as mail does<br />
|-<br />
| TOWNGROWTH_GOODS<br />
| Affect towns as goods/candy does<br />
|-<br />
| TOWNGROWTH_WATER<br />
| Affect towns as water does (second required cargo for towngrowth in the desert)<br />
|-<br />
| TOWNGROWTH_FOOD<br />
| Affect towns as food/fizzy drinks do (first required cargo for towngrowth in desert/above snowline)<br />
|-<br />
| TOWNGROWTH_NONE<br />
| Don't affect town growth (default)<br />
|}<br />
<br />
==Cargo variables==<br />
<br />
Cargos have no variables (yet).<br />
<br />
==Cargo callbacks==<br />
<br />
{| class="t"<br />
! callback<br />
! return value<br />
! comment<br />
|-<br />
| default<br />
| Sprite set (with 1 sprite)<br />
| Graphics for the cargo icon (only if property <code style="color:darkgreen">sprite</code> is set to NEW_CARGO_SPRITE)<br />
|-<br />
| station_rating<br />
| -16384 .. 16383<br />
| See detailed explanation below<br />
|-<br />
| profit<br />
| -16384 .. 16383<br />
| Called whenever cargo is delivered. <code style="color:darkgreen">extra_callback_info2</code> contains <code style="color:darkgreen">0xttaadddd</code> with <code style="color:darkgreen">tt</code> being the time spent en-route (1 unit = 2.5 days), <code style="color:darkgreen">aa</code> the amount of cargo delivered and <code style="color:darkgreen">dddd</code> the manhattan distance it was transported. The returned value is multiplied by the amount and the <code style="color:darkgreen">price_factor</code> and then divided by 199,21875 to determine the income the player receives. Returning negative values is possible, it makes players pay for the delivery.<br />
|}<br />
<br />
===Station rating callback===<br />
<br />
The station rating callback is quite complicated and deserves some detailed explanation. The default station rating calculation works as follows:<br />
<br />
Internally, station rating is byte with values 0 .. 255, representing respectively 0% and 100%. Every 2.5 days, the transportation 'performance' is calculated using some factors outlined below. The station rating is then set to this performance value, with the caveat that the rating change cannot exceed 2 points. Therefore, rating changes are always slow, this callback cannot change this. The initial rating is 175 points (69%). The following factors are parts of the performance, their effects are summed.<br />
<br />
====Time since the cargo was last picked up====<br />
<br />
{| class="t"<br />
! Time units (days)<br />
! Score (%, rounded)<br />
|-<br />
| &gt;21 (&gt;52.5 days)<br />
| 0 (0%)<br />
|-<br />
| 13 .. 21 (32.5 days .. 52.5 days)<br />
| 25 (10%)<br />
|-<br />
| 7 .. 12 (17.5 days .. 32.5 days)<br />
| 50 (20%)<br />
|-<br />
| 4 .. 6 (10 days .. 17.5 days)<br />
| 95 (37%)<br />
|-<br />
| 0..3 (0 days..10 days)<br />
| 130 (51%)<br />
|}<br />
<br />
The time unit used equals 185 engine ticks, or 2.5 TTD days. For ships, the time units are divided by 4 before calculating this component, so ships have four times more time before the ratings start dropping.<br />
<br />
====Amount of cargo waiting====<br />
<br />
{| class="t"<br />
! Amount of cargo<br />
! Score (%, rounded)<br />
|-<br />
| &gt;1500<br />
| -90 (-35%)<br />
|-<br />
| 1001..1500<br />
| -35 (-14%)<br />
|-<br />
| 601..1000<br />
| 0 (0%)<br />
|-<br />
| 301..600<br />
| 10 (4%)<br />
|-<br />
| 101..300<br />
| 30 (12%)<br />
|-<br />
| 0..100<br />
| 40 (16%)<br />
|}<br />
<br />
====Max. speed of the last vehicle picking up the cargo====<br />
<br />
This calculation is somewhat complicated. The maximum speed of the vehicle is expressed in "speed units". For trains and road vehicles, the speed unit is 1 km/h; for ships, it's 0.5 km/h; for aircraft, it's 8 mph. If the max. speed is above 255 speed units, 255 is used instead. If the vehicle is slower than 85 units, no points are awarded; otherwise, you get (speed_units-85)/4 points. Therefore, the maximum you can get is 42 points, or 16%.<br />
<br />
====Age of the last carrier picking up the cargo====<br />
<br />
{| class="t"<br />
! Age of vehicle (years)<br />
! Score (%, rounded)<br />
|-<br />
| 2<br />
| 10 (4%)<br />
|-<br />
| 1<br />
| 20 (8%)<br />
|-<br />
| 0<br />
| 33 (13%)<br />
|}<br />
<br />
In TTDPatch this changes when the 'newagerating' switch is enabled<br />
<br />
====Bonus for AI companies (TTDPatch only)====<br />
<br />
{| class="t"<br />
! AI intelligence setting<br />
! Score (%, rounded)<br />
|-<br />
| Low<br />
| 0 (0%)<br />
|-<br />
| Medium<br />
| 31 (12%)<br />
|-<br />
| High<br />
| 63 (25%)<br />
|}<br />
<br />
====Bonus for statue in nearest town====<br />
<br />
If your company has erected a statue in the nearest town, you get 26 points (10%) bonus to all cargo ratings.<br />
<br />
====Effect of callback====<br />
<br />
The return value of the callback replaces the first three components (time since pickup, amount of cargo, max speed) of the calculation. The bonus for statues, TTDPatch AIs and new vehicles is always in effect, you cannot (yet) change this.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=2156Storages2011-07-29T11:05:21Z<p>Terkhen: Clarify that nothing else can modify the temporary storage during the execution of a chain</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
{{ottdp|0.6|2.6}}<br />
<br />
'''Size:''' 00 - FF (256) (from TTDPatch r1246 to r1301) or 00 - 10F (272) (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first 256 registers 00 to FF can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values (100 to 10F) are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized. During the execution of a chain, only that chain can modify the values in the temporary storage.<br />
<br />
===Persistent storage===<br />
{{ottdp|0.6|2.6}}<br />
<br />
'''Size:''' 00 - 0F (16)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.<br />
<br />
===Persistent storage accessed by GRFID===<br />
{{ottdp|1.2|ottdrev=r22569}}<br />
<br />
'''Size:''' 00 - FF (16) for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns (since OpenTTD r22569)<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1774GRFSpecs:Todo2011-06-18T14:48:44Z<p>Terkhen: "About" page missing</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2 Towns''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''16/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2 Towns]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''Page to be created''<br />
| ''Description of the 00-3f, 40-5f, 60-7f, 80-ff [[VarAction2Advanced]] variable ranges. Comment about why most 80-FF variables are not documented. Also mention the relation between VarAction2 and Action6/7/9/D variables.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[SpriteLayouts]]''<br />
| ''Move the general explanation (without syntax) for spritelayouts, sprite&recolour flags and bounding boxes for [[Action0Stations#Sprite_layout_.2809.29 | Stations]] and [[Action2HousesIndustryTiles | Houses/Industries/Airports/Objects]] to a separate page. Also incorporate examples for typical configurations for stations with track and normal buildings (e.g. [http://www.tt-forums.net/viewtopic.php?f=26&t=43236 | this general advice]).<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[RealSprites]]''<br />
| ''Add [http://www.tt-forums.net/viewtopic.php?f=26&t=38122&p=666637#p666637 further explanations and recommendations] about sprite compressions.<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''[[IndustryTypes]]''<br />
| ''This page seems to be superfluous. Everything is on [[IndustryDefaultProps]] except for the special cases of the [[Callback: AI construction/purchase selection | AI callback]]. Maybe they should just be moved to the callback.''<br />
| ''Available''<br />
| ''16/06/2011''<br />
| ''16/06/2011''<br />
|-<br />
| ''[[RandomAction2]]''<br />
| Check descriptions for airports and airports tiles. They seem to use the same bits as stations, but without triggers yet.<br />
Also unify the naming of the section headings (but also fix the links on the main page if you change them). Which triggers apply to industries, which to industry tiles?<br />
| ''Available''<br />
| ''18/06/2011''<br />
| ''18/06/2011''<br />
|-<br />
| ''[[GRFSpecs:About]]''<br />
| Write an "About" page for the NewGRF specs.<br />
| ''Available''<br />
| ''18/06/2011''<br />
| ''18/06/2011''<br />
|}<br />
<br />
We should come up with a list of usable categories for the pages, thus that some overview / content pages can be auto-generated<br />
Suggestions:<br />
* VarAction2<br />
* Action0 (Action0Trains, Action0RoadVehicles, ...)<br />
* Actions (Action 0, Action 1, ...)<br />
* Default values (like vehicle IDs, tile IDs, cargo labels...)<br />
<br />
Should page names change to be "better" and more wiki-like: VarAction2Houses -> VarAction2 Houses etc?<br />
According to http://meta.wikimedia.org/wiki/Pywikipediabot/movepages.py it seems that it would not be a massive amount of work.<br />
<br />
==Examples to be Written==<br />
<br />
Examples should be short, well commented and clearly show how to use the featured item. See [[VarAction2Objects#Examples]]<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1664GRFSpecs:Todo2011-06-17T18:49:12Z<p>Terkhen: TownZones page done by planetmaker</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2 Towns''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''16/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2 Towns]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''Page to be created''<br />
| ''Description of the 00-3f, 40-5f, 60-7f, 80-ff [[VarAction2Advanced]] variable ranges. Comment about why most 80-FF variables are not documented. Also mention the relation between VarAction2 and Action6/7/9/D variables.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[SpriteLayouts]]''<br />
| ''Move the general explanation (without syntax) for spritelayouts, sprite&recolour flags and bounding boxes for [[Action0Stations#Sprite_layout_.2809.29 | Stations]] and [[Action2HousesIndustryTiles | Houses/Industries/Airports/Objects]] to a separate page. Also incorporate examples for typical configurations for stations with track and normal buildings (e.g. [http://www.tt-forums.net/viewtopic.php?f=26&t=43236 | this general advice]).<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[RealSprites]]''<br />
| ''Add [http://www.tt-forums.net/viewtopic.php?f=26&t=38122&p=666637#p666637 further explanations and recommendations] about sprite compressions.<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''15/06/2011''<br />
|-<br />
| ''[[IndustryTypes]]''<br />
| ''This page seems to be superfluous. Everything is on [[IndustryDefaultProps]] except for the special cases of the [[Callback: AI construction/purchase selection | AI callback]]. Maybe they should just be moved to the callback.''<br />
| ''Available''<br />
| ''16/06/2011''<br />
| ''16/06/2011''<br />
<br />
|}<br />
<br />
We should come up with a list of usable categories for the pages, thus that some overview / content pages can be auto-generated<br />
Suggestions:<br />
* VarAction2<br />
* Action0 (Action0Trains, Action0RoadVehicles, ...)<br />
* Actions (Action 0, Action 1, ...)<br />
* Default values (like vehicle IDs, tile IDs, cargo labels...)<br />
<br />
Should page names change to be "better" and more wiki-like: VarAction2Houses -> VarAction2 Houses etc?<br />
According to http://meta.wikimedia.org/wiki/Pywikipediabot/movepages.py it seems that it would not be a massive amount of work.<br />
<br />
==Examples to be Written==<br />
<br />
Examples should be short, well commented and clearly show how to use the featured item. See [[VarAction2Objects#Examples]]<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Stations&diff=1558VariationalAction2/Stations2011-06-16T18:20:09Z<p>Terkhen: Fix some formatting</p>
<hr />
<div>==Introduction==<br />
<br />
== Variables ==<br />
{| |-<br />
!Variable!!Version!![[GRFActionsDetailed|'''Size''']]!!Description<br />
|-<br />
|40||||D||Platform info and relative position<br />
|-<br />
|41||||D||Platform info and relative position for individually built sections<br />
|-<br />
|42||||D||Terrain and track type<br />
|-<br />
|43 *||||D||Player info, see [[VarAction2Vehicles#Player info 43|vehicle variable 43]]<br />
|-<br />
|44||||B||Path-based signalling info<br />
|-<br />
|45||||W||Rail continuation info<br />
|-<br />
|46,47||||D||Platform info, counted from the middle<br />
|-<br />
|48||||D||Bitmask of accepted cargos<br />
|-<br />
|49||||D||Platform info and relative position of same-direction section<br />
|-<br />
|4A||||B||Current animation frame<br />
|-<br />
|60||||D||Amount of cargo waiting<br />
|-<br />
|61||||D||Time since the cargo was last picked up<br />
|-<br />
|62||||D||Rating of the cargo<br />
|-<br />
|63||||D||Time spent en-route<br />
|-<br />
|64||||W||Information about the last vehicle picking this cargo up<br />
|-<br />
|65||||B||Amount of cargo acceptance<br />
|-<br />
|66||||D||Animation frame of nearby tile<br />
|-<br />
|67||||D||Land info of nearby tiles<br />
|-<br />
|68||||D||Station info of nearby tiles<br />
|-<br />
|69||||D||Information about cargo accepted in the past<br />
|-<br />
|80||||B||Number and length of train platforms<br />
|-<br />
|F0||||B||Bit mask of facilities attached to station (not appropriate for irregular stations)<br />
|-<br />
|FA||||W||Date when station was built in days since 1920<br />
|}<br />
<br />
<nowiki>*</nowiki> Available in the purchase list as well (since 2.5 beta 2).<br />
<br />
For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_StationArray||TTD station structure]. Note that you have to subtract 0x10 from the offsets there, or else the facility bit mask and construction date would not be accessible; instead you lose access to variables 00..0F which are meaningless anyway.<br />
<br />
'''WARNING''': Please do not use variables 8C..EB directly. The meaning of these variables changes if the newcargos switch is on. Use the variables 60..64 instead (see below). Those always work correctly.<br />
<br />
== Description ==<br />
=== Platform info (40, 41, 46, 47, 49) ===<br />
<br />
Variables 40, 41, 46, 47 and 49 all return information about the current tile, which platform it is on and how far along the platform. The difference is in the section of the station that they consider.<br />
<br />
{| |-<br />
!Variables!!Regular station!!Irregular station<br />
|-<br />
|40, 46||Whole station||Counting entire length and all adjacent platforms<br />
|-<br />
|41, 47||Individually built sections||<br />
|-<br />
|49||Whole station||Counting length and platforms that have the same direction<br />
|}<br />
<br />
The term "counting" here refers to starting at the tile in question, and counting tiles in all four directions. The two directions aligned with the station direction will be the length of the station, and the other two directions give the number of platforms. For variables 40 and 46, this counting stops at the edge of the station, i.e. the first non-station tile. For variable 49, it stops either at the edge, or at a station tile that is in the wrong direction. &nbsp;The resulting information is probably not really useful in the case of irregular stations, with the exception of edge detection. To correctly detect edges, you have the choice of either the station-&gt;non-station transition (vars. 40, 46), or additional an opposite-direction transition (var. 49).<br />
<br />
Variable 41 is largely unaffected by irregular stations, because it only refers to individually built sections. However, when these individual sections are built over existing tiles, the var. 41 information of surrounding tiles changes as well, due to an internal limitation in how it is stored.<br />
<br />
For variables 40, 41 and 49, the position is counted from the northern most edge of the station, and returned in the form xTNLcCpP, where:<br />
<br />
{| |-<br />
!Variable!!Meaning<br />
|-<br />
|x||undefined, use bit mask to mask it out<br />
|-<br />
|T||Tile type: the current tile type; only valid for callback 14<br />
|-<br />
|N||Total number of platforms<br />
|-<br />
|L||Total platform length<br />
|-<br />
|c||Platform number current being drawn, counted from the end (starting at zero)<br />
|-<br />
|C||Platform number currently being drawn (starting from zero)<br />
|-<br />
|p||Position along this platform counted from the end, zero at the end<br />
|-<br />
|P||Position along this platform, zero at the beginning<br />
|}<br />
<br />
Here, the "beginning" of a station is its northern-most (up on the screen) tile, and the "end" is the southern-most (down on the screen) tile. Each variable consists of 4 bits.<br />
<br />
For variables 46 and 47, the position is counted from the middle, i.e. the center tile has C=0 and P=0. For even lengths and numbers of platforms, the middle tile is at position L/2 resp. N/2, e.g. for length 6, it is tile 3, which is the fourth tile. The return format is xTNLxxCP, where T, N and L are as above, and C and P are the positions counted from the middle.<br />
<br />
Since C and P can have negative numbers, here's how this is encoded:<br />
<br />
{| |-<br />
!Hex!!Binary!!Decimal<br />
|-<br />
|0||0000||0<br />
|-<br />
|1||0001||1<br />
|-<br />
|7||0111||7<br />
|-<br />
|8||1000||-8<br />
|-<br />
|9||1001||-7<br />
|-<br />
|E||1110||-2<br />
|-<br />
|F||1111||-1<br />
|}<br />
<br />
The counting goes like this, preferring an extra negative number for an even count (because there are 8 negative numbers available but only 7 positive ones):<br />
<br />
{| |-<br />
!Count!!Numbers<br />
|-<br />
|1||<pre> 0</pre><br />
|-<br />
|2||<pre> -1 0</pre><br />
|-<br />
|3||<pre> -1 0 1</pre><br />
|-<br />
|4||<pre> -2 -1 0 1</pre><br />
|-<br />
|5||<pre> -2 -1 0 1 2</pre><br />
|-<br />
|6||<pre>-3 -2 -1 0 1 2</pre><br />
|}<br />
<br />
(etc.)<br />
<br />
=== Terrain and track type (42) ===<br />
<br />
Variable 42 is of the format xxxxttTT, where TT is the terrain type and tt is the railway track type.<br />
<br />
They can have the following values:<br />
<br />
{| |-<br />
!TT!!Meaning<br />
|-<br />
|0||normal (grass)<br />
|-<br />
|1||desert<br />
|-<br />
|2||rainforest<br />
|-<br />
|4||on or above snowline<br />
|}<br />
<br />
<br />
{| |-<br />
!tt!!Meaning<br />
|-<br />
|0||railroad, regular<br />
|-<br />
|1||railroad, electrified<br />
|-<br />
|2||monorail<br />
|-<br />
|3||maglev<br />
|}<br />
<br />
=== Path-based signalling info (44) ===<br />
<br />
This returns the following value in bits 0-2: (bit 2 only available from alpha 47 and up)<br />
<br />
{| |-<br />
!State!!Value (binary)!!Value (decimal)<br />
|-<br />
|Reserved||111||7<br />
|-<br />
|Not reserved||100||4<br />
|-<br />
|No PBS||010||2<br />
|}<br />
<br />
At the moment, PBS on/off refers to the switch setting, in a future alpha version it will actually refer to whether the switch is on ''and'' the current block actually uses PBS.<br />
<br />
The bits are defined this way to allow easy fallback to non-PBS cases. If you need graphics to show the "unreserved" state in non-PBS cases, use bit 0, but if you need the "reserved" state in non-PBS cases, use bit 1. To explicitly check whether PBS is active or not, use bit 2.<br />
<br />
All other bits are reserved and must be masked out.<br />
<br />
=== Rail continuation info (45) ===<br />
<br />
This variable returns 16 bits of info whether the rail tracks continue in the eight tiles adjacent to the station tile.<br />
<br />
{| |-<br />
!Bit!!Value!!Set if rail continues in direction of...<br />
|-<br />
|0||01||+Length<br />
|-<br />
|1||02||-Length<br />
|-<br />
|2||04||+Platforms<br />
|-<br />
|3||08||-Platforms<br />
|-<br />
|4||10||+Length, +Platforms<br />
|-<br />
|5||20||-Length, +Platforms<br />
|-<br />
|6||40||+Length, -Platforms<br />
|-<br />
|7||80||-Length, -Platforms<br />
|}<br />
<br />
The following picture illustrates which bits represent which tile for the two possible station orientations:<br />
<br />
[[File:station_var45.png]]<br />
<br />
Bits 0 to 3 are set if there is track on the given tile, and it has a connection to the station tile. For bits 2, 3, the station of course has itself no connection to those tiles, but this doesn't matter for this variable. Bits 4 to 7 check connections to the neighbouring platform tile, i.e. bits 4 and 5 resp. 6 and 7 indicate a connection from that tile to tile 2 resp. 3. (This has changed again with 2.5 beta 4 r325.)<br />
<br />
Bits 8..15 repeat the above, but are set if there are any train tracks on the tile and disregard whether the track is connected to the station or not entirely.<br />
<br />
=== Bitmask of accepted cargos (48) ===<br />
<br />
(This variable is available from TTDPatch 2.0.1 alpha 55 vcs 3 only)<br />
<br />
Returns a doubleword where the '''n'''th bit is set if and only if the station accepts the cargo whose climate-dependent ID is '''n'''. If newcargos is off, bits 12..31 are guaranteed to be zero. If you need to check acceptance for a climate-independent ID, you can use variable 65 instead.<br />
<br />
'''NOTE''':Variables 60..64 are available from TTDPatch 2.0.1 alpha 55 vcs 3 only!<br />
<br />
=== Amount of cargo waiting (60) ===<br />
<br />
The parameter is a cargo number (see note below). Currently, the returned value is between 0 and 32767, but this may later change to support the range -32768..32767.<br />
<br />
=== Time since the cargo was last picked up (61) ===<br />
<br />
The parameter is a cargo number (see note below). The unit is 185 ticks (approx. 2.5 TTD days). If the given type has never been seen on the station, the returned value is zero, otherwise, the return value isn't larger than 255.<br />
<br />
=== Rating of the cargo (62) ===<br />
<br />
The parameter is a cargo number (see note below). The returned value is between 0 and 255 (255 means 100% rating), or FFFFFFFFh if the cargo is unrated.<br />
<br />
=== Time spent en-route (63) ===<br />
<br />
The parameter is a cargo number (see note below). Returns the time elapsed since the cargo appeared on a station. If the cargo has never been seen on the station, the returned value is 0, otherwise it's between 0 and 255. The unit is 185 ticks (approx. 2.5 TTD days).<br />
<br />
=== Information about the last vehicle picking this cargo up (64) ===<br />
<br />
The parameter is a cargo number (see note below). Bits 0..7 contain the speed of the last vehicle, while bits 8..15 contain the age of the last vehicle in years. If no vehicle has attempted to pick up this cargo yet, the result is FF00h.<br />
<br />
=== Amount of cargo acceptance (65) ===<br />
<br />
(From TTDPatch 2.5 beta 2)<br />
<br />
The parameter is a cargo number (see note below). The return value contains the acceptance of the given cargo type in 1/8 units. The station accepts the cargo if its acceptance is at least 8/8 units. Without newcargos, the returned value is between 0 and 15 (inclusive). With newcargos enabled, the return value is either 8 or 0.<br />
<br />
'''NOTE''': In GRF version 6, parametrized variables 60..65 accept a climate-dependent cargo number. In GRF version 7 and later, these variables accept a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo bit.<br />
<br />
=== Animation frame of nearby tile (66) ===<br />
<br />
(From TTDPatch 2.5 beta 5)<br />
<br />
The parameter defines the offset relative to the current tile. Both nibbles are considered signed (that is, 8h=8, 9h=-7, ...., Fh=-1, 0h=0, 1h=1, ..., 7h=7). The high nibble contains the amount to move sideways (between platforms), the low one is the amount to move along the platform. Negative offsets move northwards, positive ones southwards. If the selected tile is a rail station tile that belongs to the current station, its animation state is returned. Otherwise, FFFFFFFFh is returned.<br />
<br />
=== Land info of nearby tiles (67) ===<br />
<br />
This variable works like [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_60_|industry tile variable 60]], except for three things:<br />
* The offsets in the parameter are interpreted relatively to the alignment of the station, the same way as for variable 66<br />
* The '''ss''' part is "mirrored" (bit 0 and 2 swapped) for the NW-SE orientation; this will allow you to handle analogous slopes of the two orientations without checking the orientation explicitly (since TTDPatch 2.6 r1693)<br />
* Bit 0 of the '''bb''' part is undefined<br />
<br />
=== Station info of nearby tiles (68) ===<br />
<br />
The parameter of this variable works the same way as the parameter of variable 66. The returned value is FFFFFFFFh if the selected tile isn't a railway station tile. Otherwise, the returned value can be separated to the following parts:<br />
<br />
{| |-<br />
!Bits!!Meaning<br />
|-<br />
|0..7||If the tile is defined in the current GRF, this is the setID used in the definition. Otherwise, the content is undefined.<br />
|-<br />
|8..9||0 - the tile uses original TTD graphics<br />
<br />
1 - the tile is defined in the current GRF<br />
<br />
2 - the tile is defined in another GRF<br />
|-<br />
|10||set if the selected tile belongs to the current station, clear otherwise<br />
|-<br />
|11||clear if the selected tile is parallel with the current one, set if perpendicular to it<br />
|-<br />
|12..13||0 - plain platform<br />
<br />
1 - platform with building<br />
<br />
2 - platform with roof, left side<br />
<br />
3 - platform with roof, right side<br />
|-<br />
|14..31||Undefined, reserved for future use<br />
|}<br />
<br />
=== Information about cargo accepted in the past (69) ===<br />
<br />
The parameter of this variable has the same format as for variables 60..65. The returned value looks like this:<br />
<br />
{| |-<br />
!Bits!!Meaning<br />
|-<br />
|0||Set if the given cargo was ever accepted at this station<br />
|-<br />
|1||Set if the given cargo was accepted last month<br />
|-<br />
|2||Set if the given cargo was accepted this month<br />
|-<br />
|3||Set if the given cargo was accepted since last periodic processing (which happens every 250 ticks)<br />
|-<br />
|4..31||Undefined, reserved for future use<br />
|}<br />
<br />
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:<br />
* Generalfixes is on, and miscmods.noextendstationrange is off<br />
* Any of fifoloading, newcargos or irregularstations is on<br />
<br />
If the station2 structure isn't present, the returned value is always zero.<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=File:Station_var45.png&diff=1557File:Station var45.png2011-06-16T18:18:51Z<p>Terkhen: </p>
<hr />
<div></div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Houses&diff=1535Action0/Houses2011-06-16T13:47:37Z<p>Terkhen: Add a note about property 1E to properties 0D/0E/0F</p>
<hr />
<div>== Introduction ==<br />
<br />
<br />
Defining properties of houses<br />
<br />
<br />
For town buildings (or simply houses), the offset defines the first house ID for this action 0. House IDs, like station IDs, are unique within each grf file, and in total each game can only have 255 IDs in TTDPatch and 512 IDs in OpenTTD for all active grf files.<br />
<br />
To start using a house ID, you must first define it by setting its property 08 (see below). If you try to modify a house ID whose property 08 isn't set, your request is ignored, but not reported as an error, either. House IDs, unlike station IDs, need not be set in order, so you can use action 7 to skip action 0s of the houses you don't currently need (for example those houses that don't appear on the current climate anyway). You are advised to do so in order to define as few IDs as possible, leaving space for other GRFs. You don't need to skip all action 0s for a house ID to disable it; skipping the action 0 that sets property 08 is enough.<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08||(a)||B||Substitute building type<br />
|-<br />
|09||(a)||B||Building flags<br />
|-<br />
|0A||(a)||W||Availability years<br />
|-<br />
|0B||(a)||B||Population<br />
|-<br />
|0C||(a)||B||Mail generation multiplier<br />
|-<br />
|0D||(a)||B||Passenger acceptance<br />
|-<br />
|0E||(a)||B||Mail acceptance<br />
|-<br />
|0F||(a)||B||Goods, food or fizzy drinks acceptance<br />
|-<br />
|10||(a)||W||LA rating decrease on removal (should be set to the same value for every tile for multi-tile buildings)<br />
|-<br />
|11||(a)||B||Removal cost multiplier (should be set to the same value for every tile for multi-tile buildings)<br />
|-<br />
|12||(a)||W||Building name ID<br />
|-<br />
|13||(a)||W||Building availability mask<br />
|-<br />
|14||(a)||B||House callback flags<br />
|-<br />
|15||(a)||B||House override byte<br />
|-<br />
|16||(a)||B||Periodic refresh multiplier<br />
|-<br />
|17||(b)||4*B||Four random colours to use<br />
|-<br />
|18||(b)||B||Relative probability of appearing<br />
|-<br />
|19||(c)||B||Extra flags<br />
|-<br />
|1A||(d)||B||Animation frames<br />
|-<br />
|1B||(d)||B||Animation speed<br />
|-<br />
|1C||(e)||B||Class of the building type<br />
|-<br />
|1D||(f)||B||Callback flags 2<br />
|-<br />
|1E||(f)||D||Accepted cargo types<br />
|-<br />
|1F||(g)||B||Minimum life span in years<br />
|-<br />
|20||(h)||V||Cargo acceptance watch list<br />
|-<br />
|21||(i)||W||Long year (zero based) of minimum appearance<br />
|-<br />
|22||(i)||W||Long year (zero based) of maximum appearance<br />
|}<br />
<br />
When a town decides to expand, each active house type (both old and new ones) has a uniform probability to appear, so the more new houses you define, the fewer old TTD buildings will appear.<br />
<br />
(a) Available since TTDPatch 2.0.1 alpha 34<br />
<br />
(b) Available since TTDPatch 2.0.1 alpha 35<br />
<br />
(c) Available since TTDPatch 2.0.1 alpha 38<br />
<br />
(d) Available since TTDPatch 2.0.1 alpha 39<br />
<br />
(e) Available since TTDPatch 2.0.1 alpha 43<br />
<br />
(f) Available since TTDPatch 2.0.1 alpha 55 vcs 2<br />
<br />
(g) Available since TTDPatch 2.6 r1554<br />
<br />
(h) Available since TTDPatch 2.6 r1677<br />
<br />
(i) Available since OpenTTD r13437<br />
<br />
== Descriptions ==<br />
<br />
=== Substitute building type (08) ===<br />
<br />
This building type will be used instead of your new one if your definition isn't available for any reason (the grf file is not found, for example).<br />
<br />
Don't set a substitute building type that is larger than your new one (for example, don't set 14 (stadium) for an 1x1 building) because this may corrupt savegames. Setting this property automatically copies every property of the substitute building to your new building, so you don't have to change properties that are the same as the substitute.<br />
<br />
House flags 40 and 80 are exceptions; these flags are never set automatically. Only the first property 08 setting copies properties; if you later change it, properties will stay.<br />
<br />
There's a special use of this property beginning from alpha 72: if you set it to FFh, you can disable an old house type. In this case, the ID used must be the number of old house type you want to disable. Disabling only prevents building the type in towns; houses already present on the map will stay unchanged. The type can still be overridden, and overriding affects houses present on the map.<br />
<br />
If this house's action 3 appears before this property is set, the action 3 will have no effect.<br />
<br />
=== Building flags (09) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||This is a 1x1 building<br />
|-<br />
|1||2||This building can be built only on flat land (if clear, foundations are automatically displayed on sloped land)<br />
|-<br />
|2||4||This is a 2x1 building<br />
|-<br />
|3||8||This is a 1x2 building<br />
|-<br />
|4||10||This is a 2x2 building<br />
|-<br />
|5||20||Animation flag, set in tiles 04 and 05 (large office block). New buildings have a different animation scheme than large office blocks, but animation is still enabled with this bit.<br />
|-<br />
|6||40||This building is a church<br />
|-<br />
|7||80||This building is a stadium<br />
|}<br />
<br />
If your building isn't 1x1, set flags for the north tile, then define the next 1 or 3 tiles tiles (by setting their property 8). The only bit that can be set in the flags of additional tiles is bit 5 (animation). There should be no property 8 setting between the first tile and the additional tiles.<br />
<br />
For 2x2 buildings, the first additional tile is the east one, the second is the west part and the third is the south part. You probably want to set the substitute for additional tiles to a TTD additional tile whose flags are already zero. 2x2 buildings are always built on flat land no matter how bit 1 is set.<br />
<br />
Only one church and one stadium can exist in a town; the town won't build buildings with the according flag set until the old church/stadium is removed. (This can be done by either the town or a player)<br />
<br />
The animation flag works on a per-tile basis, so you should enable it for additional tiles of multi-tile buildings as well if you want all tiles to be animated.<br />
<br />
=== Availability years (0A) ===<br />
<br />
The low byte is the minimum year, the high is the maximum. The building can only be built between these two years (inclusive). 1920 is added to both bytes before using the values.<br />
<br />
Since the year counting stops in TTDPatch in 2070 even with [[EternalGame]] on, start years above 150 mean "never", and end years above 150 mean "forever". In OpenTTD [[EternalGame]] is always active and the maximum year is 5000000.<br />
<br />
'''WARNING:''' Don't set the start year below 1930 (0Ah) unless you know what you're doing!<br />
<br />
If TTDPatch finds a building that is available before 1930, it will not build old building types until that year, so you have to provide at least one custom building type that is available before 1930 for every [[TownZones|town zone]], or TTD may deadlock while trying to create a random game or expand a town.<br />
<br />
In OpenTTD the availability of all active houses with the lowest availability year is set to start from year 0, so that always at least one house is available irrespective of starting year. Thus, if you de-activate default houses or set an introduction date prior to the default houses introduction year 1930, you should have at least for each [[TownZones|town zone]] a house with the same earliest availability year or you might end up with a situation where no house can be placed in a [[TownZones|town zone]].<br />
<br />
=== Population (0B) and Mail generation multiplier (0C) ===<br />
<br />
The population of the town will be increased by the amount set in prop. 0B if this building is built. Additional house parts should have a population of zero. The higher this value is, the more passengers this building generates.<br />
<br />
The higher the mail generation multiplier is, the more mail the building generates. For multi-tile buildings, mail generation is done in per-tile basis, so you can specify different values for every tile, although distributing the generation equally between tiles is suggested.<br />
<br />
=== Passenger (0D), Mail (0E) and Good/Food/Fizzy drinks (0F) acceptance ===<br />
<br />
The acceptance is given in units of 1/8th and must not be larger than 8 eighths.<br />
<br />
For prop. 0F, positive values indicate that the building accepts goods, and negative values indicate acceptance of food or fizzy drinks (depending on the climate).<br />
<br />
All the above three values can be set independently for tiles of multi-tile buildings, since every tile is processed individually when determining what a station accepts.<br />
<br />
Note that in TTDPatch the officefood switch may modify acceptance in the sub-arctic and subtropical climates.<br />
<br />
The type of accepted cargo can be modified using [[Action0Houses#Accepted_cargo_types|property 1E]].<br />
<br />
=== Building name ID (12) ===<br />
<br />
The ID of the text that should be displayed in the land query window. The name can also be set by action 4 (see there). Should be set to the same value for every tile for multi-tile buildings.<br />
<br />
=== Building availability mask (13) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0..4||1,2,4,8,10||which [[VarAction2Houses#Town zone 42|town zone(s)]] the building can be built in<br />
|-<br />
|11||800||can appear in sub-arctic climate above the snow line<br />
|-<br />
|12||1000||can appear in temperate climate<br />
|-<br />
|13||2000||can appear in sub-arctic climate below the snow line<br />
|-<br />
|14||4000||can appear in subtropical climate<br />
|-<br />
|15||8000||can appear in toyland climate<br />
|}<br />
<br />
This property should be set to zero for additional building tiles.<br />
<br />
=== House callback flags (14,1D) ===<br />
<br />
For houses, the following [[callbacks]] can be defined by setting the corresponding bit in property 14:<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||17||decide whether the house can be built on a given tile<br />
|-<br />
|1||2||1A||decide the following frame of the animations<br />
|-<br />
|2||4||1B||periodically start/stop the animation<br />
|-<br />
|3||8||1C||change animation when construction state changes<br />
|-<br />
|4||10||1E||decide the color of the building<br />
|-<br />
|5||20||1F||decide the cargos amounts accepted<br />
|-<br />
|6||40||20||decide the length of the current animation frame<br />
|-<br />
|7||80||21||trigger destruction of building<br />
|}<br />
<br />
Property 1D was introduced after all bits of property 14 were filled. Its usage is the same, only the meaning of bits is different:<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||2A||decide the cargo types accepted<br />
|-<br />
|1||2||2E||custom cargo production<br />
|-<br />
|2||4||143||conditional protection<br />
|-<br />
|3||8||14E||decide if default foundations need to be drawn (from OpenTTD r17558 and TTDPatch 2.6r2249)<br />
|-<br />
|4||10||14F||allow or deny autosloping below the tile (from OpenTTD r17558 and TTDPatch 2.6r2249)<br />
|}<br />
<br />
Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the variational action 2 for callbacks.<br />
<br />
Callback flags are ignored for additional building tiles.<br />
<br />
=== House override byte (15) ===<br />
<br />
Setting this property makes this building appear instead of the given old TTD building type. Setting the property is ignored if the given old house type is already overridden. You can set this property more than once to override more old building types.<br />
<br />
No new house of the overridden types will be built in towns.<br />
<br />
This property works in a per-tile basis, so you override tiles of old multi-tile buildings individually, although the old type will still be built if you don't override its north tile.<br />
<br />
=== Periodic refresh multiplier (16) ===<br />
<br />
This is used for random triggers, and sets how often the tile is re-randomized. When set to X, the tile will be re-randomized on every (X+1)-th periodic processing. (In other words, every (X+1)*256 game ticks.) If you want all tiles to be re-randomized, you must set this (but not necessarily to the same value) for each tile.<br />
<br />
If callback 1B is enabled in property 14, it is also called after re-randomizing random bits.<br />
<br />
In TTDPatch versions before TTDPatch 2.6 r1639 and TTDPatch 2.5 beta 9 (including beta 9), this variable could have any value between 0 and 255. After these versions, the upper limit has been lowered to 63. To maintain compatibility, values above 63 will be interpreted as 63.<br />
<br />
=== Random colours (17) ===<br />
<br />
This specifies four colors used for random painting (see [[Action2HousesIndustryTiles]]). Each byte of the dword defines a color, the values are the same as in action 2, except that numbering starts from zero instead of 775. If not set, this defaults to 04 08 0c 06 (red, blue, orange and green, the colors of the modern office building). Can be set to different values for tiles of multi-tile buildings.<br />
<br />
=== Probability (18) ===<br />
<br />
This sets the relative probability of this house being built. Old TTD house types have a probability of 16, and this is the default for new types as well.<br />
<br />
Increase (or better multiply) this value to make your building appear relatively more often, or decrease (divide) it to make it rarer. If you set this to zero, the house type never appears. The minimal useful value 1 means it's sixteen times less probable to build this type than a normal type, while the maximum setting of 255 means it's almost sixteen times more probable.<br />
<br />
The probability is relative since the absolute probability depends on the count and probability of other houses as well: the more types are available (and the higher their probabilities are), the less the chance is that your type will be chosen.<br />
<br />
=== Extra Flags (19) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||This building appears during the generation of a town, but not later, i.e. will appear in random games, but new ones won't be built during the game. Useful for buildings that are intended to be historical.<br />
|-<br />
|1||2||This building is protected, i.e. towns an AI players won't remove it. Human players can still remove it, so you may need to set a high remove cost/rating to make them think twice.<br />
|-<br />
|2||4||Synchronized callback 1B. (for multi-tile buildings)<br />
|-<br />
|3||8||[[Callbacks#Next animation frame (1A/26/141/153/158) |Callback 1A]] needs random bits (from TTDPatch 2.5 beta 2)<br />
|}<br />
<br />
If synchronized callbacks are enabled, callback 1B will be called when the periodic processing reaches the main tile of the building, and not when it reaches the current tile. This is useful if your animation must run synchronously on every tile of the building. If this bit is set, callback 1B is called according to the main tile's property 16, not the current one, to make sure every tile stays in sync.<br />
<br />
=== Animation Frames (1A) ===<br />
<br />
The bottom seven bits define how many frames the animation consists of, minus one. (I.e. 0 means 1 frame, 1 means 2 frames etc.) The highest bit has another purpose (see below), so the biggest supported value is 7F (128 frames).<br />
<br />
The highest bit is set if the animation is looping, i.e. it should start again from the first frame after showing the last frame. Non-looping animations stop after the last frame, leaving it on the screen. Both kinds of animations start automatically when the building is created. It's recommended to use callback 1B with non-looping animations, so they are played multiple times.<br />
<br />
In TTDPatch versions before TTDPatch 2.6 r1639 and TTDPatch 2.5 beta 9 (including beta 9), the frame number was limited to 32. If you intend to maintain compatibility with those versions, you should not use animations longer than 32 frames.<br />
<br />
=== Animation Speed (1B) ===<br />
<br />
This is the amount of time between switching frames.<br />
<br />
The default value is 2, which means the switch occurs every 108 milliseconds. Increasing this value by one doubles the wait, i.e. 3 will cause 216 ms delay, while 4 will pause 432 ms, and so on. Values below 2 have the same effect as 2, so the default is the fastest possible setting. The maximum is 16, which means 1769 seconds (approx. half an hour) delay. Settings above this value may cause strange behaviour.<br />
<br />
=== Building Class (1C) ===<br />
<br />
Types that were given the same class byte are considered to be in the same class. If you don't explicitly set this value, the type is considered to have no class (it won't be considered to be class 0). The scope of a class is the current GRF file, so two types are never in the same class if they were defined by different GRF files. Currently, this property affects variable 44 only.<br />
<br />
This property is a per-tile one, you can set it for additional tiles as well. It's a better idea, however, to set it for the main tile only, since var. 44 counts tiles, not buildings, and you may count multi-tile multiple times otherwise.<br />
<br />
=== Accepted cargo types (1E) ===<br />
<br />
There may be cases when you want your house to accept something other than the default types (passenger, mail, goods and food). This property allows you to do that. If this property is set to FFFFFFFFh (the default), the meaning of properties 0D, 0E and 0F aren't changed, that is, they are the passenger, mail and goods/food acceptances, accordingly. If this property isn't FFFFFFFFh, the first three bytes must be climate-dependent cargo slot numbers (the fourth byte is ignored). In this case property 0D is the amount of acceptance of the first cargo type given, 0E is the same for the second type and 0F is the same for the third type.<br />
<br />
From GRF version 7 and above, the meaning of this property changes: instead of climate-dependent cargo slot numbers, you have to give climate-independent cargo IDs. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo slot number. Acceptance of cargoes not currently present will automatically be disabled.<br />
<br />
=== Minimum life span in years (1F) ===<br />
<br />
Towns are prevented from destroying the house if it hasn't yet reached the age given here. The default is 0, which means towns are free to remove the house any time they like. Please note that this setting doesn't prevent AI players from removing the house; only towns are affected. If you need to protect your building from AI players as well, you can set the "protected" flag (property 19 bit 1), or use [[Callbacks#Protect building conditionally (143) |callback 143]] and use your custom code to decide who (and when) is allowed to remove the building.<br />
<br />
For this to operate consequently on multi-tile buildings, you must set the same minimum lifespan for all tiles of the building.<br />
<br />
=== Cargo acceptance watch list (20) ===<br />
<br />
This property is a list of cargo types, types whose acceptance should be watched. The first byte is the length of the list, the remaining bytes identify cargo types. If your GRF is version 7 or above, and has a cargo translation table, the bytes are indexes in the table; otherwise, they are cargo slot numbers. When a cargo from this list is accepted by the current tile, [[Callbacks#Watched cargo accepted (148) |callback 148]] is called on ''all'' tiles of the building. See [[Callbacks#Watched cargo accepted (148) |callback 148]] for more details about how this happens.<br />
<br />
This property has no effect if the station2 structure isn't present. The station2 structure is present if any of the following is true:<br />
* Generalfixes is on, and miscmods.noextendstationrange is off<br />
* Any of fifoloading, newcargos or irregularstations is on<br />
<br />
=== Availability years (long format) - Minimum (21) - Maximum (22) ===<br />
<br />
Those two properties allow to specify a range of dates (based on year zero(0) that are not limited to the 1930 dates. So earlier buildings can be introduced. Be sure to add substantial houses to the sets, if you do not wat to have uniform towns, since the current earliest houses will remain in their current 1920 era. Mind also the warning wrt. introduction years as described at property 0A.<br />
== Example ==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Cargos&diff=1457Action0/Cargos2011-06-15T19:58:32Z<p>Terkhen: Fix link to NewTownGrowthSwitches</p>
<hr />
<div>== Introduction ==<br />
<br />
<br />
Defining properties of cargo types<br />
<br />
<br />
The [[NewCargos]] switch of TTDPatch allows modifying the existing 12 cargos per climate, and allows adding 20 new cargos per climate as well. These cargo slots are numbered from 0 to 31, where slots 0-11 are used by default TTD cargos and slots 12-31 contain uninitialized garbage by default (so you can't trust them having meaningful information, you must set all of their properties).<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08||B||Bit number for bitmasks<br />
|-<br />
|09||W||TextID for the cargo type name<br />
|-<br />
|0A||W||TextID for the name of one unit from the cargo type<br />
|-<br />
|0B||W||TextID to be displayed for 1 unit of cargo<br />
|-<br />
|0C||W||TextID to be displayed for multiple units of cargo<br />
|-<br />
|0D||W||TextID for cargo type abbreviation<br />
|-<br />
|0E||W||Sprite number for the icon of the cargo<br />
|-<br />
|0F||B||Weight of one unit of the cargo<br />
|-<br />
|10,11||B||Penalty times<br />
|-<br />
|12||D||Base price<br />
|-<br />
|13||B||Color for the station list window<br />
|-<br />
|14||B||Color for the cargo payment list window<br />
|-<br />
|15||B||Freight status (for [[FreightTrains]] switch); 0=not freight, 1=is freight<br />
|-<br />
|16||W||Cargo classes<br />
|-<br />
|17||D||Cargo label<br />
|-<br />
|18||B||Substitute type for town growth<br />
|-<br />
|19||W||Multiplier for town growth<br />
|-<br />
|1A||B||Callback flags<br />
|-<br />
|1B||W||TextID for displaying the units of a cargo<br />
|-<br />
|1C||W||TextID for displaying the amount of cargo<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Bit number for bitmasks (08) ===<br />
<br />
This value must be used in [[Action3]] and in cargo bit mask properties such as refit masks. Values 1C-1F should be safe to use (if they aren't already taken, of course) if you intend to maintain compatibility with GRFs unaware of the newcargos switch. Further assuming that no active GRFs support the toyland climate, you can use values 11-1A as well.<br />
<br />
Additionally, you can use the value FFh to disable the given cargo slot. This way, it won't appear in cargo type lists, but it won't be removed from things already on the map. If you disable a cargo, you'll probably want to zero out the cargo label (property 17) as well.<br />
<br />
=== TextID for the cargo type name (09) ===<br />
<br />
This textID should refer to the name of the cargo, capitalized, to match the TTD style (e.g. "Passengers", "Coal", "Gold Ore", "Milk")<br />
<br />
You can reuse existing [[TextIDs]] or create custom strings using [[Action4]] with an offset in the DCxx range. Note that you need to set language-id bit 7 as well in the Action4 for a custom string. (Also applies to properties 0A to 0D)<br />
<br />
=== TextID for one unit of the type (0A) ===<br />
<br />
This textID should refer to the cargo type name in the singular. Currently, this ID is used only in subsidy messages ("First Passenger service..." instead of "First Passengers service...", for example)<br />
<br />
=== TextID for 1 unit of cargo (0B) ===<br />
<br />
This textID will be used to display the amount of the cargo if there's exactly 1 unit waiting. Although there's only one unit waiting, you'll still have to use either the special character 7C (print signed word) or 87 (print amount in litres and add suffix " litres") so TTD removes the amount from its internal reference stack. For example, if you have a new cargo named "gold ore", this should be "\7C ton of gold ore", which will expand to "1 ton of gold ore". On the other hand, a liquid cargo named "milk" should be something like "\87 of milk", which will expand to either "100 litres of milk" or "1,000 litres of milk" (The multiplier for liquid cargos depends on miscmods.dontfixlitres. If it's on, the multiplier is 100, otherwise it's 1000)<br />
<br />
=== TextID for multiple units of cargo (0C) ===<br />
<br />
This textID will be used to display the amount of cargo if the amount waiting isn't exactly 1. You'll need the same special characters as above, but now they will be expanded according to the actual cargo waiting. Sticking to the example above, you'll need "\7C tons of gold ore" and "\87 of milk", which can expand to "42 tons of gold ore" and "42,000 litres of milk", accordingly. You will note that liquid cargos can have the same textID for both property 0B and 0C since they always use the plural form.<br />
<br />
=== TextID for cargo type abbreviation (0D) ===<br />
<br />
This textID will be used in the station list window to represent the cargo waiting. It should be a two-letter abbreviation prefixed by the special character 0E to switch to the microscopic font. The microscopic font has every letter capitalized, so capitalization isn't important here. Continuing the above example, gold ore could have this as "GO" and milk as "MK" ("ML" is already taken by mail).<br />
<br />
=== Sprite number for icon (0E) ===<br />
<br />
This is a sprite number of an old TTD sprite to be displayed in the station window for this cargo, or FFFFh if the icon should be found by following the action 3 associated with this cargo. The icon must not be bigger than 10x10 pixels. One icon will be shown for every 10 units of the cargo waiting, up to 23 icons, which is the maximum.<br />
<br />
=== Weight of one unit of the cargo (0F) ===<br />
<br />
This property defines the weight of 1 unit from the cargo, which will be used to calculate the weight of the vehicles when loaded. The unit is 1/16 ton (which is 62.5 kg). With the examples above, gold ore should have this as 16 (since 1 ton of gold ore should weigh exactly 1 ton), while milk should have this slightly above 16 (milk is denser than water).<br />
<br />
=== Penalty times and price factor (10,11,12) ===<br />
<br />
These three values define how much is paid for the delivery of the cargo type. The price factor is subject to inflation, but GRFs needn't care about this, TTDPatch will adjust the price for them.<br />
<br />
The income generated from cargo delivery is calculated as:<br />
<br />
income=((((distance/2) * timefactor * amount_moved) >> 7) * cargopricefactor) >> 13<br />
<br />
where<br />
<br />
; a >> b : means a is arithmetically shifted right by b bits<br />
; distance : is the Manhattan distance between the two station signs<br />
; amount_moved : is the number of cargo units moved<br />
; cargopricefactor : is the value you set in property 12. Inflation will be applied automatically on it.<br />
; timefactor : is a multiplier in the range 0..255, calculated in the following way: (T1 is the value of property 10, T2 is the value of property 11, t is the time the delivery took, the unit is 185 game ticks (roughly 2.5 game days) )<br />
<br />
<br />
if t<=T1 then timefactor=255<br />
else if t<=(T1+T2) then timefactor=255-(t-T1)<br />
else timefactor=255-(t-T1)-(t-T1-T2)<br />
if the above rules result in a timefactor less than 31, 31 is used instead. <br />
<br />
<br />
=== Color for the station list window (13) ===<br />
<br />
This color index will be used to draw the rectangle representing the amount waiting from the current cargo type in the station list window. The index should be given for the DOS palette, the Windows version of TTDPatch will automatically translate the index for the Windows palette.<br />
<br />
=== Color for the cargo payment list window (14) ===<br />
<br />
The graph of the current cargo will be drawn using this color in the cargo payment rates graph. The index should be given for the DOS palette, the Windows version of TTDPatch will automatically translate the index for the Windows palette.<br />
<br />
=== CargoClasses (16) ===<br />
<br />
See [[Action0Trains#Cargo classes 28 29|train prop. 28/29]] for a description of the utility of this property.<br />
<br />
This is a bit mask of all cargo classes to which this cargo belongs, out of the following:<br />
<br />
{| |-<br />
!Bit!!Value!!Cargo class<br />
|-<br />
|0||1||Passengers<br />
|-<br />
|1||2||Mail<br />
|-<br />
|2||4||Express cargo (any prioritised cargo)<br />
|-<br />
|3||8||Armored cargo (needing security measures, e.g. valuables or gold)<br />
|-<br />
|4||10||Bulk freight (any non-packaged cargo suitable for pouring, e.g. coal, grain, ore, cement, ...)<br />
|-<br />
|5||20||Piece goods (any unitised cargo, packed or unpacked)<br />
|-<br />
|6||40||Liquids (any liquid or gaseous cargo, food or chemical)<br />
|-<br />
|7||80||Refrigerated cargo (any goods needing temperature-controlling, e.g. perishable goods, food, or chemicals needing cooling/heating)<br />
|-<br />
|8||100||Hazardous cargo (explosives, acids, radioactive material, ...)<br />
|-<br />
|9||200||covered/sheltered freight (any cargo needing moisture protection, i.e. transportation in box vans, silo wagons or containers required)<br />
|-<br />
|10||400||Oversized and/or overweight cargo (any cargo needing special means of transportation, e.g. industrial equipment, machinery, large format glass, ... )<br />
|-<br />
|15||8000||Special (used for livery refit tricks rather than actual cargos)<br />
|}<br />
<br />
Only cargos which are in class 0 (passengers) will appear in bus stations. &nbsp;Only cargos which are ''not'' in class 0 will appear in truck stations.<br />
<br />
=== Cargo label (17) ===<br />
<br />
Cargo labels are globally [[CargoTypes#Cargo Labels|unique identifiers]] for a cargo type. They are used to allow vehicle grfs to easily support many cargo types, whether they are active or not and no matter what slot or bit they are using.<br />
<br />
Read about the [[Action0GeneralVariables#Cargo translation table 09|cargo translation table]] for further info.<br />
<br />
'''The following properties exist for TTDPatch 2.0.1 alpha 72 and above only'''<br />
<br />
=== Substitute type and multiplier for town growth (18, 19) ===<br />
<br />
These properties allow you to modify how a cargo type affects town growth. Property 18 can contain one of the following values:<br />
<br />
{| |-<br />
!Value!!Meaning!!Details (*)<br />
|-<br />
|00||Affect towns as passengers do||Cargo produced by houses is added to the statistics in the town GUI.<br />
|-<br />
|02||Affect towns as mail does||Cargo produced by houses is added to the statistics in the town GUI.<br />
|-<br />
|05||Affect towns as goods/candy does||See note about subsidies below.<br />
|-<br />
|09||Affect towns as water does||Second required cargo for towngrowth in the desert<br />
|-<br />
|0B||Affect towns as food/fizzy drinks do||First required cargo for towngrowth in desert/above snowline. Alse see note about subsidies below.<br />
|-<br />
|FF||Don't affect town growth (default)|| <br />
|}<br />
<br />
(*) This is the interpretation of OpenTTD. For TTDPatch see [http://www.tt-wiki.net/wiki/NewTownGrowthSwitches NewTownGrowthMechanism], which is quite different/unrelated.<br />
<br />
The incoming cargo amount is multiplied by property 19, then divided by 256 before it is added to the town statistics. This allows you to have smaller or bigger impact than original cargoes do. Please note that cargoes accepted by industries affect the closest town as well; for example, if you have an industry that accepts passengers, every passenger brought to the industry affects the town just like if they were transported to the town directly. Usually, it's not a good idea to have industries that process such cargoes; they should be accepted by towns only.<br />
<br />
Note: In OpenTTD property 18 also affects the creation of subsidies. Usually subsidies apply to cargo transportation between two industries. For cargos with substitution-type 05 or 0B the destination will be a town instead. Independent of property 18 subsidies from town to town are only created for cargo slot 0 (Passengers).<br />
<br />
=== Callback flags (1A) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Var. 0C!!Callback<br />
|-<br />
|0||1||39||Custom profit calculation<br />
|-<br />
|1||2||145||Custom station rating calculation<br />
|}<br />
<br />
=== TextID for displaying the units of a cargo (1B) ===<br />
<br />
This textID is used by OpenTTD to show the "short cargo" form for cargo units, e.g. "10 litres" or "10 tonnes". This textID must be set after property 0B. The text this textID refers to should properly handle plurals, e.g. "\7B item\9A\15\80\9A\10\9A\11s\9A\12".<br />
<br />
The default for this textID depends on the default for property 0B; if the default 0B string has "litre", then the default for this textID will be the unit for litres. OpenTTD maps the following textIDs so you don't need to provide translations:<br />
<br />
{| |-<br />
!textID!!String<br />
|-<br />
|004f||<num> passenger(s)<br />
|-<br />
|0050||<num> tonne(s)<br />
|-<br />
|0051||<num> bag(s)<br />
|-<br />
|0052||<num> litre(s)<br />
|-<br />
|0053||<num> item(s)<br />
|-<br />
|0054||<num> crate(s)<br />
|}<br />
<br />
The "tonne" and "litre" strings (textID 0050 and 0052) are automatically updated based on the user settings of unit display, e.g. they "tonne" might become "kg". The "(s)" is for display purposes; in reality that is a choice list.<br />
<br />
Supported by OpenTTD since r21224.<br />
<br />
=== TextID for displaying the amount of cargo (1C) ===<br />
<br />
This textID is used by OpenTTD to show the "long cargo" form for cargo units, e.g. "10 litres of water" or "10 tonnes of coal". This textID must be set after property 0c. The text this textID refers to should properly handle plurals, e.g. "\7B item\9A\15\80\9A\10\9A\11s\9A\12 of livestock".<br />
<br />
The default for this textID depends on the default for property 0C, but with support for plurals. For "X litre(s)" or "X tonne(s)" you should respectively use string codes 87 and 9A 0D.<br />
<br />
Supported by OpenTTD since r21224.<br />
<br />
== Example ==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action0&diff=1382Action02011-06-15T16:37:28Z<p>Terkhen: Reserve a feature id for towns</p>
<hr />
<div>==Introduction==<br />
<br />
Defining new graphics feature properties<br />
<br />
Action 0 allows to change the feature properties of 'features', i.e. vehicles, stations, bridges, houses and more.<br />
<br />
== Syntax ==<br />
<br />
The data for Action 0 looks as follows:<br />
<br />
<Sprite-number> * <Length> 00 <Feature> <Num-props> <Num-info> <Id> (<Property <New-info>)...<br />
<br />
Here is a short overview of what every term means:<br />
<br />
{| |-<br />
!Element!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|<Sprite-number> ||dec||A sequential sprite number<br />
|-<br />
|<Length> ||dec||The total number of bytes in the action<br />
|-<br />
|00 ||B||Action type. In this case, 00<br />
|-<br />
|<Feature> ||B||Which type of feature you would like to change<br />
|-<br />
|<Num-props> ||B||How many properties you would like to change per vehicle or station<br />
|-<br />
|<Num-info> ||B||How many vehicles/stations you would like to change<br />
|-<br />
|<Id> ||B*||The ID of the first vehicle/station to change<br />
|-<br />
|<Property> ||B||What property to change for each vehicle/station<br />
|-<br />
|<New-info> ||V||The new value of the property<br />
|}<br />
You can put an Action 0 anywhere after [[Action8|Action 8]] in the GRF file.<br />
<br />
The <Id> is an extended byte since 2.0.1 alpha 61, to support the definition of >255 sound effects. In OpenTTD since r13482, extended IDs (up to 65535) can be used for vehicles as well. However there is currently a caveat that articulated parts must be below 128.<br />
<br />
== Descriptions ==<br />
<br />
=== Sprite-number ===<br />
<br />
Action 0 can appear anywhere in the GRF file, so set it to the sprite number you are currently at.<br />
<br />
=== Length ===<br />
<br />
The total number of bytes in Action 0. Start counting from <Action>, the bit that sets the pseudo-sprite to act as the specified action.<br />
<br />
=== Action ===<br />
<br />
The type of action this pseudo-sprites defines. It should be 00 here because we want this pseudo-sprite to act as Action 0.<br />
<br />
=== Feature ===<br />
<br />
This sets the type of feature that you wish to change. Set it to:<br />
{|<br />
!Value!!Feature<br />
|-<br />
|00 || [[Action0Trains|trains]]<br />
|-<br />
|01 || [[Action0RoadVehicles|road vehicles]]<br />
|-<br />
|02 || [[Action0Ships|ships]]<br />
|-<br />
|03 || [[Action0Planes|planes]]<br />
|-<br />
|04 || [[Action0Stations|stations]]<br />
|-<br />
|05 || [[Action0Canals|canals]]<br />
|-<br />
|06 || [[Action0Bridges|bridges]]<br />
|-<br />
|07 || [[Action0Houses|houses]] (see [[DefaultHouseProps|defaults]])<br />
|-<br />
|08 || [[Action0GeneralVariables|global variables]]<br />
|-<br />
|09 || [[Action0IndustryTiles|industry tiles]] (see [[IndustryTileDefaultProps|defaults]])<br />
|-<br />
|0A || [[Action0Industries|industries]] (see [[IndustryDefaultProps|defaults]])<br />
|-<br />
|0B || [[Action0Cargos|cargos]] (see [[CargoDefaultProps|defaults]])<br />
|-<br />
|0C || [[Action0SoundEffects|sound effects]]<br />
|-<br />
|0D || [[Action0Airports|airports]]<br />
|-<br />
|0E || signals (Action 0 is not valid for this feature)<br />
|-<br />
|0F || [[Action0Objects|newobjects]]<br />
|-<br />
|10 || [[Action0Railtypes|rail types]] (OpenTTD r18969)<br />
|-<br />
|11 || [[Action0AirportTiles|airport tiles]] (OpenTTD r19204)<br />
|-<br />
|12 || towns (Action 0 is not valid for this feature)<br />
|}<br />
<br />
Note that the above list is the master list for ''all'' actions where not stated otherwise.<br />
<br />
=== Num-props ===<br />
<br />
This is the number of properties that you wish to change per vehicle or station. Note: even if you wish to set the same properties to the same value for different vehicles then you must still repeat the properties and their values for each vehicle.<br />
<br />
=== Num-info ===<br />
<br />
Simply the number of vehicles that you will change using this action 0.<br />
<br />
=== Id ===<br />
The [[VehicleIDs|Vehicle ID]] of the first vehicle or station to change. If num-info is greater than one, this vehicle/station and the following vehicles/stations will be changed.<br />
<br />
=== Property ===<br />
<br />
The number of the property that will be changed. This and the New-info section are repeated as many times as there are properties to set; in total, there are <<br />
num-props> property bytes.<br />
<br />
See relevant sub-section (links at the bottom) for more details.<br />
<br />
=== New-info ===<br />
<br />
The new information that will replace the previous information for the specified property. This is a variable size; dependent upon the property. Each property byte is followed by <num-info> new-info sections.<br />
The appropriate \b, \w, and \d escape sequences can be quite useful for most <<br />
new-info>s. See [[GRFActionsDetailed#Byte order|the discussion of escape sequences]] for further information.<br />
<br />
=== Features and properties ===<br />
<br />
Each feature has its own very specific properties. These are explained in detail in their separate pages.<br />
<br />
You will also find the minimum GRF version (in [[Action8|Action 8]]) that supports this property, or alternatively if the property was introduced between version changes, the patch version number that you can check with [[Action7|Action 7]].<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=BaseCosts&diff=1262BaseCosts2011-06-15T09:10:26Z<p>Terkhen: Fix table format</p>
<hr />
<div>This is a list of all base costs used by TTD.<br />
<br />
NFO ID is the ID to use for action 0 feature 8 property 08.<br />
<br />
Location is the address in the savegame structure.<br />
<br />
Default value is the initial value used at the game start.<br />
<br />
{| |-<br />
!ID!!NFO ID!!Location!!Default!!Used for!!Version<br />
|-<br />
|0||<center>0</center>||4B34||100||miscellaneous||<br />
|-<br />
|1||<center>1</center>||4B3A||100||build track||<br />
|-<br />
|2||<center>2</center>||4B40||95||build road||<br />
|-<br />
|3||<center>3</center>||4B46||65||place signal||<br />
|-<br />
|4||<center>4</center>||4B4C||275||build bridge tile||<br />
|-<br />
|5||<center>5</center>||4B52||600||build rail depot, also affects "build rail-waypoint" (*)||<br />
|-<br />
|6||<center>6</center>||4B58||500||build road depot||<br />
|-<br />
|7||<center>7</center>||4B5E||700||build ship depot||<br />
|-<br />
|8||<center>8</center>||4B64||450||build tunnel unit||<br />
|-<br />
|9||<center>9</center>||4B6A||200||build platform unit (per tile)||<br />
|-<br />
|10||<center>A</center>||4B70||180||build platform fixed (per platform)||<br />
|-<br />
|11||<center>B</center>||4B76||600||build airport tile||<br />
|-<br />
|12||<center>C</center>||4B7C||200||build bus station||<br />
|-<br />
|13||<center>D</center>||4B82||200||build lorry area||<br />
|-<br />
|14||<center>E</center>||4B88||350||build dock, also affects "build buoy" (*)||<br />
|-<br />
|15||<center>F</center>||4B8E||400,000||locomotive purchase||<br />
|-<br />
|16||<center>10</center>||4B94||2000||waggon purchase||<br />
|-<br />
|17||<center>11</center>||4B9A||700,000||aircraft purchase||<br />
|-<br />
|18||<center>12</center>||4BA0||14,000||road vehicle purchase||<br />
|-<br />
|19||<center>13</center>||4BA6||65,000||ship purchase||<br />
|-<br />
|20||<center>14</center>||4BAC||20||plant tree||<br />
|-<br />
|21||<center>15</center>||4BB2||250||raise/lower land, also affects "build foundation" (*)||<br />
|-<br />
|22||<center>16</center>||4BB8||20||clear grass||<br />
|-<br />
|23||<center>17</center>||4BBE||40||clear rough land, also affects "build/remove object" (*)||<br />
|-<br />
|24||<center>18</center>||4BC4||200||clear rocks||<br />
|-<br />
|25||<center>19</center>||4BCA||500||clear fields||<br />
|-<br />
|26||<center>1A</center>||4BD0||20||remove tree||<br />
|-<br />
|27||<center>1B</center>||4BD6||-70||remove track||<br />
|-<br />
|28||<center>1C</center>||4BDC||10||remove signal||<br />
|-<br />
|29||<center>1D</center>||4BE2||50||remove bridge tile, also affects "remove aqueduct" (*)||<br />
|-<br />
|30||<center>1E</center>||4BE8||80||remove rail depot, also affects "remove rail-waypoint" (*)||<br />
|-<br />
|31||<center>1F</center>||4BEE||80||remove road depot||<br />
|-<br />
|32||<center>20</center>||4BF4||90||remove ship depot||<br />
|-<br />
|33||<center>21</center>||4BFA||30||remove tunnel tile||<br />
|-<br />
|34||<center>22</center>||4C00||10,000||clear water, also affects "build/remove canal/lock" and "build aqueduct" (*)||<br />
|-<br />
|35||<center>23</center>||4C06||50||remove platform tile||<br />
|-<br />
|36||<center>24</center>||4C0C||30||remove airport tile||<br />
|-<br />
|37||<center>25</center>||4C12||50||remove bus station||<br />
|-<br />
|38||<center>26</center>||4C18||50||remove lorry area, also affects "remove buoy" (*) (**)||<br />
|-<br />
|39||<center>27</center>||4C1E||55||remove dock||<br />
|-<br />
|40||<center>28</center>||4C24||1600||remove house, also affects "remove industry" (*)||<br />
|-<br />
|41||<center>29</center>||4C2A||40||remove road||<br />
|-<br />
|42||<center>2A</center>||4C30||5600||steam engine running costs||<br />
|-<br />
|43||<center>2B</center>||4C36||5200||diesel engine running costs||<br />
|-<br />
|44||<center>2C</center>||4C3C||4800||electricengine running costs||<br />
|-<br />
|45||<center>2D</center>||4C42||9600||aircraft running costs||<br />
|-<br />
|46||<center>2E</center>||4C48||1600||road vehicle running costs||<br />
|-<br />
|47||<center>2F</center>||4C4E||5600||ship running costs||<br />
|-<br />
|48||<center>30</center>||4C54||1,000,000||funding industries, also affects "stuff with local authority", "build raw industry" and "fund town" (*)||<br />
|-<br />
|49||<center>31</center>||-||1600||remove industry||OpenTTD r18283<br />
|-<br />
|50||<center>32</center>||-||40||build object||OpenTTD r18283<br />
|-<br />
|51||<center>33</center>||-||40||remove object||OpenTTD r18283<br />
|-<br />
|52||<center>34</center>||-||600||build rail-waypoint||OpenTTD r18283<br />
|-<br />
|53||<center>35</center>||-||80||remove rail-waypoint||OpenTTD r18283<br />
|-<br />
|54||<center>36</center>||-||350||build buoy||OpenTTD r18283<br />
|-<br />
|55||<center>37</center>||-||50||remove buoy||OpenTTD r18283<br />
|-<br />
|56||<center>38</center>||-||1,000,000||stuff with town authority||OpenTTD r18283<br />
|-<br />
|57||<center>39</center>||-||250||build foundation||OpenTTD r18283<br />
|-<br />
|58||<center>3A</center>||-||8,000,000||build raw industry (in case prospecting is disabled)||OpenTTD r18283<br />
|-<br />
|59||<center>3B</center>||-||1,000,000||fund town||OpenTTD r18283<br />
|-<br />
|60||<center>3C</center>||-||5,000||build canal||OpenTTD r19720<br />
|-<br />
|61||<center>3D</center>||-||5,000||remove canal||OpenTTD r19720<br />
|-<br />
|62||<center>3E</center>||-||10,000||build aqueduct||OpenTTD r19720<br />
|-<br />
|63||<center>3F</center>||-||2,000||remove aqueduct||OpenTTD r19720<br />
|-<br />
|64||<center>40</center>||-||7,500||build lock||OpenTTD r19720<br />
|-<br />
|65||<center>41</center>||-||2,000||remove lock||OpenTTD r19720<br />
|}<br />
<br />
(*) if not set separately<br />
(**) yes, "remove buoy" is mentioned in this line, not in the line below<br />
<br />
Note: The newly added base costs of OpenTTD only apply if a base cost modifier is set for them. E.g. if NewGRF only set a base cost modifier for terraforming, but none for building foundations, the modifier for terraforming will also apply to building foundations, as that was the base cost used before the new one was added.<br />
<br />
Note that some values may be adjusted by certain constant factors before being used by the game, but that is a property of the place where it's used, not the base cost as such.<br />
<br />
Also, all constructions costs and all running costs are subject to modification by the game difficulty settings.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action7&diff=1255Action72011-06-15T07:20:35Z<p>Terkhen: Fix internal links</p>
<hr />
<div>== Introduction ==<br />
<br />
Action 7 & Action 9<br />
<br />
Conditionally skip sprites or jump to label<br />
<br />
==Description==<br />
<br />
These two actions allow you to skip a specified number or all following sprites in this .grf file. This can be used to have, for example, climate-specific graphics, patch-version checks and error messages, and deactivating in the presence of other active .grf files.<br />
<br />
==Syntax==<br />
<br />
The data looks as follows:<br />
<br />
<sprite-number> * <length> [07/09] <variable> <varsize> <condition-type> <value> <num-sprites> <br />
{|<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes in the action<br />
|-<br />
|07/09||B||Action type. In this case, 07 or 09<br />
|-<br />
|<variable>||B||Which variable to base the decision on<br />
|-<br />
|<varsize>||B||How many bytes to read from the variable<br />
|-<br />
|<condition-type>||B||What condition to check<br />
|-<br />
|<value>||V||Value to compare with (size equals <varsize>)<br />
|-<br />
|<num-sprites>||B||How many sprites to skip<br />
|}<br />
<br />
==Filling in the terms==<br />
<br />
===sprite-number===<br />
<br />
The current sprite number.<br />
<br />
===length===<br />
<br />
The total number of bytes in this action 7 or 9.<br />
<br />
===action===<br />
<br />
The type of action this pseudo-sprites defines. It is either 07 or 09, depending if you are using action 7 or action 9.<br />
<br />
Both have identical format, the only difference is whether sprites will be skipped during the initialisation of the TTDPatch graphics system, or only when the .grf file becomes active.<br />
<br />
Action 9 is always executed, both during initialisation and activation, but action 7 is executed only during activation.<br />
<br />
Depending on the action(s) you want to skip, you cannot always use both actions. If in doubt, use action 7 except to skip an action 6 or F. You must not skip an action 2 at all unless skipping the entire rest of the file. Instead, skip the action 3 that refers to it.<br />
<br />
Here's a table showing this whole action 7/9 issue:<br />
{|<br />
!Action to skip!!with 7!!with 9!!notes<br />
|-<br />
|0 (new props)||yes||yes||<br />
|-<br />
|1 (sprite blk)||yes||yes||<br />
|-<br />
|2 (cargo ID)||n/a*||no||* skip the corresponding action 3 instead<br />
|-<br />
|3 (veh ID map)||yes*||no||* can't skip a livery override without skipping the main engine action 3 as well<br />
|-<br />
|4 (veh names)||yes||no||<br />
|-<br />
|5 (sprite blk)||yes||yes||<br />
|-<br />
|6 (apply param)||n/a*||yes||* "yes" since 2.0.1 alpha 51<br />
|-<br />
|7 (skip sprite)||yes||yes||<br />
|-<br />
|8 (GRF ID)||yes||yes||<br />
|-<br />
|9 (skip sprite)||yes*||yes||* not during initialization, of course<br />
|-<br />
|A (repl.sprite)||yes||yes||<br />
|-<br />
|B (error msg)||yes||yes||<br />
|-<br />
|C (NOP)||yes||yes||<br />
|-<br />
|D (set param)||yes*||yes||* not if parameter will be used in action 6 (except for 2.0.1 alpha 51 and higher)<br />
|-<br />
|E (deact.GRFs)||yes||yes||<br />
|-<br />
|F (town names)||n/a||yes||<br />
|-<br />
|10 (goto labels)||n/a||no||<br />
|-<br />
|11 (sound fx)||n/a||no||<br />
|-<br />
|12 (glyphs)||yes||yes||<br />
|-<br />
|13 (translate)||yes||yes||<br />
|-<br />
|14 (static info)||n/a||n/a|| <br />
|}<br />
<br />
Yes=safe to skip<br />
<br />
No=not safe to skip, will break the grf file or TTDPatch<br />
<br />
N/A=not applicable; it won't break anything, but it won't actually be skipped either (in other words, its definitions will continue to be used)<br />
<br />
===variable===<br />
<br />
This sets the variable to base the decision on. It can be either one of the GRF parameters (see [[Action6|action 6]]), or a built-in patch variable. If it's a GRF parameter that wasn't specified in the newgrf(w).cfg file, or variable 88 with a GRFID that doesn't exist, the action 7 or 9 is ignored and no sprites are skipped, the only exception being condition type 0A which will skip the sprites if the GRFID doesn't exist as well.<br />
{|<br />
!'''Variable'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|81||B||current year (count from 1920, max. 2175 even with eternalgame)<br />
|-<br />
|83||B||Current climate: 00 = temp, 01 = arctic, 02 = trop, 03 = toyland<br />
|-<br />
|84||D||[[GrfLoadingStages|GRF loading stage]], see below<br />
|-<br />
|85||B||[[TTDPatchFlags|TTDPatch flags]]: only for bit tests<br />
|-<br />
|86||B||Road traffic side: bit 4 clear=left, set=right<br />
|-<br />
|88||4*B||Checks specified GRFID (see condition-types below)<br />
|-<br />
|8B||D||TTDPatch version, see below<br />
|-<br />
|8D||B||TTD version, 0=DOS, 1=Windows<br />
|-<br />
|8E||B||Y-Offset for train sprites<br />
|-<br />
|8F||4*B||Rail track type cost factors<br />
|-<br />
|92||B||Game mode, 0 in title screen, 1 in game and 2 in editor<br />
|-<br />
|93||D||Tile refresh offset to left<br />
|-<br />
|94||D||Tile refresh offset to right<br />
|-<br />
|95||D||Tile refresh offset upwards<br />
|-<br />
|96||D||Tile refresh offset downwards<br />
|-<br />
|9A||D||Has always all bits set; you can use this to make unconditional jumps<br />
|-<br />
|9D||D||TTD Platform, 0=TTDPatch, 1=OpenTTD<br />
|-<br />
|A1||D||OpenTTD version, see below.<br />
|-<br />
|A2||D||Difficulty level: 00= easy, 01=medium, 02=hard, 03=custom, since r12449 for OpenTTD and r1857 for TTDPatch<br />
|-<br />
|A3||D||Current date(4); long format, since r13376 in OpenTTD and r2048 in TTDPatch<br />
|-<br />
|A4||D||Current year(4); long format, year zero based since r13376 in OpenTTD and r2048 in TTDPatch<br />
|}<br />
<br />
Note 1: All other parameter values greater than 80 (hexadecimal) are reserved and must not be used in action 7 or 9.<br />
<br />
Note 2: The value of variable 88 can only be tested with the GRFID tests.<br />
<br />
Note 3: The tile refresh offsets are available from 2.0.1 alpha 39. See [[ActionD#Tile+refresh+offsets|Action D]] for more details on their use.<br />
<br />
Note 4: OpenTTD doesn't report the current date and year but the date and year the game was loaded. The reason lies in the fact that it was seen that use of this variable leads to desyncs in network games.<br />
<br />
Variable 84 is a BYTE variable up to TTDPatch 2.5r1220. Its lower byte (bits 0..7) are 0 for the post-load and GRF initialization stages and 01 for all other stages. The remaining bits are a bitmask, and including the lower byte have the following meaning:<br />
{|<br />
!Bit!!Meaning<br />
|-<br />
|0||Set after the "Initialization" stage completes<br />
|-<br />
|1..7||Always clear<br />
|-<br />
|8||Set during the "Reserve" stage only<br />
|-<br />
|9||Set during the "Activate" stage only<br />
|-<br />
|10||Set during the "Test" stage only<br />
|}<br />
<br />
Variable 8B has the following format: MMmrbbbb (though encoded in little endian as bb bb mr MM)<br />
{|<br />
!Element!!Meaning!!Value<br />
|-<br />
|MM||major||First number of the TTDPatch version<br />
|-<br />
|m||minor||Second number of the TTDPatch version<br />
|-<br />
|r||revision||Third number of the TTDPatch version*<br />
|-<br />
|bbbb||build||Alpha/beta version number times ten (up to an including 2.5 beta 5), SVN revision (from 2.5 beta 5 r418 on)<br />
|}<br />
<br />
Examples<br />
{|<br />
!Version!!Variable 8B!!Elements<br />
|-<br />
|1.9.1 alpha 50||019101F4|| MM=01, m=9, r=1, bbbb=50*10=01F4<br />
|-<br />
|2.0 beta 4||02040028||MM=02, m=0, r=4*, bbbb=4*10=0028<br />
|-<br />
|2.0 final||02070046||MM=02, m=0, r=7*, bbbb=70=0046<br />
|-<br />
|2.0 rev 1||02070050||MM=02, m=0, r=7*, bbbb=80=0050<br />
|-<br />
|2.0.1 alpha 3||020A001E||MM=02, m=0, r=10*, bbbb=3*10=001E<br />
|-<br />
|2.5 beta 2||02500014||MM=02, m=5, r=0, bbbb=2*10=0014<br />
|-<br />
|2.5 rev631||02500631||MM=02, m=5, r=0, bbbb=631=0631<br />
|}<br />
<br />
* For 2.0, r=7 and for 2.0.1 series, r=10 due to an oversight which used r=1..4 for 2.0 beta 1..4.<br />
<br />
To detect versions from 2.5 rev419 and up correctly, check that var. 8B is 02500419 or higher, or replace 0419 with the actual required revision (using the revision number as hex digits). Because SVN revisions are shared with other patch branches, it is important to check the actual patch version as well as the SVN revision.<br />
<br />
Variable A1 has the following format: Mmrbbbbb (though encoded in little endian as bb bb rb Mm). This variable has only a usefull meaning when variable 9D is 1 (OpenTTD). This variable can be used since OpenTTD r11330.<br />
{|<br />
!Element!!Meaning!!Value<br />
|-<br />
|M||major||First number of the OpenTTD version<br />
|-<br />
|m||minor||Second number of the OpenTTD version<br />
|-<br />
|r||revision||Third number of the OpenTTD version<br />
|-<br />
|bbbbb||build||Subversion revision of a build leading towards a release. When a final release is done 80000h is set.<br />
|}<br />
<br />
The presence of 80000h (bit 19 set) means that a release always has a higher version number than any builds leading to that release.<br />
<br />
Examples<br />
{|<br />
!Version!!Variable A1!!Elements<br />
|-<br />
|0.6.0 r11330||06002C42||M=0, m=6, r=0, bbbbb=11330=2C42<br />
|-<br />
|0.6.0 (release)||06080000||M=0, m=6, r=0, bbbbb=0=80000 (due to release)<br />
|}<br />
<br />
===varsize===<br />
<br />
For GRF parameters, this is the same as <param-size> in [[Action6#param%2Dsize|action 6]]. For built-in variables, it depends on the variable, see the above table.<br />
<br />
For bit tests, this size is ignored. Value must be a BYTE for bit tests, no matter what the size of the variable being tested.<br />
<br />
Since r1384 it is possible to set this to 8 bytes with Variable 88 thus allowing the use of a bit mask. This is useful for if only a few bits change over several grfs.<br />
<br />
===condition-type===<br />
<br />
There are several conditions you can choose from to test against. This has an escape sequence for each valid value. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information on escape sequences in general. For your convenience they are summed up in yet another table:<br />
{|<br />
!'''Condition type'''!!'''Escape'''!!'''Description'''<br />
|-<br />
|00||\71||Test for bit given by value being set<br />
|-<br />
|01||\70||Test for bit given by value being clear<br />
|-<br />
|02||\7=||Parameter is equal to value<br />
|-<br />
|03||\7!||Parameter is not equal to value<br />
|-<br />
|04||\7<||Parameter is less than value<br />
|-<br />
|05||\7>||Parameter is greater than value<br />
|-<br />
|06||\7G||GRF ID (see [[Action8|action 8]]) is active (for variable 88 only)<br />
|-<br />
|07||\7g||GRF ID is not active (for variable 88 only)<br />
|-<br />
|08||\7gG||GRF ID is not active yet but will be activated (variable 88 only)<br />
|-<br />
|09||\7GG||GRF ID is or will be active (variable 88 only)<br />
|-<br />
|0A||\7gg||GRF ID is not nor will it be active (variable 88 only)<br />
|-<br />
|0B||\7c||Cargo type is not available (variable is ignored; value is the label)*<br />
|-<br />
|0C||\7C||Cargo type is available (variable is ignored; value is the label)*<br />
|-<br />
|0D|| ||Rail type label is not defined (variable is ignored; value is the label)**<br />
|-<br />
|0E|| ||Rail type label is defined (variable is ignored; value is the label)**<br />
|}<br />
<br />
Note that for the characters, a capital letter means available, and a lowercase character means not available. For the two character GRFid sequences, the first character is its current state, and the second is its future state.<br />
<br />
* Prior to r11358, OTTD will skip these checks with variable 88.<br />
<br />
** Only in OpenTTD since r15418.<br />
<br />
The tests for variable 88 depend on the current [[GrfLoadingStages|GRF Loading Stage]], the order GRFs are loaded, and of course whether they are present or were disabled (by themself or by other GRFs). Consider two GRFs A and B (loaded in that order):<br />
<br />
<pre><br />
| Condition || Initialisation || Reservation/Activation || Tested GRF ||<br />
|<br />
| || A testing for B || B testing for A || A testing for B || B testing for A || not present ||<br />
|<br />
| ----------+-----------------------+------------------------+------------------------+------------------------||--------------||<br />
|<br />
|06 \\7G || always false || always false || always false || A not disabled? || always false ||<br />
|<br />
|07 \\7g || always true || always true || always true || A disabled? || always false ||<br />
|<br />
|08 \\7gG || always false || A not (yet) disabled? || B not (yet) disabled? || always false || always false ||<br />
|<br />
|09 \\7GG || always false || A not (yet) disabled? || B not (yet) disabled? || A not disabled? || always false ||<br />
|<br />
|0A \\7gg || B (already) disabled? || A (already) disabled? || B (already) disabled? || A disabled? || always true ||<br />
</pre><br />
<br />
If the tested GRF is not present, conditions 06 to 09 always evaluate to "false". For condition 0A "disabled" and "not present" are the same, i.e. it always evaluates to "true".<br />
<br />
===value===<br />
<br />
This term is what the variable is compared to. Its size is given by <varsize>.<br />
<br />
For bit tests (condition types 00 or 01), it must always be a single BYTE for bit tests and specifies the bit to test.<br />
<br />
For conditions 0B, 0C, 0D and 0E the value specifies directly the cargo/railtype label; it is no index into a translation table.<br />
<br />
For conditions 0B and (since 2.0.1 alpha 72) 0C, the variable given is ignored (but must be a valid variable nonetheless), the varsize must be 4 and the value must be the cargo label to check for. If no cargo with this label is defined in case of condition 0B, the given number of sprites are skipped. For condition 0C, the sprites are skipped if the cargo label has been defined. Both tests work irrespective of the order of .grf files in newgrf(w).cfg; the cargo is considered to be available even if it is defined by a later grf file. For this to work correctly, you ''must not'' skip a cargo definition with conditions 0B or 0C.<br />
<br />
The same holds for conditions 0D and 0E wrt. railtypes and their reservation.<br />
<br />
Since r1384, setting varsize to 8, changes value slightly, the first 4 bytes are the value (generalised grfid), and the next 4 bytes are a bit mask for the grfids to check. Please note you should make sure any masked bits are also not in the grfid to check, as value to check against is not currently masked.<br />
<br />
===num-sprites===<br />
<br />
This element sets how many sprites will be skipped if the condition is true. If num-sprites is zero, the entire rest of the .grf file will be skipped, otherwise exactly that many sprites will be skipped. If this causes action 8 to be skipped, the .grf file will be deemed inactive.<br />
<br />
If the condition is false, processing continues at the following sprite.<br />
<br />
Starting from TTDPatch 2.0.1 alpha 49, it is possible to jump to a certain position in the grf file by defining labels with [[Action10|action 10]]. If num-sprites is the number of a label defined somewhere in the file, then processing of the grf file resumes with the sprite following the label, instead of skipping that many sprites. This is the only way to skip more than 255 sprites at once.<br />
<br />
Since 2.0.1 alpha 70, duplicate labels are fully supported. The jump will always be to the first matching label that follows. If no matching label follows, the first matching label in the file will be used instead.<br />
<br />
Note that it is generally not safe to skip backwards, i.e. to an earlier position. While the patch will happily do that, you will get strange results if certain actions are repeated. Only action 0, 6, 7, 9, C and D are reasonably safe to execute more than once.<br />
<br />
==Examples==<br />
<br />
Let's start with an easy Action 7:<br />
<br />
47 * 6 07 83 01 03 00 00<br />
<br />
What does this Action 7 tells the programme to do with the fictional .grf file?<br />
{|<br />
!'''Byte'''!!'''Meaning'''<br />
|-<br />
|47||<sprite-number><br />
|-<br />
|6||<length> of the action in bytes; start counting at 07 (<action>)<br />
|-<br />
|07||<action>: sets this pseudo-sprite to function as action 7<br />
|-<br />
|83||<variable> 83 refers to the 4 different climates<br />
|-<br />
|01||<varsize>: amount of bytes to compare; a single byte for the climate<br />
|-<br />
|03||<condition-type> 03 means skip if the variable is not equal to the <value><br />
|-<br />
|00||<value> 00 equals temperate climate for this variable<br />
|-<br />
|00||<num-sprites> 00 means to skip the whole .grf file if the condition is true, i.e. for all climates except temperate in this case<br />
|}<br />
<br />
Therefore, this action 7 skips the rest of the file if it is being loaded in a climate other than the temperate climate.<br />
<br />
===Check for a specific TTDPatch version===<br />
<br />
Due to action 7 being skipped during initalization, and action B severity bit 7 not working before 2.0.1 alpha 66, the best way to check for the required patch version is the following sequence:<br />
<br />
// Check for 2.0.1 alpha 57, skip action B if present<br />
1 * 9 09 8B 04 05 39 02 0A 02 01<br />
// Abort with fatal action B if not (during its first activation)<br />
2 * 19 0B 03 1F 00 32 2E 30 2E 31 20 61 6C 70 68 61 20 35 37 00<br />
// Action 8<br />
3 * ... 08 06 ...<br />
// Skip rest of file if not 2.0.1 alpha 57,<br />
// to prevent meaningless "invalid sprite" errors<br />
4 * 9 09 8B 04 04 3A 02 0A 02 00~/pp~</pre><br />
<br />
This way the GRF Status entry shows the proper error message as well as the correct name and description because the action 8 is still being processed during initialization, and all unknown sprites are skipped so that the "invalid sprites" error message is not shown first (or else it would become the permanent message shown in the GRF Status Window).<br />
<br />
===Unconditional jump===<br />
<br />
Var 9A always has all bits set, so to make an unconditional jump you can use a bit test:<br />
<br />
~1 * 7 07 9A 01 00 00 01 resp.<br />
~1 * 7 07 9A 01 \\71 00 01<br />
<br />
What this does is that it checks if bit 0 from the first byte of variable 9A is set (which it always is), so the sprite which you put after this action 7 is always skipped.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action13&diff=1254Action132011-06-15T07:19:10Z<p>Terkhen: Improve readability of the page</p>
<hr />
<div>==Description==<br />
<br />
Translating regular strings is easy by just overwriting them with an [[Action4|action 4]], however this is not possible for translating GRF-specific strings in the D000 or DC00 range of IDs. Instead, these must be translated with this action 13.<br />
<br />
Available since 2.6 alpha 1 (r857).<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<sprite-number> * <length> 13 <feature> <grfid> <num-ent> <offset> <text...><br />
<br />
{|<br />
|-<br />
!'''Element'''<br />
![[GRFActionsDetailed|'''Size''']]<br />
!'''Description'''<br />
|-<br />
|&lt;sprite-number&gt;<br />
|dec<br />
|A sequential sprite number<br />
|-<br />
|&lt;length&gt;<br />
|dec<br />
|The total number of bytes in the action<br />
|-<br />
|13<br />
|B<br />
|Action 13<br />
|-<br />
|<grfid><br />
|4*B<br />
|The GRFID of the file whose texts are to be translated<br />
|-<br />
|<num-ent><br />
|B<br />
|Number of strings<br />
|-<br />
|<offset><br />
|W<br />
|First text ID<br />
|-<br />
|<text...><br />
|S<br />
|Zero-terminated strings<br />
|}<br />
<br />
<br />
For action 13, <num-ent>, <offset> and <text...> work exactly as for [[Action4|action 4]], but the offset may only refer to a text ID in the D000 or DC00 range of IDs.<br />
<br />
Action 13 is skipped if the given GRFID cannot be found or if the file is inactive; action 13 generates an error message and disables the current file if it appears before the GRF that it is translating.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action9&diff=1253Action92011-06-15T07:10:44Z<p>Terkhen: Fix style and format</p>
<hr />
<div>See [[Action7]]</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1252Storages2011-06-15T07:07:15Z<p>Terkhen: Add a note about town storage support</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' 100 (from TTDPatch r1246 to r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 10<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 10 for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns (since OpenTTD r22569)<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action12&diff=1201Action122011-06-14T22:12:00Z<p>Terkhen: </p>
<hr />
<div>==Introduction==<br />
<br />
This action allows loading and defining glyphs for any [http://www.unicode.org/ Unicode] character in the BMP (Basic Multilingual Plane), i.e. up to U+FFFF.<br />
<br />
''Note'': If any .grf file containing an action 12 is loaded (even if it is inactive), TTDPatch is put into UTF-8 mode. This changes how character input is processed and how custom strings are stored in the savegame (they are converted to UTF-8 encoding). It is not possible to prevent this, and because of possible bugs in UTF-8 mode it is therefore preferable to put all font glyphs in separate .grf files to allow them to not be loaded in the case of problems.<br />
<br />
Available since 2.0.1 alpha 73.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<sprite-number> * <length> 12 <num-def> <nowiki>(<font> <num-char> <base-char>){n}</nowiki><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes in the action<br />
|-<br />
|12||B||Action 12<br />
|-<br />
|num-def||B||Number of definitions<br />
|-<br />
|font||B||Font for which to provide glyphs<br />
|-<br />
|num-char||B||Number of consecutive glyphs<br />
|-<br />
|base-char||W||First Unicode character for which to provide glyphs<br />
|}<br />
<br />
Following the action 12 must be the real sprites for all glyphs, as many sprites as all <num-char> added up.<br />
<br />
Glyphs sprites may only use colors 00 (transparent), 01 (foreground) and 02 (shadow). A sprite that uses the shadow color MUST NOT use the [[RealSprites#compression|chunked data format]].<br />
<br />
==Description==<br />
<br />
===sprite-number===<br />
<br />
The current sprite number.<br />
<br />
===length===<br />
<br />
The total number of bytes in this action 12.<br />
<br />
===num-def===<br />
<br />
This specifies how many definitions follow, each having <font>, <basechar> and <numchar>.<br />
<br />
===font===<br />
<br />
The font to define glyphs for. The value can be 0 for the normal size, 1 for the small size, or 2 for the large size font.<br />
<br />
===num-char===<br />
<br />
The number of characters in the range.<br />
<br />
===base-char===<br />
<br />
The first Unicode character in a range to provide glyphs for. &nbsp;This can be any Unicode character in the BMP.<br />
<br />
Note that all characters of a definition (i.e., <font> <basechar> <numchar> triplet) must fit within a &quot;block&quot; of 128 characters, i.e. you cannot define characters U+00E0..U+011F with one definition; instead you must split it into U+00E0..U+00FF and U+0100..U+011F because those are two different blocks.<br />
<br />
==Example==<br />
<br />
583 * 10 12 02 00 08 F8 00 00 0C 00 01<br />
<br />
{| |-<br />
!'''Byte'''!!'''Meaning'''<br />
|-<br />
|583||<sprite-number><br />
|-<br />
|10||<length> of the action in bytes; start counting at 12 (<action>)<br />
|-<br />
|12||<action>: sets this pseudo-sprite to function as action 12<br />
|-<br />
|02||<num-def>: we're defining two ranges of characters<br />
|-<br />
|00||<nowiki><font></nowiki>: first range, defining font 0 (normal size)<br />
|-<br />
|08||<num-char>: defining 8 characters in a row<br />
|-<br />
|F8 00||<base-char>: character U+00F8 is the first character<br />
|-<br />
|00||<nowiki><font></nowiki>: second range, also defining font 0 (normal size)<br />
|-<br />
|0C||<num-char>: defining another 12 characters<br />
|-<br />
|00 01||<base-char>: character U+0100 is the first character<br />
|}<br />
<br />
Therefore, this action 12 defines glyphs for Unicode characters U+00F8..U+010B. They are split into two definitions because a definition cannot cross a block boundary.<br />
<br />
After this action 12 follow 20 real sprites containing the glyphs for the above characters.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action12&diff=1200Action122011-06-14T22:11:18Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
This action allows loading and defining glyphs for any [http://www.unicode.org/ Unicode] character in the BMP (Basic Multilingual Plane), i.e. up to U+FFFF.<br />
<br />
''Note'': If any .grf file containing an action 12 is loaded (even if it is inactive), TTDPatch is put into UTF-8 mode. This changes how character input is processed and how custom strings are stored in the savegame (they are converted to UTF-8 encoding). It is not possible to prevent this, and because of possible bugs in UTF-8 mode it is therefore preferable to put all font glyphs in separate .grf files to allow them to not be loaded in the case of problems.<br />
<br />
Available since 2.0.1 alpha 73.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<sprite-number> * <length> 12 <num-def> <nowiki>(<font> <num-char> <base-char>){n}</nowiki><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes in the action<br />
|-<br />
|12||B||Action 12<br />
|-<br />
|num-def||B||Number of definitions<br />
|-<br />
|font||B||Font for which to provide glyphs<br />
|-<br />
|num-char||B||Number of consecutive glyphs<br />
|-<br />
|base-char||W||First Unicode character for which to provide glyphs<br />
|}<br />
<br />
Following the action 12 must be the real sprites for all glyphs, as many sprites as all <num-char> added up.<br />
<br />
Glyphs sprites may only use colors 00 (transparent), 01 (foreground) and 02 (shadow). A sprite that uses the shadow color MUST NOT use the [[RealSprites#compression|chunked data format]].<br />
<br />
==Description==<br />
<br />
===sprite-number===<br />
<br />
The current sprite number.<br />
<br />
===length===<br />
<br />
The total number of bytes in this action 12.<br />
<br />
===num-def===<br />
<br />
This specifies how many definitions follow, each having <font>, <basechar> and <numchar>.<br />
<br />
===font===<br />
<br />
The font to define glyphs for. The value can be 0 for the normal size, 1 for the small size, or 2 for the large size font.<br />
<br />
===num-char===<br />
<br />
The number of characters in the range.<br />
<br />
===base-char===<br />
<br />
The first Unicode character in a range to provide glyphs for. &nbsp;This can be any Unicode character in the BMP.<br />
<br />
Note that all characters of a definition (i.e., <font> <basechar> <numchar> triplet) must fit within a &quot;block&quot; of 128 characters, i.e. you cannot define characters U+00E0..U+011F with one definition; instead you must split it into U+00E0..U+00FF and U+0100..U+011F because those are two different blocks.<br />
<br />
==Example==<br />
<br />
583 * 10 12 02 00 08 F8 00 00 0C 00 01<br />
<br />
{| |-<br />
!'''Byte'''!!'''Meaning'''<br />
|-<br />
|583||<sprite-number><br />
|-<br />
|10||<length> of the action in bytes; start counting at 12 (<action>)<br />
|-<br />
|12||<action>: sets this pseudo-sprite to function as action 12<br />
|-<br />
|02||<num-def>: we're defining two ranges of characters<br />
|-<br />
|00||<font>: first range, defining font 0 (normal size)<br />
|-<br />
|08||<num-char>: defining 8 characters in a row<br />
|-<br />
|F8 00||<base-char>: character U+00F8 is the first character<br />
|-<br />
|00||<font>: second range, also defining font 0 (normal size)<br />
|-<br />
|0C||<num-char>: defining another 12 characters<br />
|-<br />
|00 01||<base-char>: character U+0100 is the first character<br />
|}<br />
<br />
Therefore, this action 12 defines glyphs for Unicode characters U+00F8..U+010B. They are split into two definitions because a definition cannot cross a block boundary.<br />
<br />
After this action 12 follow 20 real sprites containing the glyphs for the above characters.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Industry_Tiles&diff=1196Action0/Industry Tiles2011-06-14T22:00:43Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
Industry tiles work similarly to town buildings, except that they are not stand-alone; they are always part of an industry.<br />
<br />
Defining industry tiles follows the same schema as houses do: to start using an ID, you first need to define it by setting property 8 for it. If you try to reference an ID (either via action0 or via action3) that isn't defined, your request is ignored, but not reported as an error, either. This means that if you want to conditionally define an ID, all you need to do is skipping the action0 that sets property8, and everything else gets skipped automatically.<br />
<br />
Industry tile IDs are unique within each grf file. In total, TTDPatch can have up to 256 new industry tile IDs (i.e. old tile types don't count). OpenTTD can have 512 IDs for all active grf files, but that includes non-overridden original tiles. The per-GRF ID is specified as a byte, which means no GRF can define more than 256 tile IDs. You should use your industry tile IDs sparingly. Variational action 2 variable 43 for industry tiles can help you limiting tile consumption to 2 or 3 per industry. Try to avoid using tile FFh, so it can be turned into an extended byte (in Action 3) in the distant future without breaking your NewGRF.<br />
<br />
==Properties==<br />
<br />
{| |-<br />
!Property !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|08||(a)||B||Substitute building type<br />
|-<br />
|09||(a)||B||Industry tile override<br />
|-<br />
|0A,0B,0C||(a)||W||Tile acceptance<br />
|-<br />
|0D||(b)||B||Land shape flags<br />
|-<br />
|0E||(c)||B||Callback flags<br />
|-<br />
|0F||(c)||W||Animation information<br />
|-<br />
|10||(c)||B||Animation speed.<br />
|-<br />
|11||(c)||B||Triggers for callback 25<br />
|-<br />
|12||(d)||B||Special flags<br />
|}<br />
<br />
(a) Available since TTDPatch 2.0.1 alpha 43<br />
<br />
(b) Available since TTDPatch 2.0.1 alpha 49<br />
<br />
(c) Available since TTDPatch 2.0.1 alpha 54<br />
<br />
(d) Available since TTDPatch 2.5 beta 2<br />
<br />
==Description==<br />
<br />
===Substitute tile type (08)===<br />
<br />
This tile type will be used instead of your new one if your definition isn't available for any reason. Valid values are [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#Class8 00h-AEh]. Assigning this property copies the properties of the old type just like it does with houses.<br />
<br />
If this tile's action 3 appears before this property is set, the action 3 will have no effect.<br />
<br />
===Industry tile override (09)===<br />
<br />
Works like the house override property for houses.<br />
<br />
===Tile acceptance (0A, 0B, 0C)===<br />
<br />
These three words define what cargoes the tile accepts, and how much of them. The low byte defines the type of the cargo according to the current climate, while the high byte defines the degree of acceptance in 1/8 units. If you don't need all three cargo types, just zero out the high byte of the extra properties.<br />
<br />
From GRF version 7 and above, the meaning of the low byte changes: instead of a climate-dependent cargo slot number, you have to give a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo bit. Acceptance of cargoes not currently present will automatically be disabled.<br />
<br />
===Land shape flags (0D)===<br />
<br />
This property defines which slopes the tile can be built on.<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||NW edge cannot be lowered<br />
|-<br />
|1||2||NE edge cannot be lowered<br />
|-<br />
|2||4||SW edge cannot be lowered<br />
|-<br />
|3||8||SE edge cannot be lowered<br />
|-<br />
|4||10||Can only be built on flat land<br />
|-<br />
|5||20||The tile is allowed on both land and water (only from alpha 58)<br />
|}<br />
<br />
Industry tiles are never built on steep slopes unless callback 2F is enabled, but bits 0..4 are ignored in that case.<br />
<br />
Bit 5 can be used to allow tiles of land industries built on water or vice versa. It effectively disables the land/water check code for the tile. If you need to customize the behavior further, you can use callback 2F to decide what kind of water/land is allowed.<br />
<br />
;'''PLEASE NOTE''': Be careful when setting this property. If you fail to set it correctly, your industry may end up building on a hillside, which is probably not what you want. The easiest way is to set bit 4 for middle tiles, bit 0 for the tiles along the SE edge, bit 1 for those along the SW edge and so on.<br />
<br />
===Callback flags (0E)===<br />
<br />
{| |-<br />
!Bit!!value!!meaning<br />
|-<br />
|0||1||use callback 26 to decide the next animation frame<br />
|-<br />
|1||2||use callback 27 to decide animation speed<br />
|-<br />
|2||4||use callback 2B to decide amount of acceptance (only from 2.0.1 a55 vcs 3)<br />
|-<br />
|3||8||use callback 2C to decide accepted types (only from 2.0.1 a55 vcs 3)<br />
|-<br />
|4||10||use callback 2F to check if a slope is suitable<br />
|-<br />
|5||20||use callback 30 to decide if default foundations need to be drawn<br />
|-<br />
|6||40||use callback 3C to allow or deny autosloping below the tile (only from 2.5 beta 3)<br />
|}<br />
<br />
Please note that callback 25 doesn't have a bit here. To use callback 25, simply set the wanted bits in property 11 and it will work as intended.<br />
<br />
===Animation information (0F)===<br />
<br />
The low byte specifies the number of animation frames minus one, so 00 means 1 frame, 01 means 2 frames etc. The maximum number of frames is 256, although you can have some problems if your animation exceeds FD (253) frames. The high byte must be 0 for non-looping animations and 01 for looping animations. Every other value is reserved for future use. In addition, if the whole word contains FFFF, animation is turned off for this tile (this is the default value).<br />
<br />
===Animation speed (10)===<br />
<br />
The meaning is the same as for house property 1B, but the lower limit is 0 instead of 2, so the fastest possible animation changes frames every game tick (27ms). The default value is 2.<br />
<br />
===Triggers for callback 25 (11)===<br />
<br />
Call callback 25 when:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||the construction state changes<br />
|-<br />
|1||2||the tile is processed in the periodic processing loop<br />
|-<br />
|2||4||the industry of the tile is processed in the periodic processing loop (synchronized animation)<br />
|-<br />
|3||8||the industry of the tile receives input cargo from a station<br />
|-<br />
|4||10||the industry distributes its output cargo to one of the stations nearby (from beta 2)<br />
|}<br />
<br />
===Special flags (12)===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||Callback 26 needs random bits<br />
|}<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Industries&diff=1195Action0/Industries2011-06-14T21:55:04Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
Industries work similarly to town buildings as well, except that the maximum number of possible industries is 37 in TTDPatch and 64 in OpenTTD. The non-overridden original types count towards this limit. Industries don't have a climate mask; you should simply not define an industry if it would be for the wrong climate.<br />
<br />
Defining industries follows the same schema as houses do: to start using an ID, you first need to define it by setting property 8 for it. If you try to reference an ID (either via action0 or via action3) that isn't defined, your request is ignored, but not reported as an error, either. This means that if you want to conditionally define an ID, all you need to do is skipping the action0 that sets property8, and everything else gets skipped automatically.<br />
<br />
==Properties==<br />
{| |-<br />
!Property !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|08||(a)||B||Substitute industry type<br />
|-<br />
|09||(a)||B||Industry type override<br />
|-<br />
|0A||(a)||V||Set industry layout(s)<br />
|-<br />
|0B||(a)||B||Industry production flags<br />
|-<br />
|0C||(a)||W||Industry closure message<br />
|-<br />
|0D||(a)||W||Production increase message<br />
|-<br />
|0E||(a)||W||Production decrease message<br />
|-<br />
|0F||(a)||B||Fund cost multiplier<br />
|-<br />
|10||(a)||W||Production cargo types<br />
|-<br />
|11||(a)||D||Acceptance cargo types<br />
|-<br />
|12,13||(a)||B||Production multipliers<br />
|-<br />
|14||(a)||B||Minimal amount of cargo distributed<br />
|-<br />
|15||(a)||V||Random sound effects<br />
|-<br />
|16||(a)||3*B||Conflicting industry types<br />
|-<br />
|17||(a)||B||Probability in random game<br />
|-<br />
|18||(a)||B||Probability during gameplay<br />
|-<br />
|19||(a)||B||Map color<br />
|-<br />
|1A||(a)||D||Special industry flags to define special behavior<br />
|-<br />
|1B||(a)||W||New industry text ID<br />
|-<br />
|1C,1D,1E||(a)||D||Input cargo multipliers for the three input cargo types<br />
|-<br />
|1F||(b)||W||Industry name<br />
|-<br />
|20||(b)||D||Prospecting success chance<br />
|-<br />
|21,22||(b)||B||Callback flags<br />
|-<br />
|23||(c)||D||Destruction cost multiplier<br />
|-<br />
|24||(d)||W||Default text for nearby station<br />
|}<br />
<br />
(a) Available since TTDPatch 2.0.1 alpha 45<br />
<br />
(b) Available since TTDPatch 2.0.1 alpha 49<br />
<br />
(c) Available since TTDPatch 2.0.1 alpha 73<br />
<br />
(d) Available since TTDPatch 2.6 alpha 0 r1782<br />
<br />
==Description==<br />
<br />
===Substitute industry type (08)===<br />
<br />
Substitute industry type. The first assignment of this property copies all properties of the old type to this new type. Unlike for houses, the substitute type won't replace this new type if the definition becomes unavailable. List of valid types: [[IndustryTypes]]<br />
<br />
There's a special use of this property beginning from alpha 70: if you set it to FFh, you can disable an original industry. In this case, the ID used must be the number of industry you want to disable. Disable requests are ignored for industries not present on the current climate and industries already overridden.<br />
<br />
===Industry type override (09)===<br />
<br />
Industry type override. The overridden industry type won't be built in new random games. If the GRF file becomes active after the game was started, industries of the overridden new type won't be replaced by the new type. List of valid types: [[IndustryTypes]]<br />
<br />
By overriding an old type, you're saying &quot;my type is a substitute for that old type&quot;. When GRFs ask information about the old type you've overridden (via industry variable 67, for example), they will get information about your type instead. If you want to replace an old industry type with something completely different, use the &quot;disable&quot; function of property 08 (see above), then define the new industry type ''without'' using property 09. A rule of thumb: if your industry accepts or produces different cargoes than the original one, it should not override the original one.<br />
<br />
For example, if you want to replace the old coal mine with something that changes its coal production more dynamically, use property 09 to override industry 00. This way, other industries that want to be far from coal mines will stay far from your industry type too. If, however, you want to replace the coal mine with a potash mine, do not use property 09. This will ensure that other industries don't consider your type as a coal mine.<br />
<br />
Please note, however, that only one new industry can override an old type. If two new types want to override the same old type, the first one wins, and the second is added normally, ignoring its property 09.<br />
<br />
===Set industry layout(s) (0A)===<br />
<br />
Format of industry layout tables:<br />
<br />
{| |-<br />
!Size!!Variable!!Meaning<br />
|-<br />
|B||numlayouts||The total number of layouts following<br />
|-<br />
|D||size||The size of the whole definition, excluding numlayouts and size<br />
|-<br />
|V||layouts||numlayout layouts, see format below<br />
|}<br />
<br />
Format of an industry layout:<br />
<br />
As a special case, if the first byte of a new industry layout is FEh, then only two bytes follow: the industry number and the layout number. The specified layout of the specified old industry type will be added to the layout list of the current industry. The following applies only if the first byte wasn't FEh<br />
<br />
{| |-<br />
!Size!!Variable!!Meaning<br />
|-<br />
|B||xoffs<br />
|-<br />
|B||yoffs||Offsets counted from the northernmost tile of the industry, specifying the position of the current tile. Both are taken as signed integers, but cannot go negative except the special case mentioned below.<br />
|-<br />
|B||oldtile||An old tile type to be put on the given tile<br />
|-<br />
|||--or--||<br />
|-<br />
|0xFE,W||newtile||The ID of an already defined industry tile, padded with 0 to create a word value. This tile type will be placed on the given tile.<br />
|-<br />
|||--or--||<br />
|-<br />
|0xFF|| ||The given tile is checked for clearance, but nothing will be placed on it. Useful to ensure some free space around your industry. This is the only case where xoffs and yoffs can be negative. If xoffs is negative, yoffs must be one lower than the wanted value.<br />
|}<br />
<br />
The layout consists of a list of the above tile definitions, terminated by two bytes: 0,80h<br />
<br />
===Industry production flags (0B)===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning!!Effect on nearby stations (a)!!Effect if CB 29 is disabled<br />
|-<br />
|0||1||extractive industry (e.g. coal mine)||suffix 'Mines' if some non-liquid, non-passenger, non-mail cargo is produced||Standard primary-industry production change<br />
|-<br />
|1||2||organic industry (e.g. forest)||suffix 'Forest' or 'Woods' if wood is produced||Standard primary-industry production change<br />
|-<br />
|2||4||processing industry (e.g. steel mill)||none||Standard processing-industry closing-behaviour<br />
|}<br />
<br />
Setting this property to 0 means no production changes and no closing, like e.g. the power station.<br />
<br />
(a) Behaviour of OTTD. TTDP behaviour is different.<br />
<br />
===Industry messages (0C..0E), new industry text ID (1B)===<br />
<br />
The text associated with these textID will be shown if the industry announces closedown, if the industry increases production, if the industry decreases production or when the industry is generated during the game.<br />
<br />
For the generation message, by default, all industries have &quot;New xxx is being constructed near yyy&quot;, except forests, that have &quot;New Forest is being planted near yyy&quot;.<br />
<br />
===Production cargo types (10)===<br />
<br />
Two climate-dependent cargo numbers representing the cargo types the industry can produce. Unused slots can be filled with FFh. List of valid types: [[CargoTypes]]<br />
<br />
===Acceptance cargo types (11)===<br />
<br />
Three climate-dependent cargo numbers representing the cargo types the industry can accept, plus a fourth filler byte which is always ignored. Unused slots can be filled with FFh. List of valid types: [[CargoTypes]]<br />
<br />
These cargo types will only be really accepted if the according acceptance of the industry tiles adds up to 8/8 or more.<br />
<br />
From GRF version 7 and above, the meaning of the above two properties will change: instead of climate-dependent cargo slot numbers, you have to give climate-independent cargo IDs. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo bit. Cargoes not currently present will be changed to FFh. Please note that TTD stops processing these lists at the first FFh value, so specifying absent cargoes isn't always safe.<br />
<br />
===Production multipliers (12, 13)===<br />
<br />
If nonzero, the industry periodically (every 256 ticks, that is 8 or 9 times in a month) produces the given amount from the according cargo type. The properties specify the amount produced at default production level, they are scaled equally on [[Callbacks#Random_production_change_29_|production changes]].<br />
<br />
===Minimal amount of cargo distributed (14)===<br />
<br />
The produced cargo will be distributed to stations only after it exceeds this amount.<br />
<br />
===Random sound effects (15)===<br />
<br />
The data starts with a byte defining the number of available effects, then one byte per effect. TTD periodically picks one of the available effects randomly, and plays it.<br />
<br />
===Conflicting industry types (16)===<br />
<br />
3 bytes define 3 types that won't appear in the vicinity of this industry. If a byte has bit 7 set, the bottom 6 bits are the ID of a new type already defined in the current GRF file. If bit 7 is clear, the bottom 6 bits specify an old industry type. FFh can be used to fill unused entries. You shouldn't modify property 9 after the type has been referenced by a property 16. List of valid types: [[IndustryTypes]]<br />
<br />
===Probability in random game (17), Probability during gameplay (18)===<br />
<br />
Old types have probabilities between 0 and 10. If the random game probability value is nonzero, at least one instance of this type is guaranteed to appear on the map.<br />
<br />
These probabilities are &quot;relative probabilities&quot;. That is, if you set the probability of industry A to twice the probability of industry B, industry A will appear about twice as often as B. Increasing the probabilities of all industries on the other hand changes nothing. The appearance probabilities have no influence on how many industries are placed in total.<br />
<br />
===Map colour (19)===<br />
<br />
The value must be a color index from the DOS pallette. The following values are used by default industries:<br />
<br />
{| |-<br />
!Number!!Colour!!Example<br />
|-<br />
|01||Black||Coal mine<br />
|-<br />
|0A||Gray||Steel mill<br />
|-<br />
|0F||White||Bank<br />
|-<br />
|25||Dark beige||Water supply<br />
|-<br />
|27||Light beige||Rubber plantation<br />
|-<br />
|30||Pink||Farm<br />
|-<br />
|37||Brown||Food processing plant<br />
|-<br />
|56||Green||Forest<br />
|-<br />
|98||Blue||Oil wells/oil rig<br />
|-<br />
|AE||Purple||Factory<br />
|-<br />
|B8||Red||Power station<br />
|-<br />
|BF||Yellow||Oil refinery<br />
|-<br />
|C2||Orange||Saw mill<br />
|-<br />
|D0||Light green||Water tower<br />
|}<br />
<br />
===Special industry flags to define special behavior (1A)===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||The industry periodically plants fields around itself (temperate and arctic farms)<br />
|-<br />
|1||2||The industry cuts trees around itself and produces its first output cargo from them (lumber mill)<br />
|-<br />
|2||4||The industry is built on water (oil rig)<br />
|-<br />
|3||8||The industry can only be built in towns (i.e. it has to replace houses) with population larger than 1200 (temperate bank)<br />
|-<br />
|4||10||The industry can only be built in towns (i.e. it has to replace houses) (arctic and tropic banks, water tower)<br />
|-<br />
|5||20||The industry is always built near towns (i.e. near town sign; additionally the industry is allowed to replace houses) (toy shop)<br />
|-<br />
|6||40||Fields are planted around the industry when it's built (all farms)<br />
|-<br />
|7||80||The industry cannot increase its production on the temperate climate (oil wells)<br />
|-<br />
|8||100||The industry is built only before 1950 (oil wells)<br />
|-<br />
|9||200||The industry is built only after 1960 (oil rig)<br />
|-<br />
|10||400||AI players will attempt to establish air and ship routes going to this industry (oil rig)<br />
|-<br />
|11||800||The industry can be exploded by a military airplane (oil refinery)<br />
|-<br />
|12||1000||The industry can be exploded by a military helicopter (factory)<br />
|-<br />
|13||2000||The industry can cause a subsidence (coal mine)<br />
|-<br />
|14||4000||Automatic production multiplier handing (No industry has this bit set by default.)<br />
|-<br />
|15||8000||The production callback needs random bits in var. 10 (No industry has this bit set by default.)<br />
|-<br />
|16||10000||(since r1925) Do not force one instance of this type to appear during initial map generation (No industry has this bit set by default.)<br />
|-<br />
|17||20000||(since r1925) Allow closing down the last instance of this type (No industry has this bit set by default.)<br />
|}<br />
<br />
If bit 14 is set, variables 40..42 will be divided by industry.prodmultiplier (variable 93), and the resulting instructions will be multiplied by the same amount before applying them. If you set this bit, please use small amounts in your instructions, since industry.prodmultiplier is 16 for default production, and can get as high as 128.<br />
<br />
By default, TTDPatch tries to ensure that cargo chains don't get broken. To achieve this, TTDPatch always generates at least one instance from every available industry type during random map generation, and prevents the last instance from closing down even when the production change callback says it should. If your industry type isn't essential for gameplay, or you want to handle this situation yourself, you can set bits 16 and/or 17 to turn off the default TTDPatch behavior.<br />
<br />
If you supply a lot of industry types but also want to support OpenTTD's small map sizes you should set bit 16 for the less important industry types which can be ommitted (there will likely not be enough space for an industry of every type).<br />
<br />
===Input cargo multipliers for the three input cargo types (1C..1E)===<br />
<br />
If the first (low) word of the property is M1 and the second (high) word is M2, and X units of the corresponding cargo is delivered to the industry, the output amounts are calculated this way:<br />
<br />
<pre>output_type1 = X*M1/256<br />
<br />
output_type2 = X*M2/256</pre><br />
<br />
The default value for old industry types is 0100h,0000h , so every unit of input cargo produces one unit of output cargo of the first type. Exceptions are temperate banks and oil rigs, that have the default value of 0000h,0000h ,so input cargo doesn't affect output.<br />
<br />
===Industry name (1F)===<br />
<br />
This is the text ID that will be attached to the town name when TTD texts refer to the industry.<br />
<br />
===Prospecting success chance (20)===<br />
<br />
This value is currently used only for extractive and organic industries (see property 0B for details). The higher this value is, the higher the chance that your industry can be built on a random place after prospecting. 0 means constant failure, while FFFFFFFFh means constant success.<br />
<br />
===Callback flags (21,22)===<br />
<br />
Property 21 can have the following bits set:<br />
<br />
{| |-<br />
!Bit!!Value!!Var. 0C!!Callback<br />
|-<br />
|0||1||22||Determine whether the industry can be built<br />
|-<br />
|1||2||00||Call the [[Action2Industries|production callback]] when cargo arrives at the industry<br />
|-<br />
|2||4||00||Call the [[Action2Industries|production callback]] every 256 ticks<br />
|-<br />
|3||8||28||Determine whether the industry can be built on given spot<br />
|-<br />
|4||10||29||Control random production changes<br />
|-<br />
|5||20||35||Monthly random production change<br />
|-<br />
|6||40||37||Cargo sub-type display<br />
|-<br />
|7||80||38||(from 2.0.1 a72 and above) Additional text in industry fund window<br />
|}<br />
<br />
It should be noted that OpenTTD will use smooth economy (if enabled) changes if none of the production callbacks flags are set.<br />
<br />
Otherwise, regular production changes will be used.<br />
<br />
Property 22 can have the following bits set:<br />
<br />
{| |-<br />
!Bit!!Value!!Var. 0C!!Callback<br />
|-<br />
|0||1||3A||(from 2.0.1 a72 and above) Show additional text in industry window<br />
|-<br />
|1||2||3B||(from 2.0.1 a73 and above) Control special industry effects<br />
|-<br />
|2||4||3D||(from 2.5 beta 4 and above) Opt out of accepting cargo<br />
|-<br />
|3||8||14A||(from 2.6 r1712 and above) Decide industry color<br />
|-<br />
|4||10||14B||(from 2.6 r1718 and above) Decide input cargo types<br />
|-<br />
|5||20||14C||(from 2.6 r1718 and above) Decide output cargo types<br />
|}<br />
<br />
===Destruction cost multiplier (23)===<br />
<br />
This value specifies the cost of removing the industry when the ctrl-dynamite function of morebuildoptions.removeindustry is enabled. This value is multiplied by the house removal cost multiplier to get the final cost. The default value is 1000 in TTDPatch, and 0 (zero) in OpenTTD.<br />
<br />
===Default name for nearby station (24)===<br />
<br />
If non-zero, this text ID specifies an additional name option for stations built near this industry, which will be used before any of the standard TTD names. The text should contain a \80, which will be the name of the nearby town.<br />
<br />
If the newly built station cannot use the specified text (because that name has been used for another station in the same town) the default TTD naming system will be used, but without the names &quot;\80 Oilfield&quot; or &quot;\80 Mines&quot;.<br />
<br />
Setting this to zero disables &quot;\80 Oilfield&quot; and &quot;\80 Mines&quot; without adding any additional station name options.<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=TTDPatchFlags&diff=1194TTDPatchFlags2011-06-14T21:48:48Z<p>Terkhen: Fix style and format</p>
<hr />
<div>In the table below you find all the TTDPatch flags that belong to <param-num> = 85 in Action 7 and Action 9.<br />
<br />
{| |-<br />
!'''Bit'''!!'''Switch (bit set = switch on)'''!!'''Correspondence in OpenTTD'''<br />
|-<br />
|0C||keepsmallairport||station.never_expire_airports<br />
|-<br />
|0D||newairports||1<br />
|-<br />
|0E||largestations||1<br />
|-<br />
|0F||longbridges||construction.longbridges<br />
|-<br />
|10||loadtime||0<br />
|-<br />
|12||presignals||1<br />
|-<br />
|13||extpresignals||1<br />
|-<br />
|16||enginespersist||vehicles.never_expire_vehicles<br />
|-<br />
|1B||multihead||1<br />
|-<br />
|1D||lowmemory||1<br />
|-<br />
|1E||generalfixes||1<br />
|-<br />
|27||moreairports||economy.station_noise_level<br />
|-<br />
|28||mammothtrains||1<br />
|-<br />
|29||trainrefit||1<br />
|-<br />
|2B||subsidiaries||0<br />
|-<br />
|2C||gradualloading||order.gradual_loading<br />
|-<br />
|32||(Set to bit 0 of unifiedmaglev mode)||1 (n/a)<br />
|-<br />
|33||(Set to bit 1 of unifiedmaglev mode)||1 (n/a)<br />
|-<br />
|34||bridgespeedlimits||1<br />
|-<br />
|36||eternalgame||1<br />
|-<br />
|37||newtrains||1<br />
|-<br />
|38||newrvs||1<br />
|-<br />
|39||newships||1<br />
|-<br />
|3A||newplanes||1<br />
|-<br />
|3B||signalsontrafficside||construction.signal_side<br />
|-<br />
|3C||electrifiedrailway||vehicle.disable_elrails<br />
|-<br />
|41 *||loadallgraphics||1<br />
|-<br />
|43||semaphores||1<br />
|-<br />
|4A||newobjects (since r2364)||1<br />
|-<br />
|4B||enhancegui||0<br />
|-<br />
|4C||newagerating||0<br />
|-<br />
|4D||buildonslopes||construction.build_on_slopes<br />
|-<br />
|4E||fullloadany||1<br />
|-<br />
|4F||planespeed||1<br />
|-<br />
|50 *||moreindustriesperclimate||0<br />
|-<br />
|51||moretoylandfeatures||0<br />
|-<br />
|52||newstations||1<br />
|-<br />
|53||tracktypecostdiff||1<br />
|-<br />
|54||manualconvert||1<br />
|-<br />
|55||buildoncoasts||construction.build_on_slopes<br />
|-<br />
|56||canals||1<br />
|-<br />
|57||newstartyear||1<br />
|-<br />
|58||freighttrains||vehicle.freight_trains > 1<br />
|-<br />
|59||newhouses||1<br />
|-<br />
|5A||newbridges||1<br />
|-<br />
|5B||newtownnames||1<br />
|-<br />
|5C||moreanimation||1<br />
|-<br />
|5D||wagonspeedlimits||vehicle.wagon_speed_limits<br />
|-<br />
|5E||newshistory||1<br />
|-<br />
|5F||custombridgeheads||0<br />
|-<br />
|60||newcargodistribution||0<br />
|-<br />
|61||windowsnap||1<br />
|-<br />
|62||townbuildnoroads||not (economy.allow_town_roads or _generating_world)<br />
|-<br />
|63||pathbasedsignalling||1<br />
|-<br />
|64||aichoosechances||0<br />
|-<br />
|65||resolutionwidth||1<br />
|-<br />
|66||resolutionheight||1<br />
|-<br />
|67||newindustries||1<br />
|-<br />
|68||fifoloading||order.improved_load<br />
|-<br />
|69||townroadbranchprob||0<br />
|-<br />
|6A||tempsnowline||0<br />
|-<br />
|6B||newcargos||1<br />
|-<br />
|6C||enhancemultiplayer||1<br />
|-<br />
|6D||onewayroads||1<br />
|-<br />
|6E||irregularstations||1<br />
|-<br />
|6F||morestatistics||1<br />
|-<br />
|70||newsounds||1<br />
|-<br />
|71||autoreplace||1<br />
|-<br />
|72||autoslope||1<br />
|-<br />
|73||followvehicle||0<br />
|-<br />
|74||trams||1<br />
|-<br />
|75||enhancetunnels||0<br />
|-<br />
|76||shortrvs||1<br />
|-<br />
|77||articulatedrvs||1<br />
|-<br />
|78||dynamicengines||vehicle.dynamic_engines, since r12924<br />
|-<br />
|7E||variablerunningcosts (since r1421)||1<br />
|-<br />
|7F||set if any switches are on||1<br />
|}<br />
<br />
<nowiki>*</nowiki> loadallgraphics is obsolete (and its bit unused) since revision 401. The next official versions were the 5/Jun/2006 nightly (402) and 2.5 beta 6 (472)<br />
<br />
<nowiki>*</nowiki> moreindustriesperclimate is obsolete (and its bit unused) since 2.5 beta 2.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Action6&diff=1193Action62011-06-14T21:45:07Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
Action 6 allows modifying the contents of the following sprite. It uses the values of the grf parameters and writes them into the data of the following sprite.<br />
<br />
This action is processed only once during the initialization of a .grf file and is ignored during the following activations every time a game is started or loaded. &nbsp;Therefore, to conditionally skip this action, you must use action 9 and not action 7.<br />
<br />
Since 2.0.1 alpha 51, this is no longer true, Action 6 will be applied both at initialization as well as activation. You can therefore use either action 7 or 9 to skip it, whichever is appropriate.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<sprite-number> * <Length> 06 (<param-num> <param-size> <offset>){n} FF<br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes used in this action<br />
|-<br />
|06||B||Defines action 06<br />
|-<br />
|<param-num>||B||Which grf parameter to apply<br />
|-<br />
|<param-size>||B||How many bytes to overwrite<br />
|-<br />
|<offset>||B*||Which byte to overwrite<br />
|-<br />
|<FF>||B||Marks the end of the list<br />
|}<br />
<br />
The triplet of <param-num> <param-size> <offset> can be repeated as often as desired.<br />
<br />
==Description==<br />
<br />
===Sprite-number===<br />
<br />
This is just the number you are at.<br />
<br />
===Length===<br />
<br />
Count the number of bytes in this action.<br />
<br />
===param-num===<br />
<br />
This is the parameter number from the newgrf(w).cfg parameters to apply to the following sprite data. It can of course be the result of an ActionD calculation as well. The first parameter has number 00.<br />
<br />
The modification is not carried out if the parameter has not been defined yet.<br />
<br />
===param-size===<br />
<br />
How many bytes of the parameter to use. If this is larger than 4 (the size of a parameter), the bytes of the following parameter are used. In that case, all required parameters must be defined or no modification will be done.<br />
<br />
If this value has bit 7 set, the parameter is ''added'' to the destination value, instead of simply stored. This is useful especially when allocating sprites using the GRF Resource Management, because one typically allocates more than one sprite, but the parameter can only hold a single number, the first sprite allocated. &nbsp;Thus, to apply several sprite numbers properly (such that it works for several activations, not just the first one), use an algorithm like the following:<br />
* Suppose you have a sprite number <nowiki><s></nowiki> to which you want to add <nowiki><i></nowiki> (where <nowiki><i></nowiki> is returned by the GRF Resource Management)<br />
* To make this work several times (whenever the grf is activated), you cannot simply add <nowiki><i></nowiki> to <nowiki><s></nowiki> directly<br />
* Instead, use [[ActionD]] to define a new, otherwise unused parameter <j>, and store in it the value of <nowiki><i></nowiki> before it is set by Action D, i.e. <j> holds the previous value of <nowiki><i></nowiki>.<br />
* Next, after setting <nowiki><i></nowiki> with the GRF Resource Management, calculate <j> = <nowiki><i></nowiki> - <j> (i.e. subtract the previous value of i from the new value of i and store in j).<br />
* Use Action 6 to add the value of <j> to <nowiki><s></nowiki>, instead of adding the value of <nowiki><i></nowiki> directly.<br />
* This way, the new value <nowiki><s></nowiki> is the current value of <nowiki><s></nowiki> plus the new <nowiki><i></nowiki> minus the old <nowiki><i></nowiki>, which is the initial value of <nowiki><s></nowiki> plus the new <nowiki><i></nowiki>, just what we wanted.<br />
* Skip the action D's as well as both action 6 and the action it modifies during the [[GrfLoadingStages|&quot;test&quot; stage]] by skipping these actions if action 7 var 84 has bit 10 set.<br />
* Make sure that when using action 7/9, that either ''both'' or ''none'' of the above two operations are skipped. if only one but not the other is skipped, the values will go out of synch.<br />
<br />
See below for an example.<br />
<br />
===offset===<br />
<br />
Number of byte in the following sprite to modify. The counting starts with 0 at the action byte and can go up to the length of the sprite. It is not possible to add data at the end of the sprite.<br />
<br />
Since TTDPatch 2.0.1 alpha 51, this is an extended byte (see [[GRFActionsDetailed]]).<br />
<br />
==Example==<br />
<br />
This is an example on how to apply the sprite numbers returned by the GRF Resource Management to an action 0:<br />
<br />
<pre>// First, set param 1 (<j>) to the old value of param 0 (<i>)<br />
<br />
&nbsp; -1 * 5 &nbsp; &nbsp; &nbsp; &nbsp;0D 01 00 00 00<br />
<br />
// Then, use the GRF Resource Management to reserve 3 sprites<br />
<br />
&nbsp; -1 * 9 &nbsp; &nbsp; &nbsp; &nbsp;0D 00 00 00 FE FF 08 03 00<br />
<br />
// Now calculate <j> = <i> - <j><br />
<br />
&nbsp; -1 * 5 &nbsp; &nbsp; &nbsp; &nbsp;0D 01 02 00 01<br />
<br />
// So <j> = new <i> - old <i><br />
<br />
// Use Action 6 to add <j> to the sprite numbers in the sample sprite layout<br />
<br />
&nbsp; -1 * 11 &nbsp; &nbsp; &nbsp; 06 01 84 07 01 84 11 01 84 1B FF<br />
<br />
&nbsp; -1 * 32 &nbsp; &nbsp; &nbsp; 00 04 01 01 00 09<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;01<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;00 00 00 00 &nbsp; &nbsp; // first allocated sprite<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;00 00 00 &nbsp;10 05 02 &nbsp;01 00 00 00 // second allocated sprite<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;00 0B 00 &nbsp;10 05 02 &nbsp;02 00 00 00 // third<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;80<br />
<br />
</pre></div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=TermConsistency&diff=1192TermConsistency2011-06-14T21:34:52Z<p>Terkhen: Storages done</p>
<hr />
<div>This is a list of terms that are used inconsistently on the wiki.<br />
<br />
Once the style fixes of the wiki are done, this list can relatively easily be auto-edited to a common style. Thus do not spend a long time to search for a term on all wiki pages, but just add all spellings found to this list<br />
<br />
<br />
{|<br />
!List of names!!Suggestion for achieving consistency<br />
|+<br />
|sprite, action, real sprite, action sprite, pseudo sprite||<br />
|+<br />
|Action X, ActionX||The main article is without spaces.<br />
|+<br />
|Town, City || Use town only.<br />
|+<br />
|GRFID, grfid, grfID||Always use GRFID.<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1191GRFSpecs:Todo2011-06-14T21:33:25Z<p>Terkhen: Note about examples</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''Page to be created''<br />
| ''Description of the 00-3f, 40-5f, 60-7f, 80-ff [[VarAction2Advanced]] variable ranges. Comment about why most 80-FF variables are not documented. Also mention the relation between VarAction2 and Action6/7/9/D variables.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[SpriteLayouts]]''<br />
| ''Move the general explanation (without syntax) for spritelayouts, sprite&recolour flags and bounding boxes for [[Action0Stations#Sprite_layout_.2809.29 | Stations]] and [[Action2HousesIndustryTiles | Houses/Industries/Airports/Objects]] to a separate page. Also incorporate examples for typical configurations for stations with track and normal buildings (e.g. [http://www.tt-forums.net/viewtopic.php?f=26&t=43236 | this general advice]).<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[RealSprites]]''<br />
| ''Add [http://www.tt-forums.net/viewtopic.php?f=26&t=38122&p=666637#p666637 further explanations and recommendations] about sprite compressions.<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
Examples should be short, well commented and clearly show how to use the featured item. See [[VarAction2Objects#Examples]]<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=RandomAction2&diff=1190RandomAction22011-06-14T21:30:45Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
Unlike [[VariationalAction2]], whose results are always determined by a predictable decision, RandomAction2 can use randomized results to pick one of several [[Action2]] entries.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <nowiki>[80|83]</nowiki> <random-triggers> <randbit> <nrand> <set-ids><br />
<br />
From 2.6 r1850 and OpenTTD r12452, and '''for vehicles only''':<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> 84 <count> <random-triggers> <randbit> <nrand> <set-ids><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<Sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes used in this action.<br />
|-<br />
|02||B||Defines action 02<br />
|-<br />
|<feature>||B||For what type of vehicle/station/... should this definition be used?<br />
|-<br />
|<set-id>||B||The ID of this action 2 (used like a cargo ID)<br />
|-<br />
|80, 83, 84||B||Type of random action, see below.<br />
|-<br />
|<count>||B||(when present) Location of controlling vehicle.<br />
|-<br />
|<random-triggers>||B||When to re-randomize<br />
|-<br />
|<randbit>||B||What random bit to use for this action 2<br />
|-<br />
|<nrand>||B||Number of set-ids to choose from, must be a power of 2<br />
|-<br />
|<set-ids>||W||Action 2 set-ids to choose from.<br />
|}<br />
<br />
==Description==<br />
<br />
===Sprite-number===<br />
<br />
This is just the number you are at.<br />
<br />
===Length===<br />
<br />
Count the number of bytes in this action.<br />
<br />
===feature===<br />
<br />
This sets the type of feature that you wish to change. Set it to:<br />
<br />
00 for trains<br />
<br />
01 for road vehicles<br />
<br />
02 for ships<br />
<br />
03 for planes<br />
<br />
04 for stations<br />
<br />
05 for canals<br />
<br />
07 for houses<br />
<br />
09 for industry tiles<br />
<br />
0A for industries<br />
<br />
0F for objects<br />
<br />
10 for rail types (available in OpenTTD > r18969)<br />
<br />
===set-ID===<br />
<br />
This defines the number of this action 2. &nbsp;The ID can then be used as target in an action 3 or another variational/random action 2.<br />
<br />
===80/83/84===<br />
<br />
Use 80 to randomize the object (vehicle, station, building, industry, object) based on its own triggers and bits.<br />
<br />
Use 83 to randomize the object based on its &quot;related&quot; object (s.b.).<br />
<br />
Use 84 to randomize the vehicle based on any vehicle in the consist.<br />
<br />
{| |-<br />
!Feature!!Related object<br />
|-<br />
|Vehicles (00-03)||First vehicle of consist<br />
|-<br />
|Stations (04)||N/A<br />
|-<br />
|Houses (07)||N/A<br />
|-<br />
|Industry tiles (09)||Industry containing tile<br />
|-<br />
|Industries (0A)||N/A<br />
|-<br />
|Objects (0F)||N/A<br />
|}<br />
<br />
===count===<br />
<br />
For type 84, this specifies which vehicle's random bits this vehicle will be using and/or modifying.<br />
<br />
The low nibble (bits 0-3) specifies how far to count from the starting vehicle. If it is zero, the count will be read from GRF register 100h instead.<br />
<br />
The high nibble (bits 6-7, actually) specifies which vehicle is the starting vehicle, and which direction to count:<br />
<br />
{| |-<br />
!0!!count back (away from the engine), starting at this vehicle<br />
|-<br />
|4||count forward (toward the engine), starting at this vehicle.<br />
|-<br />
|8||count back, starting at the engine<br />
|-<br />
|C||count back, starting at the first vehicle in this chain of vehicles with the same ID, as for vehicle variable 41<br />
|}<br />
<br />
Bits 4-5 are reserved and must be zero, so other values of the high nibble are not allowed.<br />
<br />
===random-triggers===<br />
<br />
This is a bit mask of triggers which cause re-randomizing. Normally, any matching trigger causes the graphics to be randomized again, but if you add 80 to the bitmask, the re-randomizing only happens if '''all''' triggers have occurred.<br />
<br />
Trigger bits are feature-specific, see below.<br />
<br />
===randbit===<br />
<br />
For versions before 2.0.1 alpha 30, leave this at 00. It doesn't quite work the way intended (it was supposed to allow independent random chains, but currently everything is re-randomized at the same time, thereby defeating this mechanism).<br />
<br />
Since 2.0.1 alpha 30, only those bits that actually get triggered will be re-randomized. &nbsp;Prior versions always re-randomized all bits. &nbsp;This will make it possible to have independent sets of bits for independent triggers (or untriggered bits, set only at the time of purchase). Setting randbit determines the first bit to be re-randomized, as well as basing the random graphics on. The total number of bits used is the 2-logarithm of nrand below (e.g., for nrand=16, 4 bits are used).<br />
<br />
===nrand===<br />
<br />
Number of different sets to choose from. &nbsp;This must be a power of 2, i.e. 2, 4, 8, 16 etc.<br />
<br />
===set-ids===<br />
<br />
Action 2 IDs to randomly choose from<br />
<br />
==Triggers==<br />
<br />
===Vehicles===<br />
<br />
Vehicles have 8 random bits, and the following triggers:<br />
<br />
{| |-<br />
!Bit!!Value!!Trigger<br />
|-<br />
|0||01||Vehicle gets new load of cargo (only after it was empty)<br />
|-<br />
|1||02||Vehicle enters a depot and is serviced<br />
|-<br />
|2||04||The consist has unloaded all cargo<br />
|-<br />
|3||08||Any vehicle of the consist receives cargo<br />
|-<br />
|4||10||Callback 32 returned 1<br />
|}<br />
<br />
The consist trigger bits 2 and 3 allow re-randomizing whenever the consist receives cargo after fully unloading. They should be used with action 2 type 80, not 83, and the random-triggers variable should have 80 added to it, to make the re-randomizing happen only if the consist was empty and '''then''' received new cargo.<br />
<br />
===Stations===<br />
<br />
Stations have 16+4 random bits. Bits 0 to 15 are a property of the station as a whole, and bits 16 to 19 are different for each tile. &nbsp;To get tile-based randomness, therefore use randbit=10 and nrand of no more than 16 (since only 4 random bits are available per tile).<br />
<br />
{| |-<br />
!Bit!!Value!!Trigger<br />
|-<br />
|0||01||new cargo waiting<br />
|-<br />
|1||02||no more cargo<br />
|-<br />
|2||04||train arrives (starts unloading/loading)<br />
|-<br />
|3||08||train leaves (done unloading & loading)<br />
|-<br />
|4||10||train loads or unloads cargo<br />
|-<br />
|5||20||train reserves platform (using PBS)<br />
|}<br />
<br />
Also note that none of the above triggers will actually trigger unless prop. 12 has at least one bit set. &nbsp;Triggers 01 will be triggered for any of the cargo types set in prop. 12, but trigger 02 will only be triggered if all of those cargo types have no more cargo waiting. Triggers 04, 08 and 20 are triggered no matter what cargo types the train transports, as long as prop. 12 is not zero.<br />
<br />
Triggers 04, 08, 10 and 20 only affect the platform on which they occur, as well as the random bits of the station, but not other platforms.<br />
<br />
===Town building triggers===<br />
<br />
Town buildings have 8 random bits.<br />
<br />
{| |-<br />
!Bit!!Value!!Trigger<br />
|-<br />
|0||01||the building tile is processed in the periodic tile processing loop<br />
|-<br />
|1||02||the top tile of the building is processed in the periodic tile processing loop<br />
|}<br />
<br />
The periodic tile processing loop constantly processes the tiles of the map, processing any given tile in every 256 ticks (approx. 3.5 TTD days). Since no &quot;real&quot; event happens to town buildings, you have only this opportunity to re-randomize the look of your building.<br />
<br />
If every 3.5 days is too fast for you, you can multiply the time-out by setting property 16 for the given tile. The time-out is 256 ticks*(prop. 16+1), so 0 means every 3.5 days, 1 means every 7 days, 2 means every 10.5 days and so on.<br />
<br />
If trigger 02 is activated, all parts of the building that has this trigger set will get the same random bits, allowing you to randomize a multi-tile building as one unit. On the other hand, if the tiles of a multi-tile building have trigger 1 set, all tiles will be randomized individually. Note that all tiles of a multi-tile building get the same value when building the building.<br />
<br />
===Industry tile triggers===<br />
<br />
Industry tiles have 8+16 random bits. &nbsp;Accessed through random action 2 type 80, you get 8 tile-specific bits, and accessed through random action 2 type 83, you get 16 industry-specific bits. &nbsp;The triggers are the same for both:<br />
<br />
{| |-<br />
!Bit!!Value!!Trigger<br />
|-<br />
|0||01||the building tile is processed in the periodic tile processing loop<br />
|-<br />
|1||02||triggers simultaneously for all tiles of the industry every 256 ticks. If the industry is a primary one, output cargo is generated at the same time.<br />
|-<br />
|2||04||cargo is delivered to the industry. If the industry is a processing one, output cargo is generated at the same time.<br />
|}<br />
<br />
Trigger 1 works similarly to trigger 1 for houses except that you cannot multiply the timeout: it's always 256 ticks.<br />
<br />
===Canals===<br />
<br />
Canals / Rivers have 8 random bits.<br />
<br />
There is currently no way to influence the random byte creation via triggers, internally the bits are feed from VarAction2Canals var 83 that is set when building a canal. Feature ids not supported by VarAction2Canals are undefined and should never be used.<br />
<br />
===Objects===<br />
<br />
Objects have around 8 random bits per tile of the object.<br />
<br />
There are no triggers for objects however.<br />
<br />
Also note that the random bits are unique to each tile in the object, and are not shared across the whole object.<br />
<br />
===Rail types===<br />
<br />
Rail tiles have 2 pseudo random bits, based on tile location.<br />
<br />
There are no triggers.<br />
<br />
===Other features===<br />
<br />
All features not mentioned in the list above have neither random bits nor triggers, including cities (which would be accessed using random action 2 type 83 for stations and industries).<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2&diff=1188VariationalAction22011-06-14T21:18:32Z<p>Terkhen: Clean up descriptions that are now at the storages page</p>
<hr />
<div>==Introduction==<br />
<br />
To support changes in graphics based on other factors than just the load states, you use a variational action 2. This provides a sophisticated way of deciding what graphics to use.<br />
<br />
A variational action 2 can be used like any other action 2, but it provides an additional step in-between: instead of defining the action 1 sets right away, it instead specifies a list of additional action 2 entry, one of which is used depending on the kind of variation that is defined. These action 2 entries that are referred can in turn be variational or random (to provide chains of decisions), or they can be the final element, that is a regular action 2 which contains definitions of action 1 sets, or a callback result.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> <nvar> (<set-id> <low-range> <high-range>){n} <default><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<Sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes used in this action.<br />
|-<br />
|02||B||Defines action 02<br />
|-<br />
|<feature>||B||For what type of vehicle/station should this definition be used?<br />
|-<br />
|<set-id>||B||The ID of this action 2 (used like a cargo ID)<br />
|-<br />
|<type>||B||Type of variational action 2, see below<br />
|-<br />
|<variable>||B||Which variable we base the decision on<br />
|-<br />
|<varadjust>||V||How to manipulate the value before deciding.<br />
|-<br />
|<nvar>||B||Number of different ranges of the value (not counting the default)<br />
|-<br />
|<set-id>||W||Action 2 set-id to use for the following range.<br />
|-<br />
|<low-range>||B/W/D||Minimum (inclusive) of the range for which to use the above set-id<br />
|-<br />
|<high-range>||B/W/D||Maximum (inclusive) of the range<br />
|-<br />
|<default>||W||Action 2 set-id to use if no range matches<br />
|}<br />
<br />
You repeat the sequence of <set-id> <low-range> <high-range> as often as <nvar> specifies.<br />
<br />
<low-range> and <high-range> have a size of B, W, or D, depending on <type>. See that entry for more information.<br />
<br />
==Description==<br />
<br />
===Sprite-number===<br />
<br />
This is just the number you are at.<br />
<br />
===Length===<br />
<br />
Count the number of bytes in this action.<br />
<br />
===feature===<br />
<br />
This sets the type of feature that you wish to change. Set it to:<br />
<br />
00 for trains<br />
<br />
01 for road vehicles<br />
<br />
02 for ships<br />
<br />
03 for planes<br />
<br />
04 for stations<br />
<br />
05 for canals<br />
<br />
06 for bridges<br />
<br />
07 for houses<br />
<br />
09 for industry tiles<br />
<br />
0A for industries<br />
<br />
0B for cargos<br />
<br />
0E for signals<br />
<br />
0F for objects<br />
<br />
10 for railtypes<br />
<br />
===Set-ID===<br />
<br />
This defines the number of this action 2. &nbsp;The ID can then be used as target in an action 3 or another variational/random action 2.<br />
<br />
===Type===<br />
<br />
The access type specifies both the size of the variable access, and selects between general variables and the object's innate variables, or variables of a specific &quot;related&quot; object.<br />
<br />
Use 81/85/89 to decide upon a general variable, or a variable of the object in question.<br />
<br />
Use 82/86/8A to refer to the &quot;related&quot; object:<br />
<br />
{| |-<br />
!Feature!!Related object<br />
|-<br />
|Vehicles (00-03)||First vehicle of consist<br />
|-<br />
|Stations (04)||Town to which station belongs<br />
|-<br />
|Canals (05)||N/A<br />
|-<br />
|Bridges (06)||Town of bridge<br />
|-<br />
|Houses (07)||Town of building<br />
|-<br />
|Generic (08)||(no action 2 support)<br />
|-<br />
|Industry tiles (09)||Industry containing tile<br />
|-<br />
|Industries (0A)||Town to which industry belongs<br />
|-<br />
|Cargos (0B)||N/A<br />
|-<br />
|Sounds (0C)||(no action 2 support)<br />
|-<br />
|Airports (0D)||Town of airport<br />
|-<br />
|Signals (0E)||N/A<br />
|-<br />
|Objects (0F)||Town of object<br />
|-<br />
|Railtypes (10)||N/A<br />
|}<br />
<br />
This number also tells what size the checked variable is:<br />
<br />
For 81/82, the lowest byte of the value is accessed<br />
<br />
For 85/86, the lowest word is accessed<br />
<br />
For 89/8A, the lowest doubleword is accessed.<br />
<br />
If the accessed variable is smaller than the size given here, the extra bits may contain junk, and should probably be <and-masked> out.<br />
<br />
On this page, the size B/W/D means the field is byte-sized for types 81 and 82, word-sized for types 85 and 86, and doubleword-sized for types 89 and 8A.<br />
<br />
===Variable===<br />
<br />
Which variable to use for this decision. The following variables are always available:<br />
<br />
{| |-<br />
!'''Number'''!![[GRFActionsDetailed|'''Size''']]!!'''Meaning'''<br />
|-<br />
|00||W||current date (counted as days from 1920)<br />
|-<br />
|01||B||current year (count from 1920, max. 2175 even with eternalgame)<br />
|-<br />
|02||B/D||current month (0-11) in bits 0-7; the higher bytes contain unusable junk. Since OTTD r13594 'day of month' (0-30) is stored in bits 8-12, bit 15 is set in leapyears and 'day of year'(0-364 resp. 365) is stored in bits 16-24. All other bits are reserved and should be masked.<br />
|-<br />
|03||B||current climate, 0=temp, 1=arctic, 2=trop, 3=toyland<br />
|-<br />
|09||W||date fraction, incremented by 0x375 every engine tick<br />
|-<br />
|0A||W||animation counter, incremented every tick<br />
|-<br />
|0C||W||current [[Callbacks|callback]] ID (feature-specific), set to 00 when not in a callback<br />
|-<br />
|10||D||extra callback info 1, as described in the callback specs<br />
|-<br />
|11||B||current rail tool type (for station callbacks)<br />
|-<br />
|12||B||Game mode, 0 in title screen, 1 in game and 2 in editor<br />
|-<br />
|18||D||extra callback info 2, as described in the callback specs<br />
|-<br />
|1A||D||always -1 (that is, all bits are set). Useful to create constants (see [[VarAction2Advanced]])<br />
|-<br />
|1B||B||display options; bit 0=town names, 1=station names, 2=signs, 3=animation, 4=transparency, 5=full detail<br />
|-<br />
|1C||D||result from most recent variational action 2<br />
|-<br />
|20||B||snow line height, FFh if snow isn't present at all<br />
|-<br />
|23||D||current date; long format, since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|24||D||current year; long format, year zero based since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|25||D||GrfID of the grf that contains the corresponding Action3. Useful when accessing the &quot;related&quot; object. Currently only supported for vehicles (OpenTTD r15739)<br />
|-<br />
|40+x||D||specially calculated feature-specific variable, see following feature-specific pages<br />
|-<br />
|5F||D||Feature-specific random data: triggers in low byte, bits in other three bytes. Bits of the variable not associated with random or trigger bits are reserved. (2.5 r1927, 2.6 r1928)<br />
|-<br />
|60+x||D||similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter.<br />
|-<br />
|7B||-||A special 60+x variable to be used in Advanced Variational Action 2. It allows to evaluate any other 60+x variable using a non-constant parameter from a register. The parameter of variable 7B specifies another 60+x variable which is evaluated. The parameter for that variable is read from the accumulator ('val1'), i.e. the result from the preceding operations of the same Advanced Variational Action 2. Hence variable 7B may not be the first variable used in the calculation. Variable 7B itself and 7E (procedure call) are not allowed to be used as parameter for variable 7B. Also note that you can pass non-byte parameters to 60+x variable here. While current 60+x variables only use byte parameters, the higher bits of the parameter are considered reserved. So, make sure to mask the higher bits in the preceding calculations. Available since TTDPatch r2359 and OpenTTD r21604.<br />
|-<br />
|7C||D||A special 60+x variable used to access values stored in the registers of [[Storages#Persistent_storage|persistent storage]]. Available since 2.6 r1315.<br />
|-<br />
|7D||D||A special 60+x variable used to access values stored in the registers of [[Storages#Temporary_storage|temporary storage]]. Available since 2.6 r1246. Available in the purchase list.<br />
|-<br />
|7E||D||A special 60+x variable indicating a [[VarAction2Advanced#Using_procedures|procedure call]]. Available in the purchase list.<br />
|-<br />
|7F||D||A special 60+x variable that reads GRF parameter whose number is given by the 60+x parameter. Available in the purchase list.<br />
|-<br />
|80+x|| ||feature-specific variable, see following feature-specific pages<br />
|}<br />
<br />
The definition of variable 1B is slightly feature-dependent. For features that can be drawn transparently (stations, bridges, houses, industry tiles and objects) bit 4 is set if the current feature will be drawn normally, and clear if the current feature will be drawn transparently. For these purposes, airports are stations. For all other features, bit 4 is undefined.<br />
<br />
For all features, the 80+x variables are offsets into the corresponding structure in TTD's game data. &nbsp;The 40+x and 60+x variables are special variables that are computed on-the-fly, and aren't actually stored anywhere in memory, unless stated otherwise. Therefore they should be used as little as necessary so as not to slow down the game too much with the calculation of these variables (which can be called thousands of times per second, whenever any vehicle moves).<br />
<br />
When displaying a vehicle (etc.) in the purchase list, the game will show those variations based on external variables (dates etc.) correctly, but variations based on vehicle variables (variables 40+x, 60+x and 80+x) will always show the first (not the default) cargo-ID unless otherwise specified for the given variable. If you do a calculation, the first cargo-ID will be selected if any of the needed variables is inaccessible.<br />
<br />
The lists of 80+x variables on the following pages are not exhaustive; only the useful variables are listed there. For a full list check the definition of corresponding structures in TTD. Marcin Grzegorczyk has a pretty good list of the structure definitions on his [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html|savegame internals page].<br />
<br />
===varadjust===<br />
<br />
Adjust variable to a more useful range. It has the following format:<br />
<br />
<pre> <shift-num> <and-mask> <nowiki>[<add-val> <divide-val>/<modulo-val>]</nowiki></pre><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|shift-num||B||value to right-shift the variable, and some special bits. See below.<br />
|-<br />
|and-mask||B/W/D||value with which to AND the variable after shifting. Return this value if neither bit 6 nor bit 7 of shift-num are set.<br />
|-<br />
|add-val||B/W/D||value to add to the variable after ANDing. Only present if bits 6 or 7 are set in shift-num.<br />
|-<br />
|divide-val||B/W/D||return the sum divided by this value. Only present if bit 6 is set in shift-num.<br />
|-<br />
|modulo-val||B/W/D||return the sum modulo (remainder of division by) this value. Only present if bit 7 is set in shift-num.<br />
|}<br />
<br />
<shift-num> is a partial bit-mask; its bits have the following meanings:<br />
<br />
{| |-<br />
!Bit(s)!!value!!meaning<br />
|-<br />
|0..4||0..1F||number of bits to right shift <variable><br />
|-<br />
|5||20||This is an [[VarAction2Advanced|advanced var.action 2]]<br />
|-<br />
|6||40||This is a shift-and-add-divide adjustment.<br />
|-<br />
|7||80||This is a shift-and-add-modulo adjustment.<br />
|}<br />
<br />
Bits 6 and 7 may not both be set. If neither are set, this varadjust is a shift-and adjustment.<br />
<br />
Note that for the add and divide operations, both the variable and the divisor are taken to be signed numbers. This means that if the high bit is set, the number is taken to be negative, so you may need to mask out the most significant bit to do an unsigned division.<br />
<br />
===nvar===<br />
<br />
Here you set how many different ranges to check for. If the value of the variable, after the above manipulations, is not within one of these ranges, the default will be used. &nbsp;When displayed in the purchase window, the game will always show the first range if the variable is of the 40+x or 80+x type (because the variable is undefined since the vehicle doesn't exist yet).<br />
<br />
Since 2.0.1 alpha 57, nvar=0 is a special case. Instead of using ranges, nvar=0 means that the result of an [[VarAction2Advanced|advanced]] calculation (or, if no calculation is performed, the adjusted variable value itself) is returned as callback result, with bit 15 set. &nbsp;This is useful for those callbacks where many different return values are possible and it is easier to calculate them than list them in ranges. &nbsp;The default value must still be specified, and will be used in case the variable(s) used are not available.<br />
<br />
===sets and ranges===<br />
<br />
For each of the ranges to check, you give the set-id as a '''WORD''' value (i.e. with a 00 following, e.g. set-id 5 becomes 05 00, or - in case of a callback result - by setting the high bit, e.g. 05 80), followed by the low and high limits of this range. &nbsp;The first range that matches will be used.<br />
<br />
The various \b, \w, and \d escape sequences can be useful for <min-range> and <max-range>. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information.<br />
<br />
===default===<br />
<br />
The set-id to use if none of the ranges matches.<br />
<br />
=Example=</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1187Storages2011-06-14T21:15:59Z<p>Terkhen: Add note about access to persistent storage by unsupported features</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' 100 (from TTDPatch r1246 to r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 10<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 10 for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VarAction2Advanced&diff=1186VarAction2Advanced2011-06-14T21:12:46Z<p>Terkhen: Clean up descriptions that are now at the storages page</p>
<hr />
<div>==Introduction==<br />
<br />
A regular action 2 can access one variable and perform limited modifications on it (shift, and, add, divide/modulo) instead of a simple variable access. Using an advanced action 2, it is possible to do a nearly unlimited number of many different operations on several variables.<br />
<br />
In addition, using procedure calls (with variable 7E), it is possible to reuse variational action 2 blocks in several places on the NFO code.<br />
<br />
==Format==<br />
<br />
An advanced variational action 2 looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> '''[<operator> <variable> <varadjust>]'''... <nvar> (<set-id> <low-range> <high-range>){n} <default><br />
<br />
The new elements are the <operator> (a byte), followed by another <variable> and <varadjust> pair. &nbsp;This sequence may be repeated as often as necessary, by setting the appropriate bit in the previous <varadjust> (see below).<br />
<br />
===varadjust===<br />
<br />
<varadjust> itself has the same format as a regular var. action 2, however to perform a calculation, bit 5 in <shift-num> has to be set:<br />
<br />
{|<br />
!Bit(s)!!Value!!Meaning<br />
|-<br />
|0..4||0..1F||number of bits to right shift <variable><br />
|-<br />
|5||20||'''an <operator> <variable> <varadjust> triple follows this <varadjust>'''<br />
|-<br />
|6||40||This is a shift-and-add-divide adjustment.<br />
|-<br />
|7||80||This is a shift-and-add-modulo adjustment.<br />
|}<br />
<br />
Bit 5 needs to be set for each <shift-num>, except the last one that isn't going to be followed by another calculation (i.e., <operator> <variable> <varadjust> set). Bit 5 clear terminates the calculation and uses the resulting value for checking the ranges determining the set-id to use (or, if nvar=0, as a callback result).<br />
<br />
===operator===<br />
<br />
This field, and the following variable/varadjust pair, exist only if the previous shift-num had bit 5 set. This field has escape sequences for each of its valid values, as shown in the table below. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information on escape sequences in general. Can have the following values:<br />
<br />
{|<br />
!Value!!Escape!!Effect!!Notes<br />
|-<br />
|00||\2+||result = val1 + val2||<br />
|-<br />
|01||\2-||result = val1 - val2||<br />
|-<br />
|02||\2<||result = min(val1, val2)||val1 and val2 are both considered signed<br />
|-<br />
|03||\2>||result = max(val1, val2)||val1 and val2 are both considered signed<br />
|-<br />
|04,05||\2u<, \2u>||result = max(val1, val2)||Same as 02/03, but operands are considered unsigned<br />
|-<br />
|06||\2/||result = val1 / val2||val1 and val2 are both considered signed<br />
|-<br />
|07||\2%||result = val1 mod val2||val1 and val2 are both considered signed<br />
|-<br />
|08,09||\2u/, \2u%||result = val1 mod val2||Same as 06/07, but operands are considered unsigned<br />
|-<br />
|0A||\2*||result = val1 * val2||result will be truncated to B/W/D (that makes it the same for signed/unsigned operands)<br />
|-<br />
|0B||\2&||result = val1 & val2||bitwise AND<br />
|-<br />
|0C||\2<nowiki>|</nowiki>||result = val1 <nowiki>|</nowiki> val2||bitwise OR<br />
|-<br />
|0D||\2<nowiki>^</nowiki>||result = val1 <nowiki>^</nowiki> val2||bitwise XOR<br />
|-<br />
|0E||\2s or \2sto (a)||var7D[val2] = val1, result = val1||Store result, available since 2.6 r1246. See [[Storages#Temporary_storage|Temporary storage]].<br />
|-<br />
|0F||\2r or \2rst (a)||result = val2||Available since 2.6 r1246<br />
|-<br />
|10||\2psto (c)||var7C[val2] = val1, result = val1||Store result into persistent storage, available since 2.6 r1315. See [[Storages#Persistent_storage|Persistent storage]].<br />
|-<br />
|11||\2ror or \2rot (b)||result = val1 rotate right val2||Always a 32-bit rotation. Available since 2.6 r1651<br />
|-<br />
|12||\2cmp (c)||see notes||Result is 0 if val1<val2, 1 if val1=val2 and 2 if val1>val2. Both values are considered signed. Available since 2.6 r1698 (*)<br />
|-<br />
|13||\2ucmp (c)||see notes||The same as 12, but operands are considered unsigned. Available since 2.6 r1698 (*)<br />
|-<br />
|14||\2<< (c)||result = val1 << val2||shift left; val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|-<br />
|15||\2u>> (c)||result = val1 >> val2||shift right (unsigned); val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|-<br />
|16||\2>> (c)||result = val1 >> val2||shift right (signed); val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|}<br />
<br />
where val1 is the value resulting from the current variable/varadjust pair (or the result of the previous calculations if this isn't the first pair) and val2 is the value resulting from the following variable/varadjust pair. By setting bit 5 of shift-num repeatedly, you can combine several variables together before making your decision.<br />
<br />
(a) Supported since grfcodec and nforenum r1265 (1.0.0 and 3.4.4, respectively.)<br />
<br />
(b) Supported since grfcodec and nforenum r1655 (1.0.0 and 3.4.6, respectively.)<br />
<br />
(c) Supported since grfcodec 1.0.0 and nforenum 4.0.0.<br />
<br />
<nowiki>*</nowiki> Operations 12 and 13 should be preferred over operation 01 (subtraction) when only the relation of the two values is needed and the difference itself is irrelevant. This is because operation 01 can overflow and give the wrong sign if the difference is too big, but comparisons work correctly for all values.<br />
<br />
Note that a bitwise NOT can be done by XORing with variable 1A. Similarly, you can specify literal values (i.e. plain numbers instead of variables), by using variable 1A and an and-mask of the value you want. For example, to specify a literal 26, use variable=1A, shift-num=00 (or the higher bits set if you need further calculations), and and-mask=26. This works with B, W or D sized literals if you use the right and-mask size for the given type of action 2. The appropriate \b, \w, or \d escape sequence can be useful for specifying literals. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information.<br />
<br />
Operator 0F is only useful when using variable 7B, or immediately after operators 0E or 10, to store the result of a calculation, and then discard that result and start fresh.<br />
<br />
===Using types 81/82 (etc) simultaneously===<br />
<br />
Since 2.0.1 alpha 59, it is possible to access variables using both var.action 2 type 81 and 82 (and their W/D cousins) indirectly through the new variable 1C.<br />
<br />
This variable stores the result of the current var.action 2 and makes it available to the next var.action 2 in the chain. &nbsp;Therefore, to access, for instance when drawing a house, both house variables (type 81) and town variables (type 82), you would read the house variables in one var. action 2, type 81, and then chain to the next var.action 2, type 82. &nbsp;There, you now have access to the house variable value stored in variable 1C as well as the town variables in the regular variables. Since 2.6 r1246, you may also store values in the 7D array, where they will persist for the life of the action 2 chain, unless overwritten.<br />
<br />
Note that to chain to the next var.action 2, you ''must not'' use nvar=0, because that returns the result value as a callback result. &nbsp;Instead, you need to use nvar=1, and specify the chained var.action 2 in both the <set-id> and <default> positions.<br />
<br />
===Using procedures===<br />
<br />
When the variable in a var.action 2 is 7E, the procedure given by the 60+x parameter is invoked. This means that the byte following the variable number (7E) specifies a variational or random action 2 ID to call, similarly to how a regular var.action 2 branches to other action 2 entries. However, instead of branching, it is a subroutine call, with the value calculated by the called entry being used as variable value.<br />
<br />
The called action 2 must return a callback result. If the chain ends in a regular action 2 instead of returning a callback result, the variable 7E value is undefined. &nbsp;Because callback results are limited to 15 bits, to access the full 32 bit result you can read variable 1C instead (e.g. by anding the 7E result with 0 and then adding var. 1C).<br />
<br />
In TTDPatch 2.5 beta 9 and earlier and in TTDPatch 2.6 prior to r846, var.action 2s that attempt to perform multiple sequential (as opposed to nested) procedure calls will have undefined results.<br />
<br />
The feature of this called action 2 is ignored, and all variables accessed use the same feature as the calling var.action 2. It is however valid to use any type of var.action 2, e.g. types 81 and 82 and the various byte/word/dword sizes may be mixed. It is also valid to use nvar=00 to return the computed value as callback result, instead of specifying ranges, although this way the return value is still limited to 15 bits. When using a random action 2 in the called chain, random triggers are processed in the same way as in &quot;normal&quot; chains.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1184Storages2011-06-14T21:08:12Z<p>Terkhen: Add initial TTDPatch revision for temporary storage</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' 100 (from TTDPatch r1246 to r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 10<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 10 for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1182GRFSpecs:Todo2011-06-14T21:02:45Z<p>Terkhen: Mark storages creation task as done</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Done''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''Page to be created''<br />
| ''Description of the 00-3f, 40-5f, 60-7f, 80-ff [[VarAction2Advanced]] variable ranges. Comment about why most 80-FF variables are not documented. Also mention the relation between VarAction2 and Action6/7/9/D variables.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[SpriteLayouts]]''<br />
| ''Move the general explanation (without syntax) for spritelayouts, sprite&recolour flags and bounding boxes for [[Action0Stations#Sprite_layout_.2809.29 | Stations]] and [[Action2HousesIndustryTiles | Houses/Industries/Airports/Objects]] to a separate page. Also incorporate examples for typical configurations for stations with track and normal buildings (e.g. [http://www.tt-forums.net/viewtopic.php?f=26&t=43236 | this general advice]).<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[RealSprites]]''<br />
| ''Add [http://www.tt-forums.net/viewtopic.php?f=26&t=38122&p=666637#p666637 further explanations and recommendations] about sprite compressions.<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1181Storages2011-06-14T20:59:54Z<p>Terkhen: Add escapes to operator descriptions</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' 100 (before TTDPatch r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 10<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 10 for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1180Storages2011-06-14T20:55:27Z<p>Terkhen: Fix sizes</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' 100 (before TTDPatch r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 0E]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 10<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 10 for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1179Storages2011-06-14T20:48:47Z<p>Terkhen: Fix the format</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Description==<br />
===Temporary storage===<br />
<br />
'''Size:''' FF (before TTDPatch r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 0E]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
===Persistent storage===<br />
<br />
'''Size:''' 0F<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created.<br />
<br />
===Persistent storage accessed by GRFID===<br />
<br />
'''Size:''' 0F for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=Storages&diff=1178Storages2011-06-14T20:47:36Z<p>Terkhen: Initial description of storages</p>
<hr />
<div>==Introduction==<br />
<br />
Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
==Temporary storage==<br />
<br />
'''Size:''' FF (before TTDPatch r1301) or 10F (since TTDPatch r1301 and OpenTTD r9707)<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 0E]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The first FF registers can be read using [[VariationalAction2#Variable|variable 7C]]. The rest of the values are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.<br />
<br />
<br />
Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized.<br />
<br />
==Persistent storage==<br />
<br />
'''Size:''' 0F<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).<br />
<br />
'''Features that support it:''' Industries (0A)<br />
<br />
<br />
Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created.<br />
<br />
==Persistent storage accessed by GRFID==<br />
<br />
'''Size:''' 0F for each GRFID<br />
<br />
'''Data storage:''' [[VarAction2Advanced#operator|Operator 10]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7D]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.<br />
<br />
'''Features that support it:''' Towns<br />
<br />
<br />
Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=TermConsistency&diff=1176TermConsistency2011-06-14T20:29:08Z<p>Terkhen: Add GRFID.</p>
<hr />
<div>This is a list of terms that are used inconsistently on the wiki.<br />
<br />
Once the style fixes of the wiki are done, this list can relatively easily be auto-edited to a common style. Thus do not spend a long time to search for a term on all wiki pages, but just add all spellings found to this list<br />
<br />
<br />
{|<br />
!List of names!!Suggestion for achieving consistency<br />
|+<br />
|Persistent storage, persistent data (All instances of "register" should be checked though).||Always use "Persistent storage" and "Temporary storage". Make clear somewhere that, unless otherwise stated, all references to registers are talking about temporary storage.<br />
|+<br />
|sprite, action, real sprite, action sprite, pseudo sprite||<br />
|+<br />
|Action X, ActionX||The main article is without spaces.<br />
|+<br />
|Town, City || Use town only.<br />
|+<br />
|GRFID, grfid, grfID||Always use GRFID.<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2&diff=1171VariationalAction22011-06-14T19:26:33Z<p>Terkhen: Add a missing link</p>
<hr />
<div>==Introduction==<br />
<br />
To support changes in graphics based on other factors than just the load states, you use a variational action 2. This provides a sophisticated way of deciding what graphics to use.<br />
<br />
A variational action 2 can be used like any other action 2, but it provides an additional step in-between: instead of defining the action 1 sets right away, it instead specifies a list of additional action 2 entry, one of which is used depending on the kind of variation that is defined. These action 2 entries that are referred can in turn be variational or random (to provide chains of decisions), or they can be the final element, that is a regular action 2 which contains definitions of action 1 sets, or a callback result.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> <nvar> (<set-id> <low-range> <high-range>){n} <default><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<Sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes used in this action.<br />
|-<br />
|02||B||Defines action 02<br />
|-<br />
|<feature>||B||For what type of vehicle/station should this definition be used?<br />
|-<br />
|<set-id>||B||The ID of this action 2 (used like a cargo ID)<br />
|-<br />
|<type>||B||Type of variational action 2, see below<br />
|-<br />
|<variable>||B||Which variable we base the decision on<br />
|-<br />
|<varadjust>||V||How to manipulate the value before deciding.<br />
|-<br />
|<nvar>||B||Number of different ranges of the value (not counting the default)<br />
|-<br />
|<set-id>||W||Action 2 set-id to use for the following range.<br />
|-<br />
|<low-range>||B/W/D||Minimum (inclusive) of the range for which to use the above set-id<br />
|-<br />
|<high-range>||B/W/D||Maximum (inclusive) of the range<br />
|-<br />
|<default>||W||Action 2 set-id to use if no range matches<br />
|}<br />
<br />
You repeat the sequence of <set-id> <low-range> <high-range> as often as <nvar> specifies.<br />
<br />
<low-range> and <high-range> have a size of B, W, or D, depending on <type>. See that entry for more information.<br />
<br />
==Description==<br />
<br />
===Sprite-number===<br />
<br />
This is just the number you are at.<br />
<br />
===Length===<br />
<br />
Count the number of bytes in this action.<br />
<br />
===feature===<br />
<br />
This sets the type of feature that you wish to change. Set it to:<br />
<br />
00 for trains<br />
<br />
01 for road vehicles<br />
<br />
02 for ships<br />
<br />
03 for planes<br />
<br />
04 for stations<br />
<br />
05 for canals<br />
<br />
06 for bridges<br />
<br />
07 for houses<br />
<br />
09 for industry tiles<br />
<br />
0A for industries<br />
<br />
0B for cargos<br />
<br />
0E for signals<br />
<br />
0F for objects<br />
<br />
10 for railtypes<br />
<br />
===Set-ID===<br />
<br />
This defines the number of this action 2. &nbsp;The ID can then be used as target in an action 3 or another variational/random action 2.<br />
<br />
===Type===<br />
<br />
The access type specifies both the size of the variable access, and selects between general variables and the object's innate variables, or variables of a specific &quot;related&quot; object.<br />
<br />
Use 81/85/89 to decide upon a general variable, or a variable of the object in question.<br />
<br />
Use 82/86/8A to refer to the &quot;related&quot; object:<br />
<br />
{| |-<br />
!Feature!!Related object<br />
|-<br />
|Vehicles (00-03)||First vehicle of consist<br />
|-<br />
|Stations (04)||Town to which station belongs<br />
|-<br />
|Canals (05)||N/A<br />
|-<br />
|Bridges (06)||Town of bridge<br />
|-<br />
|Houses (07)||Town of building<br />
|-<br />
|Generic (08)||(no action 2 support)<br />
|-<br />
|Industry tiles (09)||Industry containing tile<br />
|-<br />
|Industries (0A)||Town to which industry belongs<br />
|-<br />
|Cargos (0B)||N/A<br />
|-<br />
|Sounds (0C)||(no action 2 support)<br />
|-<br />
|Airports (0D)||Town of airport<br />
|-<br />
|Signals (0E)||N/A<br />
|-<br />
|Objects (0F)||Town of object<br />
|-<br />
|Railtypes (10)||N/A<br />
|}<br />
<br />
This number also tells what size the checked variable is:<br />
<br />
For 81/82, the lowest byte of the value is accessed<br />
<br />
For 85/86, the lowest word is accessed<br />
<br />
For 89/8A, the lowest doubleword is accessed.<br />
<br />
If the accessed variable is smaller than the size given here, the extra bits may contain junk, and should probably be <and-masked> out.<br />
<br />
On this page, the size B/W/D means the field is byte-sized for types 81 and 82, word-sized for types 85 and 86, and doubleword-sized for types 89 and 8A.<br />
<br />
===Variable===<br />
<br />
Which variable to use for this decision. The following variables are always available:<br />
<br />
{| |-<br />
!'''Number'''!![[GRFActionsDetailed|'''Size''']]!!'''Meaning'''<br />
|-<br />
|00||W||current date (counted as days from 1920)<br />
|-<br />
|01||B||current year (count from 1920, max. 2175 even with eternalgame)<br />
|-<br />
|02||B/D||current month (0-11) in bits 0-7; the higher bytes contain unusable junk. Since OTTD r13594 'day of month' (0-30) is stored in bits 8-12, bit 15 is set in leapyears and 'day of year'(0-364 resp. 365) is stored in bits 16-24. All other bits are reserved and should be masked.<br />
|-<br />
|03||B||current climate, 0=temp, 1=arctic, 2=trop, 3=toyland<br />
|-<br />
|09||W||date fraction, incremented by 0x375 every engine tick<br />
|-<br />
|0A||W||animation counter, incremented every tick<br />
|-<br />
|0C||W||current [[Callbacks|callback]] ID (feature-specific), set to 00 when not in a callback<br />
|-<br />
|10||D||extra callback info 1, as described in the callback specs<br />
|-<br />
|11||B||current rail tool type (for station callbacks)<br />
|-<br />
|12||B||Game mode, 0 in title screen, 1 in game and 2 in editor<br />
|-<br />
|18||D||extra callback info 2, as described in the callback specs<br />
|-<br />
|1A||D||always -1 (that is, all bits are set). Useful to create constants (see [[VarAction2Advanced]])<br />
|-<br />
|1B||B||display options; bit 0=town names, 1=station names, 2=signs, 3=animation, 4=transparency, 5=full detail<br />
|-<br />
|1C||D||result from most recent variational action 2<br />
|-<br />
|20||B||snow line height, FFh if snow isn't present at all<br />
|-<br />
|23||D||current date; long format, since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|24||D||current year; long format, year zero based since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|25||D||GrfID of the grf that contains the corresponding Action3. Useful when accessing the &quot;related&quot; object. Currently only supported for vehicles (OpenTTD r15739)<br />
|-<br />
|40+x||D||specially calculated feature-specific variable, see following feature-specific pages<br />
|-<br />
|5F||D||Feature-specific random data: triggers in low byte, bits in other three bytes. Bits of the variable not associated with random or trigger bits are reserved. (2.5 r1927, 2.6 r1928)<br />
|-<br />
|60+x||D||similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter.<br />
|-<br />
|7B||-||A special 60+x variable to be used in Advanced Variational Action 2. It allows to evaluate any other 60+x variable using a non-constant parameter from a register. The parameter of variable 7B specifies another 60+x variable which is evaluated. The parameter for that variable is read from the accumulator ('val1'), i.e. the result from the preceding operations of the same Advanced Variational Action 2. Hence variable 7B may not be the first variable used in the calculation. Variable 7B itself and 7E (procedure call) are not allowed to be used as parameter for variable 7B. Also note that you can pass non-byte parameters to 60+x variable here. While current 60+x variables only use byte parameters, the higher bits of the parameter are considered reserved. So, make sure to mask the higher bits in the preceding calculations. Available since TTDPatch r2359 and OpenTTD r21604.<br />
|-<br />
|7C||D||A special 60+x variable that contains persistent data written by [[VarAction2Advanced#operator|operator 10]], for the features that support it. (See [[VariationalAction2#Type]]). Available since 2.6 r1315. Should not be read if the current feature doesn't support it. If the given slot hasn't been written yet, it contains zero.<br />
|-<br />
|7D||D||A special 60+x variable that contains up to 256 values stored by [[VarAction2Advanced#operator|operator 0E]]. Available since 2.6 r1246. Available in the purchase list. These values are undefined unless written by a var2 earlier in the same chain.<br />
|-<br />
|7E||D||A special 60+x variable indicating a [[VarAction2Advanced#Using_procedures|procedure call]]. Available in the purchase list.<br />
|-<br />
|7F||D||A special 60+x variable that reads GRF parameter whose number is given by the 60+x parameter. Available in the purchase list.<br />
|-<br />
|80+x|| ||feature-specific variable, see following feature-specific pages<br />
|}<br />
<br />
The definition of variable 1B is slightly feature-dependent. For features that can be drawn transparently (stations, bridges, houses, industry tiles and objects) bit 4 is set if the current feature will be drawn normally, and clear if the current feature will be drawn transparently. For these purposes, airports are stations. For all other features, bit 4 is undefined.<br />
<br />
For all features, the 80+x variables are offsets into the corresponding structure in TTD's game data. &nbsp;The 40+x and 60+x variables are special variables that are computed on-the-fly, and aren't actually stored anywhere in memory, unless stated otherwise. Therefore they should be used as little as necessary so as not to slow down the game too much with the calculation of these variables (which can be called thousands of times per second, whenever any vehicle moves).<br />
<br />
When displaying a vehicle (etc.) in the purchase list, the game will show those variations based on external variables (dates etc.) correctly, but variations based on vehicle variables (variables 40+x, 60+x and 80+x) will always show the first (not the default) cargo-ID unless otherwise specified for the given variable. If you do a calculation, the first cargo-ID will be selected if any of the needed variables is inaccessible.<br />
<br />
The lists of 80+x variables on the following pages are not exhaustive; only the useful variables are listed there. For a full list check the definition of corresponding structures in TTD. Marcin Grzegorczyk has a pretty good list of the structure definitions on his [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html|savegame internals page].<br />
<br />
===varadjust===<br />
<br />
Adjust variable to a more useful range. It has the following format:<br />
<br />
<pre> <shift-num> <and-mask> <nowiki>[<add-val> <divide-val>/<modulo-val>]</nowiki></pre><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|shift-num||B||value to right-shift the variable, and some special bits. See below.<br />
|-<br />
|and-mask||B/W/D||value with which to AND the variable after shifting. Return this value if neither bit 6 nor bit 7 of shift-num are set.<br />
|-<br />
|add-val||B/W/D||value to add to the variable after ANDing. Only present if bits 6 or 7 are set in shift-num.<br />
|-<br />
|divide-val||B/W/D||return the sum divided by this value. Only present if bit 6 is set in shift-num.<br />
|-<br />
|modulo-val||B/W/D||return the sum modulo (remainder of division by) this value. Only present if bit 7 is set in shift-num.<br />
|}<br />
<br />
<shift-num> is a partial bit-mask; its bits have the following meanings:<br />
<br />
{| |-<br />
!Bit(s)!!value!!meaning<br />
|-<br />
|0..4||0..1F||number of bits to right shift <variable><br />
|-<br />
|5||20||This is an [[VarAction2Advanced|advanced var.action 2]]<br />
|-<br />
|6||40||This is a shift-and-add-divide adjustment.<br />
|-<br />
|7||80||This is a shift-and-add-modulo adjustment.<br />
|}<br />
<br />
Bits 6 and 7 may not both be set. If neither are set, this varadjust is a shift-and adjustment.<br />
<br />
Note that for the add and divide operations, both the variable and the divisor are taken to be signed numbers. This means that if the high bit is set, the number is taken to be negative, so you may need to mask out the most significant bit to do an unsigned division.<br />
<br />
===nvar===<br />
<br />
Here you set how many different ranges to check for. If the value of the variable, after the above manipulations, is not within one of these ranges, the default will be used. &nbsp;When displayed in the purchase window, the game will always show the first range if the variable is of the 40+x or 80+x type (because the variable is undefined since the vehicle doesn't exist yet).<br />
<br />
Since 2.0.1 alpha 57, nvar=0 is a special case. Instead of using ranges, nvar=0 means that the result of an [[VarAction2Advanced|advanced]] calculation (or, if no calculation is performed, the adjusted variable value itself) is returned as callback result, with bit 15 set. &nbsp;This is useful for those callbacks where many different return values are possible and it is easier to calculate them than list them in ranges. &nbsp;The default value must still be specified, and will be used in case the variable(s) used are not available.<br />
<br />
===sets and ranges===<br />
<br />
For each of the ranges to check, you give the set-id as a '''WORD''' value (i.e. with a 00 following, e.g. set-id 5 becomes 05 00, or - in case of a callback result - by setting the high bit, e.g. 05 80), followed by the low and high limits of this range. &nbsp;The first range that matches will be used.<br />
<br />
The various \b, \w, and \d escape sequences can be useful for <min-range> and <max-range>. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information.<br />
<br />
===default===<br />
<br />
The set-id to use if none of the ranges matches.<br />
<br />
=Example=</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1170GRFSpecs:Todo2011-06-14T19:21:07Z<p>Terkhen: Add item to ToDo list.</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''Page to be created''<br />
| ''Description of the 00-3f, 40-5f, 60-7f, 80-ff [[VarAction2Advanced]] variable ranges. Comment about why most 80-FF variables are not documented.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1168GRFSpecs:Todo2011-06-14T19:10:57Z<p>Terkhen: Add VarAction2Cities task.</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''There are variables only mentioned in the table and not in description.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VarAction2Advanced&diff=1167VarAction2Advanced2011-06-14T18:28:59Z<p>Terkhen: Fix table format</p>
<hr />
<div>==Introduction==<br />
<br />
A regular action 2 can access one variable and perform limited modifications on it (shift, and, add, divide/modulo) instead of a simple variable access. Using an advanced action 2, it is possible to do a nearly unlimited number of many different operations on several variables.<br />
<br />
In addition, using procedure calls (with variable 7E), it is possible to reuse variational action 2 blocks in several places on the NFO code.<br />
<br />
==Format==<br />
<br />
An advanced variational action 2 looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> '''[<operator> <variable> <varadjust>]'''... <nvar> (<set-id> <low-range> <high-range>){n} <default><br />
<br />
The new elements are the <operator> (a byte), followed by another <variable> and <varadjust> pair. &nbsp;This sequence may be repeated as often as necessary, by setting the appropriate bit in the previous <varadjust> (see below).<br />
<br />
===varadjust===<br />
<br />
<varadjust> itself has the same format as a regular var. action 2, however to perform a calculation, bit 5 in <shift-num> has to be set:<br />
<br />
{|<br />
!Bit(s)!!Value!!Meaning<br />
|-<br />
|0..4||0..1F||number of bits to right shift <variable><br />
|-<br />
|5||20||'''an <operator> <variable> <varadjust> triple follows this <varadjust>'''<br />
|-<br />
|6||40||This is a shift-and-add-divide adjustment.<br />
|-<br />
|7||80||This is a shift-and-add-modulo adjustment.<br />
|}<br />
<br />
Bit 5 needs to be set for each <shift-num>, except the last one that isn't going to be followed by another calculation (i.e., <operator> <variable> <varadjust> set). Bit 5 clear terminates the calculation and uses the resulting value for checking the ranges determining the set-id to use (or, if nvar=0, as a callback result).<br />
<br />
===operator===<br />
<br />
This field, and the following variable/varadjust pair, exist only if the previous shift-num had bit 5 set. This field has escape sequences for each of its valid values, as shown in the table below. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information on escape sequences in general. Can have the following values:<br />
<br />
{|<br />
!Value!!Escape!!Effect!!Notes<br />
|-<br />
|00||\2+||result = val1 + val2||<br />
|-<br />
|01||\2-||result = val1 - val2||<br />
|-<br />
|02||\2<||result = min(val1, val2)||val1 and val2 are both considered signed<br />
|-<br />
|03||\2>||result = max(val1, val2)||val1 and val2 are both considered signed<br />
|-<br />
|04,05||\2u<, \2u>||result = max(val1, val2)||Same as 02/03, but operands are considered unsigned<br />
|-<br />
|06||\2/||result = val1 / val2||val1 and val2 are both considered signed<br />
|-<br />
|07||\2%||result = val1 mod val2||val1 and val2 are both considered signed<br />
|-<br />
|08,09||\2u/, \2u%||result = val1 mod val2||Same as 06/07, but operands are considered unsigned<br />
|-<br />
|0A||\2*||result = val1 * val2||result will be truncated to B/W/D (that makes it the same for signed/unsigned operands)<br />
|-<br />
|0B||\2&||result = val1 & val2||bitwise AND<br />
|-<br />
|0C||\2<nowiki>|</nowiki>||result = val1 <nowiki>|</nowiki> val2||bitwise OR<br />
|-<br />
|0D||\2<nowiki>^</nowiki>||result = val1 <nowiki>^</nowiki> val2||bitwise XOR<br />
|-<br />
|0E||\2s or \2sto (a)||var7D[val2] = val1, result = val1||Store result, available since 2.6 r1246. val2 must not exceed FF (before r1301) or 10F (starting from r1301) (*)<br />
|-<br />
|0F||\2r or \2rst (a)||result = val2||Available since 2.6 r1246<br />
|-<br />
|10||\2psto (c)||var7C[val2] = val1, result = val1||Store result into persistent storage, available since 2.6 r1315 (**)<br />
|-<br />
|11||\2ror or \2rot (b)||result = val1 rotate right val2||Always a 32-bit rotation. Available since 2.6 r1651<br />
|-<br />
|12||\2cmp (c)||see notes||Result is 0 if val1<val2, 1 if val1=val2 and 2 if val1>val2. Both values are considered signed. Available since 2.6 r1698 (***)<br />
|-<br />
|13||\2ucmp (c)||see notes||The same as 12, but operands are considered unsigned. Available since 2.6 r1698 (***)<br />
|-<br />
|14||\2<< (c)||result = val1 << val2||shift left; val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|-<br />
|15||\2u>> (c)||result = val1 >> val2||shift right (unsigned); val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|-<br />
|16||\2>> (c)||result = val1 >> val2||shift right (signed); val2 should be in the range 0 to 31. Available since OpenTTD r20332 and TTDPatch r2335.<br />
|}<br />
<br />
where val1 is the value resulting from the current variable/varadjust pair (or the result of the previous calculations if this isn't the first pair) and val2 is the value resulting from the following variable/varadjust pair. By setting bit 5 of shift-num repeatedly, you can combine several variables together before making your decision.<br />
<br />
(a) Supported since grfcodec and nforenum r1265 (1.0.0 and 3.4.4, respectively.)<br />
<br />
(b) Supported since grfcodec and nforenum r1655 (1.0.0 and 3.4.6, respectively.)<br />
<br />
(c) Supported since grfcodec 1.0.0 and nforenum 4.0.0.<br />
<br />
<nowiki>*</nowiki> Registers above FFh are write-only because you can't give a value bigger than FFh to var 7D. These registers are special; they allow passing extra data to some 4x and 6x variables, as well as returning extra data from callbacks.<br />
<br />
<nowiki>**</nowiki> Currently only feature A (industries) is supported, you have 16 4-byte slots per industry. This storage can be reached from industry tiles as well by using var. action 2 type 82/86/8A. This operation shouldn't be used when the industry structure isn't available.<br />
<br />
<nowiki>***</nowiki> Operations 12 and 13 should be preferred over operation 01 (subtraction) when only the relation of the two values is needed and the difference itself is irrelevant. This is because operation 01 can overflow and give the wrong sign if the difference is too big, but comparisons work correctly for all values.<br />
<br />
Registers (temporary and persistent alike) always have the size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.<br />
<br />
Note that a bitwise NOT can be done by XORing with variable 1A. Similarly, you can specify literal values (i.e. plain numbers instead of variables), by using variable 1A and an and-mask of the value you want. For example, to specify a literal 26, use variable=1A, shift-num=00 (or the higher bits set if you need further calculations), and and-mask=26. This works with B, W or D sized literals if you use the right and-mask size for the given type of action 2. The appropriate \b, \w, or \d escape sequence can be useful for specifying literals. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information.<br />
<br />
Operator 0F is only useful when using variable 7B, or immediately after operators 0E or 10, to store the result of a calculation, and then discard that result and start fresh.<br />
<br />
===Using types 81/82 (etc) simultaneously===<br />
<br />
Since 2.0.1 alpha 59, it is possible to access variables using both var.action 2 type 81 and 82 (and their W/D cousins) indirectly through the new variable 1C.<br />
<br />
This variable stores the result of the current var.action 2 and makes it available to the next var.action 2 in the chain. &nbsp;Therefore, to access, for instance when drawing a house, both house variables (type 81) and town variables (type 82), you would read the house variables in one var. action 2, type 81, and then chain to the next var.action 2, type 82. &nbsp;There, you now have access to the house variable value stored in variable 1C as well as the town variables in the regular variables. Since 2.6 r1246, you may also store values in the 7D array, where they will persist for the life of the action 2 chain, unless overwritten.<br />
<br />
Note that to chain to the next var.action 2, you ''must not'' use nvar=0, because that returns the result value as a callback result. &nbsp;Instead, you need to use nvar=1, and specify the chained var.action 2 in both the <set-id> and <default> positions.<br />
<br />
===Using procedures===<br />
<br />
When the variable in a var.action 2 is 7E, the procedure given by the 60+x parameter is invoked. This means that the byte following the variable number (7E) specifies a variational or random action 2 ID to call, similarly to how a regular var.action 2 branches to other action 2 entries. However, instead of branching, it is a subroutine call, with the value calculated by the called entry being used as variable value.<br />
<br />
The called action 2 must return a callback result. If the chain ends in a regular action 2 instead of returning a callback result, the variable 7E value is undefined. &nbsp;Because callback results are limited to 15 bits, to access the full 32 bit result you can read variable 1C instead (e.g. by anding the 7E result with 0 and then adding var. 1C).<br />
<br />
In TTDPatch 2.5 beta 9 and earlier and in TTDPatch 2.6 prior to r846, var.action 2s that attempt to perform multiple sequential (as opposed to nested) procedure calls will have undefined results.<br />
<br />
The feature of this called action 2 is ignored, and all variables accessed use the same feature as the calling var.action 2. It is however valid to use any type of var.action 2, e.g. types 81 and 82 and the various byte/word/dword sizes may be mixed. It is also valid to use nvar=00 to return the computed value as callback result, instead of specifying ranges, although this way the return value is still limited to 15 bits. When using a random action 2 in the called chain, random triggers are processed in the same way as in &quot;normal&quot; chains.</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1166GRFSpecs:Todo2011-06-14T18:26:40Z<p>Terkhen: Add VarAction2NewSignals to ToDo.</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2NewSignals]]''<br />
| ''This page does not follow the same format than the other VarAction2 pages, and it seems to include information about callbacks. Variables are not named.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Signals&diff=1165VariationalAction2/Signals2011-06-14T18:25:21Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
This is available from 2.6 alpha 0 r1247 onwards.<br />
<br />
This type of variational action 2 requires the use of advanced calculations: [[VarAction2Advanced]]<br />
<br />
==Variables==<br />
<br />
==Description==<br />
<br />
===Variable 10===<br />
<br />
{| |-<br />
!Bit!!Meaning<br />
|-<br />
|0||Green<br />
|-<br />
|1-3||Front facing: 0=SW, 1=NE, 2=NW, 3=SE, 4=E, 5=W, 6=S, 7=N<br />
|-<br />
|4-5||Presignals: 0=norm, 1=entrance, 2=exit, 3=combo<br />
|-<br />
|6||Semaphore<br />
|-<br />
|7||PBS<br />
|-<br />
|8||Restricted<br />
|-<br />
|9||Programmed<br />
|-<br />
|10||Through<br />
|-<br />
|11||Inverted<br />
|}<br />
<br />
Note: that these are the same bits as would be used to order action5 block type 4.<br />
<br />
===Variable 18===<br />
<br />
{| |-<br />
!Bit!!Meaning<br />
|-<br />
|0-7||L5 of signal tile<br />
<br />
&nbsp; 0: track in X<br />
<br />
&nbsp; 1: track in Y<br />
<br />
&nbsp; 2: track in N<br />
<br />
&nbsp; 3: track in S<br />
<br />
&nbsp; 4: track in W<br />
<br />
&nbsp; 5: track in E<br />
|-<br />
|8-15||Low half of L3 of tile, bits 4-7 bitmask of which signals present as shown below, bits 0-3: track type<br />
|-<br />
|16-23||Which signal is currently being drawn, bit index of L3 signal mask:<br />
<br />
&nbsp; * For track in the X direction:<br />
<br />
&nbsp; &nbsp; &nbsp; 6: &nbsp;signal in the SW direction<br />
<br />
&nbsp; &nbsp; &nbsp; 7: &nbsp;signal in the NE direction<br />
<br />
&nbsp; * For track in the Y direction:<br />
<br />
&nbsp; &nbsp; &nbsp; 6: &nbsp;signal in the NW direction<br />
<br />
&nbsp; &nbsp; &nbsp; 7: &nbsp;signal in the SE direction<br />
<br />
&nbsp; * For tracks in the W-E direction:<br />
<br />
&nbsp; &nbsp; &nbsp; 4: &nbsp;signal in the W direction on the track in the S corner<br />
<br />
&nbsp; &nbsp; &nbsp; 5: &nbsp;signal in the E direction on the track in the S corner<br />
<br />
&nbsp; &nbsp; &nbsp; 6: &nbsp;signal in the W direction on the track in the N corner<br />
<br />
&nbsp; &nbsp; &nbsp; 7: &nbsp;signal in the E direction on the track in the N corner<br />
<br />
&nbsp; * For tracks in the N-S direction:<br />
<br />
&nbsp; &nbsp; &nbsp; 4: &nbsp;signal in the S direction on the track in the E corner<br />
<br />
&nbsp; &nbsp; &nbsp; 5: &nbsp;signal in the N direction on the track in the E corner<br />
<br />
&nbsp; &nbsp; &nbsp; 6: &nbsp;signal in the S direction on the track in the W corner<br />
<br />
&nbsp; &nbsp; &nbsp; 7: &nbsp;signal in the N direction on the track in the W corner<br />
|-<br />
|24-27||Land/Fence type<br />
|-<br />
|28-31||Terrain type: 0=normal, 1=desert, 2=rainforest, 4=snow<br />
|}<br />
<br />
===Parameterised var 60===<br />
<br />
Parameter is two signed nybble offsets to add to coordinates of tile.<br />
<br />
The low nybble is added to the X coordinate (top-right to bottom-left).<br />
<br />
The high nybble is added to the Y coordinate (top-left to bottom-right).<br />
<br />
The information is retrieved from the tile after the coordinates have been adjusted, starting from the tile which is currently being drawn.<br />
<br />
{| |-<br />
!Bit!!Meaning<br />
|-<br />
|0-7||L5<br />
|-<br />
|8-15||L3 low<br />
|-<br />
|16-20||Altitude of tile<<3<br />
|-<br />
|21-25||Slope map of tile<br />
|-<br />
|26||Tile has same owner<br />
|-<br />
|27||Semaphores<br />
|-<br />
|28||Tile has same track bits<br />
|-<br />
|29||Tile has same slope and altitude<br />
|-<br />
|30||Tile has signals<br />
|-<br />
|31||Tile is a track tile<br />
|}<br />
<br />
Return value cached in varaction2var 10<br />
<br />
==Output==<br />
<br />
===Callback return value===<br />
<br />
{| |-<br />
!Bit!!Meaning<br />
|-<br />
|0||Use new sprites<br />
|-<br />
|1-4||Num sprites, varaction2vars 0x20-2F<br />
|-<br />
|5||Use recolour sprite specified in varaction2var 0x30<br />
|-<br />
|6||Use ordinary signal sprite number: varaction2var 0x20, (this overrides all other bits)<br />
|}<br />
<br />
===Varaction2var 20-2F value===<br />
<br />
{| |-<br />
!Bit!!Meaning<br />
|-<br />
|0-12||Sprite offset into action5 block 0E.<br />
|-<br />
|13||Add sprite yrel to Y correction for next sprite (sub from 3D Z), (yrel must fit in a signed byte)<br />
|-<br />
|14-18||Sprite Y (-3D Z) correction for next sprite, (signed), (added to total)~010~Overall change to 3D Z, (-Y correction), must be positive, else risk of TTD crashing<br />
|-<br />
|19-23||Sprite Y (-3D Z) correction for this sprite only, (signed), (not added to total)<br />
|-<br />
|24-27||Sprite X correction for next sprite << 1, (signed), (added to total)<br />
|-<br />
|28-31||Sprite X correction for this sprite only << 1, (signed), (not added to total)<br />
|}<br />
<br />
---<br />
<br />
A generic action 3 feature 0E should be used to reference the action 2.<br />
<br />
Callback 0x146 will call this action 3 when a signal is drawn.<br />
<br />
Should the GRF not support the type of signal indicated in variable 10, an invalid callback result should be returned. Returning 0 will prevent further new signal GRF files from being queried and will cause the default signal graphics to be used. Returning 0 should only be done to explicitly prevent lower priority new signals GRFs from possibly drawing the signal.<br />
<br />
The result to the callback should be returned as a calculation result.<br />
<br />
Bits 1-4 of the callback result indicate how many varaction2vars starting from 0x20 will be used to specify sprites, to be drawn. Operator 0E should be used to store the appropriate values in vars 0x20-2F and 30 as appropriate.<br />
<br />
Recolour sprites, specifed in varaction2var 0x30 and bit 5 of the callback result are applied for all of the sprites to be drawn.<br />
<br />
===Example===<br />
<br />
[http://tt-forums.net/viewtopic.php?p=529007#529007|Example GRF with NFO, PCX components.]</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2&diff=1164VariationalAction22011-06-14T18:16:20Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
To support changes in graphics based on other factors than just the load states, you use a variational action 2. This provides a sophisticated way of deciding what graphics to use.<br />
<br />
A variational action 2 can be used like any other action 2, but it provides an additional step in-between: instead of defining the action 1 sets right away, it instead specifies a list of additional action 2 entry, one of which is used depending on the kind of variation that is defined. These action 2 entries that are referred can in turn be variational or random (to provide chains of decisions), or they can be the final element, that is a regular action 2 which contains definitions of action 1 sets, or a callback result.<br />
<br />
==Format==<br />
<br />
The data looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> <nvar> (<set-id> <low-range> <high-range>){n} <default><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|<Sprite-number>||dec||A sequential sprite number<br />
|-<br />
|<length>||dec||The total number of bytes used in this action.<br />
|-<br />
|02||B||Defines action 02<br />
|-<br />
|<feature>||B||For what type of vehicle/station should this definition be used?<br />
|-<br />
|<set-id>||B||The ID of this action 2 (used like a cargo ID)<br />
|-<br />
|<type>||B||Type of variational action 2, see below<br />
|-<br />
|<variable>||B||Which variable we base the decision on<br />
|-<br />
|<varadjust>||V||How to manipulate the value before deciding.<br />
|-<br />
|<nvar>||B||Number of different ranges of the value (not counting the default)<br />
|-<br />
|<set-id>||W||Action 2 set-id to use for the following range.<br />
|-<br />
|<low-range>||B/W/D||Minimum (inclusive) of the range for which to use the above set-id<br />
|-<br />
|<high-range>||B/W/D||Maximum (inclusive) of the range<br />
|-<br />
|<default>||W||Action 2 set-id to use if no range matches<br />
|}<br />
<br />
You repeat the sequence of <set-id> <low-range> <high-range> as often as <nvar> specifies.<br />
<br />
<low-range> and <high-range> have a size of B, W, or D, depending on <type>. See that entry for more information.<br />
<br />
==Description==<br />
<br />
===Sprite-number===<br />
<br />
This is just the number you are at.<br />
<br />
===Length===<br />
<br />
Count the number of bytes in this action.<br />
<br />
===feature===<br />
<br />
This sets the type of feature that you wish to change. Set it to:<br />
<br />
00 for trains<br />
<br />
01 for road vehicles<br />
<br />
02 for ships<br />
<br />
03 for planes<br />
<br />
04 for stations<br />
<br />
05 for canals<br />
<br />
06 for bridges<br />
<br />
07 for houses<br />
<br />
09 for industry tiles<br />
<br />
0A for industries<br />
<br />
0B for cargos<br />
<br />
0E for signals<br />
<br />
0F for objects<br />
<br />
10 for railtypes<br />
<br />
===Set-ID===<br />
<br />
This defines the number of this action 2. &nbsp;The ID can then be used as target in an action 3 or another variational/random action 2.<br />
<br />
===type===<br />
<br />
The access type specifies both the size of the variable access, and selects between general variables and the object's innate variables, or variables of a specific &quot;related&quot; object.<br />
<br />
Use 81/85/89 to decide upon a general variable, or a variable of the object in question.<br />
<br />
Use 82/86/8A to refer to the &quot;related&quot; object:<br />
<br />
{| |-<br />
!Feature!!Related object<br />
|-<br />
|Vehicles (00-03)||First vehicle of consist<br />
|-<br />
|Stations (04)||Town to which station belongs<br />
|-<br />
|Canals (05)||N/A<br />
|-<br />
|Bridges (06)||Town of bridge<br />
|-<br />
|Houses (07)||Town of building<br />
|-<br />
|Generic (08)||(no action 2 support)<br />
|-<br />
|Industry tiles (09)||Industry containing tile<br />
|-<br />
|Industries (0A)||Town to which industry belongs<br />
|-<br />
|Cargos (0B)||N/A<br />
|-<br />
|Sounds (0C)||(no action 2 support)<br />
|-<br />
|Airports (0D)||Town of airport<br />
|-<br />
|Signals (0E)||N/A<br />
|-<br />
|Objects (0F)||Town of object<br />
|-<br />
|Railtypes (10)||N/A<br />
|}<br />
<br />
This number also tells what size the checked variable is:<br />
<br />
For 81/82, the lowest byte of the value is accessed<br />
<br />
For 85/86, the lowest word is accessed<br />
<br />
For 89/8A, the lowest doubleword is accessed.<br />
<br />
If the accessed variable is smaller than the size given here, the extra bits may contain junk, and should probably be <and-masked> out.<br />
<br />
On this page, the size B/W/D means the field is byte-sized for types 81 and 82, word-sized for types 85 and 86, and doubleword-sized for types 89 and 8A.<br />
<br />
===Variable===<br />
<br />
Which variable to use for this decision. The following variables are always available:<br />
<br />
{| |-<br />
!'''Number'''!![[GRFActionsDetailed|'''Size''']]!!'''Meaning'''<br />
|-<br />
|00||W||current date (counted as days from 1920)<br />
|-<br />
|01||B||current year (count from 1920, max. 2175 even with eternalgame)<br />
|-<br />
|02||B/D||current month (0-11) in bits 0-7; the higher bytes contain unusable junk. Since OTTD r13594 'day of month' (0-30) is stored in bits 8-12, bit 15 is set in leapyears and 'day of year'(0-364 resp. 365) is stored in bits 16-24. All other bits are reserved and should be masked.<br />
|-<br />
|03||B||current climate, 0=temp, 1=arctic, 2=trop, 3=toyland<br />
|-<br />
|09||W||date fraction, incremented by 0x375 every engine tick<br />
|-<br />
|0A||W||animation counter, incremented every tick<br />
|-<br />
|0C||W||current [[Callbacks|callback]] ID (feature-specific), set to 00 when not in a callback<br />
|-<br />
|10||D||extra callback info 1, as described in the callback specs<br />
|-<br />
|11||B||current rail tool type (for station callbacks)<br />
|-<br />
|12||B||Game mode, 0 in title screen, 1 in game and 2 in editor<br />
|-<br />
|18||D||extra callback info 2, as described in the callback specs<br />
|-<br />
|1A||D||always -1 (that is, all bits are set). Useful to create constants (see [[VarAction2Advanced]])<br />
|-<br />
|1B||B||display options; bit 0=town names, 1=station names, 2=signs, 3=animation, 4=transparency, 5=full detail<br />
|-<br />
|1C||D||result from most recent variational action 2<br />
|-<br />
|20||B||snow line height, FFh if snow isn't present at all<br />
|-<br />
|23||D||current date; long format, since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|24||D||current year; long format, year zero based since OpenTTD r13376, 2.6 r2049<br />
|-<br />
|25||D||GrfID of the grf that contains the corresponding Action3. Useful when accessing the &quot;related&quot; object. Currently only supported for vehicles (OpenTTD r15739)<br />
|-<br />
|40+x||D||specially calculated feature-specific variable, see following feature-specific pages<br />
|-<br />
|5F||D||Feature-specific random data: triggers in low byte, bits in other three bytes. Bits of the variable not associated with random or trigger bits are reserved. (2.5 r1927, 2.6 r1928)<br />
|-<br />
|60+x||D||similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter.<br />
|-<br />
|7B||-||A special 60+x variable to be used in Advanced Variational Action 2. It allows to evaluate any other 60+x variable using a non-constant parameter from a register. The parameter of variable 7B specifies another 60+x variable which is evaluated. The parameter for that variable is read from the accumulator ('val1'), i.e. the result from the preceding operations of the same Advanced Variational Action 2. Hence variable 7B may not be the first variable used in the calculation. Variable 7B itself and 7E (procedure call) are not allowed to be used as parameter for variable 7B. Also note that you can pass non-byte parameters to 60+x variable here. While current 60+x variables only use byte parameters, the higher bits of the parameter are considered reserved. So, make sure to mask the higher bits in the preceding calculations. Available since TTDPatch r2359 and OpenTTD r21604.<br />
|-<br />
|7C||D||A special 60+x variable that contains persistent data written by [[VarAction2Advanced#operator|operator 10]], for the features that support it. (The list of supported features can be found on that page.) Available since 2.6 r1315. Should not be read if the current feature doesn't support it. If the given slot hasn't been written yet, it contains zero.<br />
|-<br />
|7D||D||A special 60+x variable that contains up to 256 values stored by [[VarAction2Advanced#operator|operator 0E]]. Available since 2.6 r1246. Available in the purchase list. These values are undefined unless written by a var2 earlier in the same chain.<br />
|-<br />
|7E||D||A special 60+x variable indicating a [[VarAction2Advanced#Using_procedures|procedure call]]. Available in the purchase list.<br />
|-<br />
|7F||D||A special 60+x variable that reads GRF parameter whose number is given by the 60+x parameter. Available in the purchase list.<br />
|-<br />
|80+x|| ||feature-specific variable, see following feature-specific pages<br />
|}<br />
<br />
The definition of variable 1B is slightly feature-dependent. For features that can be drawn transparently (stations, bridges, houses, industry tiles and objects) bit 4 is set if the current feature will be drawn normally, and clear if the current feature will be drawn transparently. For these purposes, airports are stations. For all other features, bit 4 is undefined.<br />
<br />
For all features, the 80+x variables are offsets into the corresponding structure in TTD's game data. &nbsp;The 40+x and 60+x variables are special variables that are computed on-the-fly, and aren't actually stored anywhere in memory, unless stated otherwise. Therefore they should be used as little as necessary so as not to slow down the game too much with the calculation of these variables (which can be called thousands of times per second, whenever any vehicle moves).<br />
<br />
When displaying a vehicle (etc.) in the purchase list, the game will show those variations based on external variables (dates etc.) correctly, but variations based on vehicle variables (variables 40+x, 60+x and 80+x) will always show the first (not the default) cargo-ID unless otherwise specified for the given variable. If you do a calculation, the first cargo-ID will be selected if any of the needed variables is inaccessible.<br />
<br />
The lists of 80+x variables on the following pages are not exhaustive; only the useful variables are listed there. For a full list check the definition of corresponding structures in TTD. Marcin Grzegorczyk has a pretty good list of the structure definitions on his [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html|savegame internals page].<br />
<br />
===varadjust===<br />
<br />
Adjust variable to a more useful range. It has the following format:<br />
<br />
<pre> <shift-num> <and-mask> <nowiki>[<add-val> <divide-val>/<modulo-val>]</nowiki></pre><br />
<br />
{| |-<br />
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''<br />
|-<br />
|shift-num||B||value to right-shift the variable, and some special bits. See below.<br />
|-<br />
|and-mask||B/W/D||value with which to AND the variable after shifting. Return this value if neither bit 6 nor bit 7 of shift-num are set.<br />
|-<br />
|add-val||B/W/D||value to add to the variable after ANDing. Only present if bits 6 or 7 are set in shift-num.<br />
|-<br />
|divide-val||B/W/D||return the sum divided by this value. Only present if bit 6 is set in shift-num.<br />
|-<br />
|modulo-val||B/W/D||return the sum modulo (remainder of division by) this value. Only present if bit 7 is set in shift-num.<br />
|}<br />
<br />
<shift-num> is a partial bit-mask; its bits have the following meanings:<br />
<br />
{| |-<br />
!Bit(s)!!value!!meaning<br />
|-<br />
|0..4||0..1F||number of bits to right shift <variable><br />
|-<br />
|5||20||This is an [[VarAction2Advanced|advanced var.action 2]]<br />
|-<br />
|6||40||This is a shift-and-add-divide adjustment.<br />
|-<br />
|7||80||This is a shift-and-add-modulo adjustment.<br />
|}<br />
<br />
Bits 6 and 7 may not both be set. If neither are set, this varadjust is a shift-and adjustment.<br />
<br />
Note that for the add and divide operations, both the variable and the divisor are taken to be signed numbers. This means that if the high bit is set, the number is taken to be negative, so you may need to mask out the most significant bit to do an unsigned division.<br />
<br />
===nvar===<br />
<br />
Here you set how many different ranges to check for. If the value of the variable, after the above manipulations, is not within one of these ranges, the default will be used. &nbsp;When displayed in the purchase window, the game will always show the first range if the variable is of the 40+x or 80+x type (because the variable is undefined since the vehicle doesn't exist yet).<br />
<br />
Since 2.0.1 alpha 57, nvar=0 is a special case. Instead of using ranges, nvar=0 means that the result of an [[VarAction2Advanced|advanced]] calculation (or, if no calculation is performed, the adjusted variable value itself) is returned as callback result, with bit 15 set. &nbsp;This is useful for those callbacks where many different return values are possible and it is easier to calculate them than list them in ranges. &nbsp;The default value must still be specified, and will be used in case the variable(s) used are not available.<br />
<br />
===sets and ranges===<br />
<br />
For each of the ranges to check, you give the set-id as a '''WORD''' value (i.e. with a 00 following, e.g. set-id 5 becomes 05 00, or - in case of a callback result - by setting the high bit, e.g. 05 80), followed by the low and high limits of this range. &nbsp;The first range that matches will be used.<br />
<br />
The various \b, \w, and \d escape sequences can be useful for <min-range> and <max-range>. See [[GRFActionsDetailed#Byte_order|the discussion of escape sequences]] for further information.<br />
<br />
===default===<br />
<br />
The set-id to use if none of the ranges matches.<br />
<br />
=Example=</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1161GRFSpecs:Todo2011-06-14T15:10:04Z<p>Terkhen: Clean orphan line</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=GRFSpecs:Todo&diff=1160GRFSpecs:Todo2011-06-14T14:44:06Z<p>Terkhen: Note about airport tiles.</p>
<hr />
<div>=To-Do List=<br />
<br />
Currently the main task is to fix all conversion errors from the change of wikis. Have a look at the "[http://newgrf-specs.tt-wiki.net/index.php?title=Special:AncientPages&limit=250&offset=0| oldest pages]" list. Anything dating to 12 June has not been reviewed.<br />
<br />
Many terms are used inconsistently. Although it is not a big priority to fix them right now, add an entry or edit existing ones at [[TermConsistency]] if you spot any inconsistencies regarding term names.<br />
<br />
This page contains a list of 'jobs' that remain to be completed, please follow the example listing when adding/editing information in the table.<br />
<br />
*'''Item''' - internal link to a page.<br />
*'''Task''' - What needs to be done.<br />
*'''Status''' - Available (no one working on it), In Progress (someone working on it, include name in parentheses ()), Complete (item has been finished)<br />
*'''Date Added''' - DD/MM/YYYY format<br />
*'''Last Updated''' - DD/MM/YYYY format<br />
<br />
==Main List==<br />
<br />
{|<br />
|-<br />
! Item<br />
! Task<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''Example Item''<br />
| ''Example Task''<br />
| ''Available''<br />
| ''13/06/2011''<br />
| ''13/06/2011''<br />
|-<br />
| ''[[VarAction2Cities]]''<br />
| ''Rename to VarAction2Towns''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[TownZones]]''<br />
| ''Explanation of town zones. Links to all appropiate places.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Storages]]''<br />
| ''Explanation of persistent and temporary storages. See [[TermConsistency]].''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2IndustryTiles]]''<br />
| ''Right now, VarAction2AirportTiles just links to [[VarAction2IndustryTiles]]. This is okay (we should not duplicate information), but that page has almost no explanation about being also for airport tiles.''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}<br />
<br />
VarAction2AirportTiles<br />
<br />
==Examples to be Written==<br />
<br />
{|<br />
|-<br />
! Examples Needed For<br />
! Status<br />
! Date Added<br />
! Last Updated<br />
|-<br />
| ''[[Action0]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Airports]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Canals]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Cargos]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Planes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Railtypes]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0RoadVehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action0Ships]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action2Vehicles]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[Action4]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[ActionD]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|-<br />
| ''[[VarAction2Stations]]''<br />
| ''Available''<br />
| ''14/06/2011''<br />
| ''14/06/2011''<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Railtypes&diff=1159VariationalAction2/Railtypes2011-06-14T14:42:19Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
==Variables==<br />
<br />
{| |-<br />
!Variable !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|40||||B||Terrain type: 0 normal, 1 desert, 2 rainforest, 4 on or above snowline.<br />
|-<br />
|41||||B||Enhanced tunnels; entrance has track above. Always 0 in OpenTTD.<br />
|-<br />
|42||||B||Level crossing status: 0 if open (or not a crossing), 1 if closed.<br />
|-<br />
|43||||D||Depot construction date (long format, 0 based); other: current date<br />
|}<br />
<br />
Available in OpenTTD r19056<br />
<br />
==Description==<br />
===Terrain type (40)===<br />
<br />
'''Format:''' byte<br />
<br />
{| |-<br />
!value!!Meaning<br />
|-<br />
|0||normal tile<br />
|-<br />
|1||desert tile<br />
|-<br />
|2||rain forest tile<br />
|-<br />
|4||tile on or above snow line<br />
|}<br />
<br />
===Enhanced tunnels (41)===<br />
<br />
'''Format:''' byte<br />
<br />
This variable will always return 0 and is reserved for future use with enhanced tunnels.<br />
<br />
===Level crossing status (42)===<br />
<br />
'''Format:''' byte<br />
<br />
This variable returns 1, if a crossing is closed. If the crossing is open or the tile is no level crossing, the return value is 0.<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Objects&diff=1158VariationalAction2/Objects2011-06-14T14:39:26Z<p>Terkhen: Title with wrong format</p>
<hr />
<div>==Introduction==<br />
<br />
==Variables==<br />
{|<br />
!Variable !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|40||||D||Relative position, like [[VarAction2IndustryTiles#Relative_position_(43)|Industry Tile var43]]<br />
|-<br />
|41||||W||Tile information, see below<br />
|-<br />
|42||||D||Construction date from year 0<br />
|-<br />
|43||||B||Animation counter, see below<br />
|-<br />
|44||||B||Object founder information<br />
|-<br />
|45||||D||Get town zone and Manhattan distance of closest town<br />
|-<br />
|46||||D||Get square of Euclidian distance of closest town<br />
|-<br />
|47||||B||Object colour<br />
|-<br />
|48||||B||Object views<br />
|-<br />
|60||||W||Get object type at offset<br />
|-<br />
|61||||B||Get random bits at offset<br />
|-<br />
|62||||D||Land info of nearby tiles<br />
|-<br />
|63||||W||Animation counter of nearby tile<br />
|-<br />
|64||||D||Count of object, distance of closest instance<br />
|}<br />
<br />
==Description==<br />
===Tile information (41)===<br />
<br />
The return value has the format of ss0t where t is the terrain type which the tile is on, same values as [[VarAction2Canals|canal var81]].<br />
<br />
As of TTDPatch r2088, ss contains the slope data of the tile, same format as for [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_(60)| industrytile var60]]. The meaning of the individual bits is:<br />
<br />
{|<br />
!Bit!!Meaning<br />
|-<br />
|0||West corner is above the lowest<br />
|-<br />
|1||South corner is above the lowest<br />
|-<br />
|2||East corner is above the lowest<br />
|-<br />
|3||North corner is above the lowest<br />
|-<br />
|4||The tile is a steep slope (*)<br />
|}<br />
<br />
(*) - Steep slopes have this bit plus 3 points raised, giving them values of 0x17, 0x1B, 0x1D and 0x1E.<br />
<br />
===Animation Counter (43)===<br />
<br />
This byte gets the actual value of the animation counter (note that action0, property 10, bit 6 must be set for this to work).<br />
<br />
===Object founder information (44)===<br />
<br />
This byte contains the ID of the company that funded the object, or 10h if the object was placed in the scenario editor.<br />
<br />
===Get town zone and Manhattan distance of closest town (45)===<br />
<br />
Like [[VarAction2Industries#Get_town_zone_and_Manhattan_distance_of_closest_town_(65)|industry var65]] but instead of an offset the current tile is used.<br />
<br />
===Get square of Euclidian distance of closest town (46)===<br />
<br />
Like [[VarAction2Industries#Get_square_of_Euclidean_distance_of_closest_town_(66)|industry var66]] but instead of an offset the current tile is used.<br />
<br />
===Object colour (47)===<br />
<br />
This byte returns the colour of the object.<br />
<br />
(since TTDPatch r2351 and OpenTTD r21259)<br />
<br />
===Get object views (48)===<br />
<br />
Returned value stands for a particular view of an object. Number and rank of set-IDs must match the value given in the object's action0 prop17, i.e. for an object with 4 views, prop48 may return values 0 .. 4. Since OpenTTD r21455.<br />
<br />
===Get object type at offset (60)===<br />
<br />
The parameter of this variable is an offset from 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. Therefore the parameter 00h accesses the current tile itself. The high word of the return value is currently reserved, and the low word can be:<br />
<br />
* 00xxh if the tile is an object tile and was defined in the current GRF with ID xx.<br />
* FFFEh if the tile is an object tile that was defined in another GRF file or it's a default object.<br />
* FFFFh if the tile isn't an object tile.<br />
<br />
===Get random bits at offset (61)===<br />
<br />
Returns the same values as [[VarAction2Industries#Get_random_tile_bits_at_offset_(61)|industry var61]]. The offset it from the current tile and is signed.<br />
<br />
To get the random bits from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
===Land info of nearby tiles (62)===<br />
<br />
Returns the same values as [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_(60)|industry tile var60]]. The offset it from the current tile and is signed.<br />
<br />
To get the land info from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
===Animation counter of nearby tile (63)===<br />
<br />
Returns the var43 of another tile given by the signed offset.<br />
<br />
To get the animation counter from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
===Count of object, distance of closest instance (64)===<br />
<br />
Returns the same values as [[VarAction2Industries#Count_of_industry,_distance_of_closest_instance_(67,_68)|industry var67]]. The distance is from the current tile.<br />
<br />
==Examples==<br />
<br />
===Getting the north tile random bits===<br />
<br />
The following code uses variable 40, 61 and 7B to read the random bits of the north tile of the object.<br />
<br />
<pre> 0 * 0 02 0F xx 81<br />
40 30 FF // Get relative position of object tile as yx<br />
\2^ 1A 20 77 // Negate the numbers in bits 0..3 and 4..7 ...<br />
\2+ 1A 20 11 // ... (here we can optionally insert another (positive) offset, to get some other tile relative to the north tile)<br />
\2^ 1A 20 88 // ... (we need to split the xor in two parts, so bits 0..3 do not influence bits 4..7)<br />
\2rst 7B 61 00 FF // Get the random bits at the northern tile<br />
...</pre></div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Objects&diff=1157VariationalAction2/Objects2011-06-14T14:37:28Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
==Variables==<br />
{|<br />
!Variable !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|40||||D||Relative position, like [[VarAction2IndustryTiles#Relative_position_(43)|Industry Tile var43]]<br />
|-<br />
|41||||W||Tile information, see below<br />
|-<br />
|42||||D||Construction date from year 0<br />
|-<br />
|43||||B||Animation counter, see below<br />
|-<br />
|44||||B||Object founder information<br />
|-<br />
|45||||D||Get town zone and Manhattan distance of closest town<br />
|-<br />
|46||||D||Get square of Euclidian distance of closest town<br />
|-<br />
|47||||B||Object colour<br />
|-<br />
|48||||B||Object views<br />
|-<br />
|60||||W||Get object type at offset<br />
|-<br />
|61||||B||Get random bits at offset<br />
|-<br />
|62||||D||Land info of nearby tiles<br />
|-<br />
|63||||W||Animation counter of nearby tile<br />
|-<br />
|64||||D||Count of object, distance of closest instance<br />
|}<br />
<br />
==Description==<br />
===Tile information (41)===<br />
<br />
The return value has the format of ss0t where t is the terrain type which the tile is on, same values as [[VarAction2Canals|canal var81]].<br />
<br />
As of TTDPatch r2088, ss contains the slope data of the tile, same format as for [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_(60)| industrytile var60]]. The meaning of the individual bits is:<br />
<br />
{|<br />
!Bit!!Meaning<br />
|-<br />
|0||West corner is above the lowest<br />
|-<br />
|1||South corner is above the lowest<br />
|-<br />
|2||East corner is above the lowest<br />
|-<br />
|3||North corner is above the lowest<br />
|-<br />
|4||The tile is a steep slope (*)<br />
|}<br />
<br />
(*) - Steep slopes have this bit plus 3 points raised, giving them values of 0x17, 0x1B, 0x1D and 0x1E.<br />
<br />
===Animation Counter (43)===<br />
<br />
This byte gets the actual value of the animation counter (note that action0, property 10, bit 6 must be set for this to work).<br />
<br />
===Object founder information (44)===<br />
<br />
This byte contains the ID of the company that funded the object, or 10h if the object was placed in the scenario editor.<br />
<br />
===Get town zone and Manhattan distance of closest town (45)===<br />
<br />
Like [[VarAction2Industries#Get_town_zone_and_Manhattan_distance_of_closest_town_(65)|industry var65]] but instead of an offset the current tile is used.<br />
<br />
===Get square of Euclidian distance of closest town (46)===<br />
<br />
Like [[VarAction2Industries#Get_square_of_Euclidean_distance_of_closest_town_(66)|industry var66]] but instead of an offset the current tile is used.<br />
<br />
===Object colour (47)===<br />
<br />
This byte returns the colour of the object.<br />
<br />
(since TTDPatch r2351 and OpenTTD r21259)<br />
<br />
===Get object views (48)===<br />
<br />
Returned value stands for a particular view of an object. Number and rank of set-IDs must match the value given in the object's action0 prop17, i.e. for an object with 4 views, prop48 may return values 0 .. 4. Since OpenTTD r21455.<br />
<br />
===Get object type at offset (60)===<br />
<br />
The parameter of this variable is an offset from 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. Therefore the parameter 00h accesses the current tile itself. The high word of the return value is currently reserved, and the low word can be:<br />
<br />
* 00xxh if the tile is an object tile and was defined in the current GRF with ID xx.<br />
* FFFEh if the tile is an object tile that was defined in another GRF file or it's a default object.<br />
* FFFFh if the tile isn't an object tile.<br />
<br />
===Get random bits at offset (61)===<br />
<br />
Returns the same values as [[VarAction2Industries#Get_random_tile_bits_at_offset_(61)|industry var61]]. The offset it from the current tile and is signed.<br />
<br />
To get the random bits from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
===Land info of nearby tiles (62)===<br />
<br />
Returns the same values as [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_(60)|industry tile var60]]. The offset it from the current tile and is signed.<br />
<br />
To get the land info from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
===Animation counter of nearby tile (63)===<br />
<br />
Returns the var43 of another tile given by the signed offset.<br />
<br />
To get the animation counter from a tile using a offset relative to the north tile of the object, see the example below.<br />
<br />
==Count of object, distance of closest instance (64)==<br />
<br />
Returns the same values as [[VarAction2Industries#Count_of_industry,_distance_of_closest_instance_(67,_68)|industry var67]]. The distance is from the current tile.<br />
<br />
==Examples==<br />
<br />
===Getting the north tile random bits===<br />
<br />
The following code uses variable 40, 61 and 7B to read the random bits of the north tile of the object.<br />
<br />
<pre> 0 * 0 02 0F xx 81<br />
40 30 FF // Get relative position of object tile as yx<br />
\2^ 1A 20 77 // Negate the numbers in bits 0..3 and 4..7 ...<br />
\2+ 1A 20 11 // ... (here we can optionally insert another (positive) offset, to get some other tile relative to the north tile)<br />
\2^ 1A 20 88 // ... (we need to split the xor in two parts, so bits 0..3 do not influence bits 4..7)<br />
\2rst 7B 61 00 FF // Get the random bits at the northern tile<br />
...</pre></div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Industries&diff=1156VariationalAction2/Industries2011-06-14T14:17:24Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
==Variables==<br />
<br />
{| |-<br />
!Variable !!Version !![[GRFActionsDetailed|Size]] !! Description<br />
|-<br />
|40..42||||||Waiting cargo<br />
|-<br />
|43||||||Manhattan distance of closest dry/land tile<br />
|-<br />
|44||||||Layout number (1-based)<br />
|-<br />
|45||||||Player info<br />
|-<br />
|46||||||Date when industry was built in days since year 0<br />
|-<br />
|60||||||Get industry tile ID at offset<br />
|-<br />
|61||||||Get random tile bits at offset<br />
|-<br />
|62||||||Land info of nearby tiles<br />
|-<br />
|63||||||Animation stage of nearby tiles<br />
|-<br />
|64||||||Distance of nearest industry with given type<br />
|-<br />
|65||||||Get town zone and Manhattan distance of closest town<br />
|-<br />
|66||||||Get square of Euclidean distance of closest town<br />
|-<br />
|67||||||Count of industry, distance of closest instance<br />
|-<br />
|68||||||Like the above, but with layout filter<br />
|-<br />
|A7||||||Industry founder information<br />
|-<br />
|B0||||||Date when industry was built in days since 1920<br />
|-<br />
|B3||||||Construction type<br />
|-<br />
|B4||||||Date when cargo was last accepted in days since 1920, or 0 if no cargo was ever accepted (available since 2.6 r1321)<br />
|}<br />
<br />
For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_IndustryArray|TTD industry structure].<br />
<br />
===Waiting cargo (40..42)===<br />
<br />
If bit 1 or 2 is set in property 21, these variables contain the amount of incoming cargo waiting to be processed. (40 gives the amount of the first type waiting, 41 gives the same for the second type etc.) These variables are capped at FFFFh (65535).<br />
<br />
===Manhattan distance of closest dry/land tile (43)===<br />
<br />
(from r1298)<br />
<br />
This variable works the same way as var. 8B does during callback 28: if your industry is built on water, it gives the distance of the closest dry land tile, otherwise it gives the distance of the closest water tile. However, you can't use this variable during callback 28; you must always use 8B.<br />
<br />
'''PLEASE NOTE''': This variable is rather expensive to compute because, in the worst case, it has to check all tiles on the map before it gives up looking for a good tile. Try to avoid it in frequent callbacks such as the production callback, animation callbacks (unless the animation is slow, around 1 frame per game day or slower). It is, however, OK to use it during the production change callbacks.<br />
<br />
===Layout number (44)===<br />
<br />
If the industry was created running TTDPatch 2.6 r1594 or later, this variable returns the number of the current layout. The first layout will return 01, the second 02, etc. In other words, this is one larger than what you get in variable 86 during callback 28.<br />
<br />
If the industry was created using an earlier version of TTDPatch, or while newindustries was off, the result will be zero.<br />
<br />
===Player info (45)===<br />
<br />
(From 2.6 r1711)<br />
<br />
As [[VarAction2Vehicles#Player_info_43_|vehicle variable 43]], except that the no-player state is indicated by var A7 being 10h.<br />
<br />
===Date when industry was built in days since year 0 (46)===<br />
<br />
(From OpenTTD r13443, 2.6 r2047)<br />
<br />
Exact same behaviour as var B0, but based on year 0, instead of year 1920<br />
<br />
In TTDPatch, industry age is limited to 65535 days (approximately 180 years) -- build date is never more than 65535 days ago.<br />
<br />
===Get industry tile ID at offset (60)===<br />
<br />
(from TTDPatch 2.0.1 alpha 73 and above only)<br />
<br />
The parameter of this variable is an offset from the northernmost tile of the industry: the high nibble contains the Y offset, the low one the X offset; both are unsigned. The high word of the return value is currently reserved, and the low word can be:<br />
* 00xxh if the tile is an industry tile and was defined in the current GRF with ID xx.<br />
* FFxxh if the tile is an industry tile of an old type, and has the ID xx.<br />
* FFFEh if the tile is an industry tile that was defined in another GRF file<br />
* FFFFh if the tile isn't an industry tile, or doesn't belong to the current industry<br />
<br />
===Get random tile bits at offset (61)===<br />
<br />
(from TTDPatch 2.0.1 alpha 73 and above only)<br />
<br />
The parameter of this variable is an offset from the northernmost tile of the industry: the high nibble contains the Y offset, the low one the X offset; both are unsigned. If there's an industry tile on that offset and it belongs to the current industry, the lowest byte of the return value will contain the random bits of that tile. Otherwise, the lowest byte will be zero.<br />
<br />
The other bytes are reserved for future use.<br />
<br />
===Land info of nearby tiles (62)===<br />
<br />
(from TTDPatch 2.0.1 alpha 74 and above only)<br />
<br />
The parameter of this variable is an offset from the northernmost tile of the industry: the high nibble contains the Y offset, the low one the X offset; both are unsigned. This variable returns the same values as [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_60_|industry tile variable 60]], in the same format, except that bit 0 in the '''bb''' part is undefined. The offset should be given relatively to the north corner of the industry.<br />
<br />
===Animation stage of nearby tiles (63)===<br />
<br />
The parameter of this variable is an offset from the northernmost tile of the industry: the high nibble contains the Y offset, the low one the X offset; both are unsigned. This variable returns the same values as [[VarAction2IndustryTiles#Animation_stage_for_nearby_tiles_61_|industry tile variable 61]], in the same format. The offset should be given relatively to the north corner of the industry.<br />
<br />
===Distance of nearest industry with given type (64)===<br />
<br />
The format of the parameter is the same as for industry property 16: either the ID of a new type with bit 7 set, or the ID of an old type. The returned value is FFFFFFFFh if there are no industries with the given type (not counting the current one, if it has the given type); otherwise, the returned value is the Manhattan distance of the closest industry with the given type.<br />
<br />
===Get town zone and Manhattan distance of closest town (65)===<br />
<br />
The parameter gives an offset from the northernmost tile of the industry: the high nibble means the Y offset, the low nibble means the X offset, both signed. The returned value is rrzzdddd, where rr is reserved for future use, zz is the town zone of the selected tile, while dddd is the Manhattan distance of the closest town.<br />
<br />
===Get square of Euclidean distance of closest town (66)===<br />
<br />
The parameter works like for var. 65, but the result is the Euclidean distance of the closest town, squared.<br />
<br />
===Count of industry, distance of closest instance (67, 68)===<br />
<br />
Variable 67 gets two parameters: the GRFID of the GRF where the industry is defined in register 100h (can be written using operator 0E of [[VarAction2Advanced|variational action 2]]) and the setID of the industry as the regular parameter. There are two special cases for the GRFID: 00000000h means you're checking for a default TTD industry type, while FFFFFFFFh can be used instead of the GRFID of the current GRF.<br />
<br />
The return value has the format rrccdddd, where rr is reserved for future use, cc is the number of instances of the industry type and dddd is the Manhattan distance of the closest instance, of FFFFh if not appliable.<br />
<br />
You may note that this variable can be used instead of variable 64. This variable is the preferred way to get this information since it allows you to check industries defined in other GRFs as well. Variable 64 will stay for backward compatibility only.<br />
<br />
Variable 68 works like variable 67, except that you can put a layout number in the lowest byte of register 101. (The other bits are reserved for future use, leave them zero for now.) This layout number should be 1-based (the first layout is 01, not 00). Only industries with the given layout are considered for counting and calculating distance. As a special case, if the layout number is 00, all layouts are counted, and so the result is the same as with variable 67.<br />
<br />
Since OpenTTD r22434, it is possible to filter by the town of the current industry. If the bit number 8 is set, only industries in the same town than the current one will be considered.<br />
<br />
===Industry founder information (A7)===<br />
<br />
Since TTDPatch 2.0.1 alpha 74, this byte contains the ID of the company that funded the industry, or 10h if the industry was generated randomly. If the industry was built using an earlier TTDPatch version or with newindustries turned off, this field is 10h.<br />
<br />
===Construction type (B3)===<br />
<br />
This byte tells you how the industry got onto the map. The following values are possible:<br />
<br />
{| |-<br />
!Value!!Meaning<br />
|-<br />
|0||Unknown - This industry was built with newindustries being off, or in a TTDPatch version prior to 2.0.1 alpha 74<br />
|-<br />
|1||Created during normal gameplay, either by a player or the in-game random industry generator<br />
|-<br />
|2||Created during random map generation<br />
|-<br />
|3||Created in the scenario editor<br />
|}<br />
<br />
In case 1, you can check variable A7 to find out whether the industry was funded by a player or by the random generator.<br />
<br />
==Example==</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=StringCodes&diff=1155StringCodes2011-06-14T14:15:32Z<p>Terkhen: Fix style and format</p>
<hr />
<div>=String Codes=<br />
<br />
Texts in TTD are mostly in the Latin-1 (ISO-8859-1) character set (except when using UTF-8 encoding; see below), however a few characters are different. &nbsp;Also, some characters have special meaning. These are explained in the following table.<br />
<br />
{| |-<br />
!Range, hex!!Meaning<br />
|-<br />
|00..1F||Control characters, unused except for the following:<br />
|-<br />
|||01 X offset in next byte of string (variable space)<br />
|-<br />
|||0D New line<br />
|-<br />
|||0E Set small font size<br />
|-<br />
|||0F Set large font size<br />
|-<br />
|||1F X and Y offsets in next two bytes of string<br />
|-<br />
|20..7A|| Latin-1 characters, from space &quot; &quot; up to lower case &quot;z&quot;<br />
|-<br />
|7B..87|| Formatting instructions, all take their argument from the stack if not otherwise specified<br />
|-<br />
|||7B Print dword<br />
|-<br />
|||7C Print signed word<br />
|-<br />
|||7D Print signed byte<br />
|-<br />
|||7E Print unsigned word<br />
|-<br />
|||7F Print dword in currency units<br />
|-<br />
|||80 Print substring (text ID from stack)<br />
|-<br />
|||81 Print substring (text ID in next 2 bytes of string)<br />
|-<br />
|||82 Print date (day, month, year)<br />
|-<br />
|||83 Print month and year<br />
|-<br />
|||84 Print signed word in speed units<br />
|-<br />
|||85 Discard next word from stack<br />
|-<br />
|||86 Rotate down top 4 words on stack<br />
|-<br />
|||87 Print signed word in litres<br />
|-<br />
|88..98||Colour codes<br />
|-<br />
|||88 Blue<br />
|-<br />
|||89 Light Gray<br />
|-<br />
|||8A Light Orange (&quot;Gold&quot;)<br />
|-<br />
|||8B Red<br />
|-<br />
|||8C Purple<br />
|-<br />
|||8D Gray-Green<br />
|-<br />
|||8E Orange<br />
|-<br />
|||8F Green<br />
|-<br />
|||90 Yellow<br />
|-<br />
|||91 Light Green<br />
|-<br />
|||92 Red-Brown<br />
|-<br />
|||93 Brown<br />
|-<br />
|||94 White<br />
|-<br />
|||95 Light Blue<br />
|-<br />
|||96 Dark Gray<br />
|-<br />
|||97 Mauve (grayish purple)<br />
|-<br />
|||98 Black<br />
|-<br />
|99||Switch to company colour that follows in next byte (enabled by enhancegui)<br />
|-<br />
|9A||Extended format code in next byte:<br />
|-<br />
|||00 -or- 01 Display 64-bit value from stack in currency units<br />
|-<br />
|||02 Ignore next colour byte. Multiple instances will skip multiple colour bytes.<br />
|-<br />
|||03 WORD Push WORD onto the textref stack<br />
|-<br />
|||04 BYTE Un-print the previous BYTE characters.<br />
|-<br />
|||05 For internal use only. Not valid in GRF files.<br />
|-<br />
|||06 Print byte in hex (since TTDPatch r2007)<br />
|-<br />
|||07 Print word in hex (since TTDPatch r2007)<br />
|-<br />
|||08 Print dword in hex (since TTDPatch r2007)<br />
|-<br />
|||09 For internal use only. Usage in NewGRFs will most likely crash TTDPatch. (since TTDPatch r2128)<br />
|-<br />
|||0A For internal use only. Usage in NewGRFs will most likely crash TTDPatch. (since TTDPatch r2128)<br />
|-<br />
|||0B Print 64-bit value in hex (since TTDPatch r2178)<br />
|-<br />
|||0C Print name of station with id in next textrefstack word (since TTDPatch r2178)<br />
|-<br />
|||0D Print signed word in tonnes (since OpenTTD r21086)<br />
|-<br />
|||0E Set gender of string, NewGRF internal ID in next byte. Must be first in a string (since OpenTTD r21209) (*)<br />
|-<br />
|||0F Select case for next substring, NewGRF internal ID in next byte (since OpenTTD r21209) (*)<br />
|-<br />
|||10 Begin choice list value, NewGRF internal ID in next byte (since OpenTTD r21211) (**)<br />
|-<br />
|||11 Begin choice list default (since OpenTTD r21211) (**)<br />
|-<br />
|||12 End choice list (since OpenTTD r21211) (**)<br />
|-<br />
|||13 Begin gender choice list, stack offset of substring to get gender from in next byte (since OpenTTD r21211) (**)<br />
|-<br />
|||14 Begin case choice list (since OpenTTD r21211) (**)<br />
|-<br />
|||15 Begin plural choice list, stack offset of value to get plural for in next byte (since OpenTTD r21216) (***)<br />
|-<br />
|9B..9D||Reserved<br />
|-<br />
|9E..FF||Latin-1 characters, except for the following:<br />
|-<br />
|||9E Euro character &quot;&euro;&quot;<br />
|-<br />
|||9F Capital Y umlaut &quot;&Yuml;&quot;<br />
|-<br />
|||A0 Scroll button up<br />
|-<br />
|||AA Scroll button down<br />
|-<br />
|||AC Tick mark<br />
|-<br />
|||AD X mark<br />
|-<br />
|||AF Scroll button right<br />
|-<br />
|||B4 Train symbol<br />
|-<br />
|||B5 Truck symbol<br />
|-<br />
|||B6 Bus symbol<br />
|-<br />
|||B7 Plane symbol<br />
|-<br />
|||B8 Ship symbol<br />
|-<br />
|||B9 Superscript -1<br />
|-<br />
|||BC Small scroll button up<br />
|-<br />
|||BD Small scroll button down<br />
|}<br />
<br />
The formatting instructions must not be used except in strings that expect them, and then they may not be out of order (with the possible exception of code 86 shuffling the internal stack). When used improperly, they will most likely crash TTD. Code 81 is always safe to use (provided that the referenced text ID uses no unsafe formatting instructions either), and will insert the given text ID (e.g. &quot;\81\3D\A0&quot; will insert text ID A03D, &quot;\98Refit Aircraft&quot;). Note however that if you want to include e.g. ID D000/D400, the 00 byte will be considered the end of string, and this will therefore break if additional texts are supposed to follow in the action 4. DCxx IDs must not be included; neither codes 80 nor 81 correctly access DCxx IDs.<br />
<br />
Each formatting instructions removes its argument from the stack, so that the next one will receive the following bytes as arguments. Code 86 takes the top four words from the stack, let's call them W1 through W4, and reorders them as W4 W1 W2 W3. This is used for languages in which industries or stations should be named not &quot;Flinfingbury Power Plant&quot; but &quot;Power Plant Flinfingbury&quot;.<br />
<br />
(*) Maps a NewGRF internal gender or case ID to an OpenTTD gender or case. The internal ID is resolved to the appropriate OpenTTD gender or case at load time by means of the mapping. The first internal ID in the mapping that matches the ID from the string and has an existing OpenTTD gender or case is taken, i.e. the list of mappings is filtered by internal ID and existance of the OpenTTD gender/case and then the top element is used. When the gender or case ID is not known, or there is no existing OpenTTD gender or case with the mapped names the whole mapping is ignored and the default gender or case is taken.<br />
<br />
==Example==<br />
<br />
<pre>// Gender translation table<br />
<br />
// Current OpenTTD German translation uses m, w, n and p but<br />
<br />
// support a (fictitious) previous version that used masculine,<br />
<br />
// feminine, neuter and plural as gender names.<br />
<br />
&nbsp;0 * 56 &nbsp; &nbsp; 00 08 01 01 02<br />
<br />
&nbsp; &nbsp; 13<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;01 &quot;m&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;01 &quot;masculine&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;02 &quot;w&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;02 &quot;feminine&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;03 &quot;n&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;03 &quot;neuter&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;04 &quot;p&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;04 &quot;plural&quot; 00<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;00<br />
<br />
// Brauerei is a female word in German; this sets it as female.<br />
<br />
&nbsp;1 * 40 &nbsp; &nbsp; 04 0A 82 01 73 DC C3 9E 9A 0E 02 &quot;Brauerei&quot; 00</pre><br />
<br />
In this case OpenTTD would look for NewGRF internal ID 2 in the gender table. This would yield &quot;w&quot; and &quot;feminine&quot; as OpenTTD gender names. In current OpenTTD this would match &quot;w&quot;, in the fictitious older version of OpenTTD it will match &quot;feminine&quot;.<br />
<br />
(**) Maps an OpenTTD gender or case to the NewGRF internal gender or case ID. The mapping is resolved at load time by going through all cases or genders OpenTTD's translation knows an mapping these to NewGRF internal IDs. If mapping is found the default choice list item is chosen. This happens by filtering the mapping on the gender or case name and then the NewGRF internal ID of the top element is used.<br />
<br />
The choice list string codes are related and must be used in a specific manner:<br />
<br />
Genders: 9A 13 &lt;offset&gt; (9A 10 &lt;index&gt; &lt;string&gt;)+ 9A 11 &lt;default&gt; 9A 12<br />
<br />
Cases: 9A 14 (9A 10 &lt;ndex&gt; &lt;string&gt;)+ 9A 11 &lt;default&gt; 9A 12<br />
<br />
Plurals: 9A 13 &lt;offset&gt; (9A 10 &lt;index&gt; &lt;string&gt;)+ 9A 11 &lt;default&gt; 9A 12<br />
<br />
The offset is the stack location of the substring/value you want to get the gender/plural for. This is the real offset plus 80, i.e. an offset of 0 becomes 80 and an offset of 1 becomes 81 in the NFO.<br />
<br />
=Example=<br />
<br />
<pre>// Assuming the translation table of the previous example<br />
<br />
// A string with a gender choice list and a stack item that gets resolved<br />
<br />
&nbsp;2 * 29 &nbsp; &nbsp; 04 0A FF 01 1A DC &quot;D&quot; 9A 13 80 9A 10 1 &quot;er&quot; 9A 10 3 &quot;as&quot; 9A 11 &quot;ie&quot; 9A 12 &quot; &quot; 80 00</pre><br />
<br />
Imagine the &quot;Brauerei&quot; from the previous example being, as substring, on the stack. Then this string would resolve to &quot;Die Brauerei&quot;.<br />
<br />
What happens in OpenTTD is that whenever the &quot;begin gender choice list&quot; string code is found it will resolve the string at the given stack location. Of that resolved string the first character is compared to the &quot;set gender&quot; string code and if that is the case the (mapped) OpenTTD gender is retrieved. When there is &quot;set gender&quot; string code the first OpenTTD gender is used. After resolving the OpenTTD gender that gender is reverse mapped to a NewGRF internal ID. If that NewGRF internal ID exists in one of the &quot;choice list values&quot; that (sub)string is taken (up till the next choice list value/default). If there is no reverse mapping the string at the &quot;choice list default&quot; string code is used up till the &quot;end choice list&quot; string code. Further processing of the string happens after the choice list, i.e. the (sub)strings in the choice list may not contain any special string codes except colour codes.<br />
<br />
Case choice lists work in a similar matter, except that instead of resolving a case from a (sub)string we &quot;are&quot; the substring; the string that includes this substring has set a case using the &quot;select case&quot; string code. As such no offset has to be given to the choice list, but the rest works in the same way as gender choice lists.<br />
<br />
(***) The plural list works like a gender list, however you have to choose one &quot;mapping&quot; from value to plural index by setting the plural form using [[Action0GeneralVariables]] property 15.<br />
<br />
If, for example, plural form 0 is chosen using the [[Action0GeneralVariables]] property 15, then there are 2 plural indices. If the value at the stack with the given offset equals 1 you get plural index 1, otherwise plural index 2. These plural indices are the indices that are used in the choice lists.<br />
<br />
{| |-<br />
!Plural form!!Plural index!!Description<br />
|-<br />
|0||Two forms:<br />
|-<br />
|||1||1<br />
|-<br />
|||2||rest<br />
|-<br />
|1||Only one form:<br />
|-<br />
|||1||every form<br />
|-<br />
|2||Two forms:<br />
|-<br />
|||1||0 or 1<br />
|-<br />
|||2||rest<br />
|-<br />
|3||Three forms:<br />
|-<br />
|||1||ending in 1, but not ending in 11<br />
|-<br />
|||2||0<br />
|-<br />
|||3||rest<br />
|-<br />
|4||Five forms:<br />
|-<br />
|||1||1<br />
|-<br />
|||2||2<br />
|-<br />
|||3||3-6<br />
|-<br />
|||4||7-10<br />
|-<br />
|||5||rest<br />
|-<br />
|5||Three forms:<br />
|-<br />
|||1||ending in 1, but not ending in 11<br />
|-<br />
|||2||ending in 2-9, but not ending in 1~91~2-9~93~<br />
|-<br />
|||3||rest<br />
|-<br />
|6||Three forms:<br />
|-<br />
|||1||ending in 1, but not ending in 11<br />
|-<br />
|||2||ending in 2-4, but not ending in 1~91~2-4~93~<br />
|-<br />
|||3||rest<br />
|-<br />
|7||Three forms:<br />
|-<br />
|||1||0<br />
|-<br />
|||2||ending in 2-4, but not ending in 1~91~2-4~93~<br />
|-<br />
|||3||rest<br />
|-<br />
|8||Four forms:<br />
|-<br />
|||1||ending in 01<br />
|-<br />
|||2||ending in 02<br />
|-<br />
|||3||ending in 03 or ending in 04<br />
|-<br />
|||4||rest<br />
|-<br />
|9||Two forms:<br />
|-<br />
|||1||ending in 1, but not ending in 11<br />
|-<br />
|||2||ret<br />
|-<br />
|10||Three forms:<br />
|-<br />
|||1||1<br />
|-<br />
|||2||2-4<br />
|-<br />
|||3||rest<br />
|-<br />
|11||Two forms:<br />
|-<br />
|||1||ending in 0, 1, 3, 6, 7 and 8<br />
|-<br />
|||2||ending in 2, 4, 5 and 9<br />
|-<br />
|12||Four forms:<br />
|-<br />
|||1||1<br />
|-<br />
|||2||0 or ending in 02-10<br />
|-<br />
|||3||ending in 11-19<br />
|-<br />
|||4||rest<br />
|}<br />
<br />
=Example=<br />
<br />
<pre>// Gender translation table<br />
<br />
// Set the plural type to type 0<br />
<br />
&nbsp;0 * 7 &nbsp; &nbsp; 00 08 01 01 02 15 00<br />
<br />
// In case of the first stack item being 1 use &quot;Tonne&quot;, otherwise use &quot;Tonnen&quot;<br />
<br />
&nbsp;1 * 34 &nbsp; &nbsp; 04 0B 82 01 1A DC C3 9E &quot;\UE07C Tonne&quot; 9A 15 80 9A 10 01 &quot;&quot; 9A 11 &quot;n&quot; 9A 12 &quot; Sand&quot; 00</pre><br />
<br />
=UTF-8 support=<br />
<br />
Since 2.0.1 alpha 68, TTDPatch supports UTF-8 encoded input strings. Use [[Action12|action 12]] to define glyphs for the characters which do not exist in TTD's .grf files (possible since 2.0.1 alpha 73).<br />
<br />
To indicate that a given string is in UTF-8 encoding, start it with a capital thorn (U+00DE, &quot;&THORN;&quot;), encoded in UTF-8 as usual with the bytes C3 9E. &nbsp;Everything in that string is then assumed to be in UTF-8 encoding, with the following exception: if characters appear that are not valid UTF-8 sequences, they are assumed to be one of the above control codes. This way, it is still possible to write, e.g. &quot;&THORN;Capacity: &quot; 87 &quot;litres&quot;, without encoding the 87 in UTF-8 (which would instead refer to a character installed at codepoint U+0087).<br />
<br />
In addition, this allows using the non-Unicode characters 9E, 9F, A0, AA, AC, AD, AF, B4..B9, BC and BD from the above list, which when encoded with UTF-8 would refer to their respective Unicode characters instead. To use the TTD characters, simply do not encode them using UTF-8 but enter them directly as bytes. This causes them to be an invalid UTF-8 sequence and allows TTDPatch to use the correct symbol from TTD's fonts.<br />
<br />
Alternatively, these symbols (in fact, the TTD character set from 20 to FF) are also mapped into the Unicode Private Use Area at U+E0xx, so to encode the truck symbol, you may use character U+E0B5 as well, although this will probably be an unprintable character in most text editors.<br />
<br />
Finally, characters 7B..7F no longer function as the above formatting instructions, but will display regular glyphs instead (provided they are installed; by default TTD has none at these codepoints). Instead, to use these formatting instructions in UTF-8 mode, you need to use their Private Use Area codepoint at U+E0xx.<br />
<br />
Basically there are three possibilities:<br />
# Characters U+E020..U+E0FF &nbsp;in the E0xx Private Use Area do what their respective character xx would do in TTD, as do the control characters below U+0020<br />
# All other valid UTF-8 sequences display actual glyphs, if they are available<br />
# All invalid UTF-8 sequences do what their individual bytes would do in TTD<br />
<br />
To summarize, here's a handy table:<br />
<br />
{| |-<br />
!Character!!Encoding in UTF-8 mode!!Meaning<br />
|-<br />
|7E||7E||Unicode Character 'TILDE' (~)<br />
|-<br />
|82||82 (invalid UTF-8)||Print date (day, month, year)<br />
|-<br />
|82||C2 82||Display glyph for U+0082<br />
|-<br />
|AC||AC (invalid UTF-8)||Tick mark<br />
|-<br />
|AC||C2 AC||Unicode Character 'NOT SIGN' (&not;)<br />
|-<br />
|E07E||EE 81 BE||Print unsigned word<br />
|-<br />
|E082||EE 82 82||Print date (day, month, year)<br />
|-<br />
|E0AC||EE 82 AC||Tick mark<br />
|}</div>Terkhenhttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Cargos&diff=1154VariationalAction2/Cargos2011-06-14T14:08:05Z<p>Terkhen: Fix style and format</p>
<hr />
<div>==Introduction==<br />
<br />
Currently, cargos don't have 40+x, 60+x, or 80+x variables, but they might be added later.</div>Terkhen