https://newgrf-specs.tt-wiki.net/api.php?action=feedcontributions&user=Pm-bot&feedformat=atomGRFSpecs - User contributions [en-gb]2024-03-28T14:33:30ZUser contributionsMediaWiki 1.35.13https://newgrf-specs.tt-wiki.net/index.php?title=CargoTypes&diff=2736CargoTypes2011-10-24T19:36:42Z<p>Pm-bot: Feat 08 is 'Global Settings'</p>
<hr />
<div>'''Cargo types in TTD'''<br />
<br />
Definitions of cargo types used in TTD and the Patch<br />
<br />
For setting the various action 0 properties of vehicles, various way of specifying the cargo type are used. Typically, there is one property that sets the default cargo type, and another property that sets the cargo types available for refitting in a bit mask.<br />
<br />
The following table lists the values to use for these properties, as well as the values to use for [[Action3|action 3]].<br />
<br />
{| class="wikitable<br />
|-<br />
! Column <br />
! Name<br />
! Usage<br />
|-<br />
| Type A<br />
| Cargo bit<br />
| Use this cargo type in action 3. When using a [[Action0/Global Settings#Cargo translation table 09|cargo translation table]], this is the <br />
<br />
position in the translation table. If there is no cargo translation table, the cargo bit is defined by property 08 for new cargos.<br />
|-<br />
| Bit value<br />
| <br />
| Add these bit values to find the value to give the refit mask property (this is -+1 << cargobit+-)<br />
|-<br />
| Type B<br />
| Cargo slot<br />
| Use this cargo type to set the default cargo type of vehicles (note, this is climate dependent!). For new cargos this is the ID used in Action 0 and Action 3 of the cargo-defining NewGRF.<br />
|}<br />
<br />
Note, when New Cargos are being used, you can only rely on Type A values when using a cargo translation table. Type B values depend on the actual NewGRF (and its version) defining the new cargos; so, unless you test for a specific (industry) NewGRF you cannot rely on any value for Type B. <br />
<br />
That means, to be compatible to any new cargos, you have to set the default cargo of refittable vehicles to "first refittable". However, you can kind of rely on passengers being slot 0 and mail being slot 2.<br />
<br />
<br />
{| class="wikitable<br />
|-<br />
! Type A<br />
! Bit Value<br />
! Type B<br />
! Cargo<br />
! style="background: #FFA020; color: black" | [http://www.tt-wiki.net/wiki/ECS ECS]<br />
! style="background: #0000C0; color: white" | Type B<br />
! style="background: #0CDDA0; color: white" | [http://www.tt-wiki.net/wiki/FIRS FIRS]<br />
|-<br />
| 00<br />
| 1<br />
| 00<br />
| Passengers<br />
| +<br />
| 00<br />
| +<br />
|-<br />
| 01<br />
| 2<br />
| 01<br />
| Coal<br />
| +<br />
| 01<br />
| +<br />
|-<br />
| 02<br />
| 4<br />
| 02<br />
| Mail<br />
| +<br />
| 02<br />
| +<br />
|-<br />
| 03<br />
| 8<br />
| 03<br />
| Oil<br />
| +<br />
| 03<br />
| +<br />
|-<br />
| 04<br />
| 10<br />
| 04<br />
| Livestock<br />
| +<br />
| 04<br />
| +<br />
|-<br />
| 05<br />
| 20<br />
| 05<br />
| Goods<br />
| +<br />
| 05<br />
| +<br />
|-<br />
| 06<br />
| 40<br />
| 06<br />
| Grain/Wheat/Maize<br />
| +<br />
| 06<br />
| +<br />
|-<br />
| 07<br />
| 80<br />
| 07<br />
| Wood<br />
| +<br />
| 07<br />
| +<br />
|-<br />
| 08<br />
| 100<br />
| 08<br />
| Iron Ore<br />
| +<br />
| 08<br />
| +<br />
|-<br />
| 09<br />
| 200<br />
| 09<br />
| Steel<br />
| +<br />
| 09<br />
| + (Metal)<br />
|-<br />
| 0A<br />
| 400<br />
| 0A<br />
| Valuables/Gold/Diamonds<br />
| +<br />
| 0A<br />
| Milk<br />
|-<br />
| 0B<br />
| 800<br />
| 09<br />
| Paper<br />
| Food<br />
| 0B<br />
| Food<br />
|-<br />
| 0C<br />
| 1000<br />
| 0B<br />
| Food<br />
| Paper<br />
| 0C<br />
| Raw Sugar<br />
|-<br />
| 0D<br />
| 2000<br />
| 04<br />
| Fruit<br />
| +<br />
| 0D<br />
| Fruit and Vegetables<br />
|-<br />
| 0E<br />
| 4000<br />
| 08<br />
| Copper Ore<br />
| Fish<br />
| 0E<br />
| Fish<br />
|-<br />
| 0F<br />
| 8000<br />
| 09<br />
| Water<br />
| Wool<br />
| 0F<br />
| Wool<br />
|-<br />
| 10<br />
| 10000<br />
| 01<br />
| Rubber<br />
| Potash<br />
| 10<br />
| Clay<br />
|-<br />
| 11<br />
| 20000<br />
| 01<br />
| Sugar<br />
| Sand<br />
| 11<br />
| Sand<br />
|-<br />
| 12<br />
| 40000<br />
| 03<br />
| Toys<br />
| Glass/Ceramics<br />
| 12<br />
| Manufacturing Supplies<br />
|-<br />
| 13<br />
| 80000<br />
| 04<br />
| Batteries<br />
| Wood products<br />
| 13<br />
| Lumber<br />
|-<br />
| 14<br />
| 100000<br />
| 05<br />
| Candy (Sweets)<br />
| Dyes<br />
| 14<br />
| Scrap Metal<br />
|-<br />
| 15<br />
| 200000<br />
| 06<br />
| Toffee<br />
| Fertiliser<br />
| 15<br />
| Farm Supplies<br />
|-<br />
| 16<br />
| 400000<br />
| 07<br />
| Cola<br />
| Oil seeds<br />
| 16<br />
| Plant Fibres<br />
|-<br />
| 17<br />
| 800000<br />
| 08<br />
| Cotton Candy (Candyfloss)<br />
| Refined products<br />
| 17<br />
| Chemicals<br />
|-<br />
| 18<br />
| 1000000<br />
| 09<br />
| Bubbles<br />
| Vehicles<br />
| 18<br />
| Engineering Supplies<br />
|-<br />
| 19<br />
| 2000000<br />
| 0A<br />
| Plastic<br />
| Petrol<br />
| 19<br />
| Petrol<br />
|-<br />
| 1A<br />
| 4000000<br />
| 0B<br />
| Fizzy Drinks<br />
| Bricks<br />
| 1A<br />
| Gravel<br />
|-<br />
| 1B<br />
| 8000000<br />
| 0B<br />
| Paper<ref name="moreindustries">Only in temperate climate, with the "moreindustriesperclimate" switch, i.e. disabled when "newcargos" is switched on.</ref><br />
| Sulphur<br />
| 1B<br />
| Bauxite<br />
|-<br />
| 1C<br />
| 10000000<br />
| 08<br />
| undefined; unused slot in arctic climate<br />
| Cement<br />
| 1C<br />
| Building Materials<br />
|-<br />
| 1D<br />
| 20000000<br />
| -<br />
| undefined; unused slot<br />
| Fibre crops<br />
| 1D<br />
| Alcohol<br />
|-<br />
| 1E<br />
| 40000000<br />
| - <br />
| undefined; unused slot<br />
| Lime stone<br />
| 1E<br />
| Reserved1<br />
|-<br />
| 1F<br />
| 80000000<br />
| -<br />
| undefined; unused slot<br />
| Tourists<br />
| 1F<br />
| Reserved2<br />
|-<br />
| n/a<br />
| n/a<br />
| FF<br />
| colspan="4" | Use first <ref name="firstrefittable">"first" means first wrt. cargo slot, type B. I.e. this is purely up to the cargo-defining NewGRF and cannot be influenced by the vehicle NewGRF.</ref> refittable cargo type as default cargo. See also [[VehicleRefitting|vehicle refitting]].<br />
|-<br />
| FE<br />
| n/a<br />
| n/a<br />
| colspan="4" | Used in action 3 for stations to disable default<br />
|-<br />
| FF<br />
| n/a<br />
| n/a<br />
| colspan="4" | Shown in purchase list<br />
|}<br />
<br />
<references /><br />
<br />
== Cargo Labels ==<br />
<br />
The following cargo labels have been defined so far:<br />
<br />
<br />
{| class="wikitable<br />
|-<br />
! Label<br />
! Cargo Description<br />
! [[Action0Cargos#Cargo classes 16|Cargo classes]]<br />
! colspan="3" | Notes<br />
|-<br />
| align="center" colspan="6" | '''TTD Default Cargos'''<br />
|- <br />
| PASS<br />
| Passengers<br />
| 0001 Passengers <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| <br />
|-<br />
| COAL<br />
| Coal<br />
| 0010 Bulk<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|- <br />
| MAIL<br />
| Mail<br />
| 0002 Mail<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|- <br />
|OIL_<br />
| Oil<br />
| 0040 Liquid<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|- <br />
| LVST<br />
| Livestock<br />
| 0020 Piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| GOOD<br />
| Goods<br />
| 0004 Express<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| GRAI<br />
| Grain<br />
| 0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| Temperate; see also WHEA, MAIZ, CERE<br />
|-<br />
| WOOD<br />
| Wood<br />
| 0020 Piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| IORE<br />
| Iron Ore<br />
| 0010 Bulk <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| STEL<br />
| Steel<br />
| 0020 Piece goods<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| Renamed "Metal" in FIRS.<br />
|-<br />
| VALU<br />
| Valuables<br />
| 0008 Armoured<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| Temperate; see also GOLD, DIAM<br />
|-<br />
| PAPR<br />
| Paper<br />
| 0020 Piece goods<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| <br />
|-<br />
| WHEA<br />
| Wheat<br />
| 0010 Bulk <br />
| <br />
| <br />
| Arctic; see also GRAI, MAIZ, CERE<br />
|-<br />
| FOOD<br />
| Food<br />
| 0084 Express, refrigerated<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| <br />
|-<br />
| GOLD<br />
| Gold<br />
| 0008 Armoured<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| Arctic; see also VALU, DIAM<br />
|-<br />
| RUBR<br />
|Rubber<br />
|0040 Liquid <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| <br />
|-<br />
| FRUT<br />
| Fruit<br />
| 0090 Bulk, refrigerated<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| <br />
|-<br />
| MAIZ<br />
| Maize<br />
| 0010 Bulk <br />
| <br />
| <br />
| Tropic; see also GRAI, WHEA, CERE<br />
|-<br />
| CORE<br />
| Copper Ore<br />
| 0010 Bulk <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| <br />
|-<br />
| WATR<br />
| Water<br />
| 0040 Liquid <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| <br />
|-<br />
| DIAM<br />
| Diamonds<br />
| 0008 Armoured<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
| Tropic; see also VALU, GOLD<br />
|-<br />
| SUGR<br />
| Sugar<br />
| 0010 Bulk <br />
| <br />
| <br />
| <br />
|-<br />
| TOYS<br />
| Toys<br />
| 0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| BATT<br />
| Batteries<br />
| 0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| SWET<br />
|Sweets (Candy)<br />
|0004 Express <br />
| <br />
| <br />
|<br />
|-<br />
| TOFF<br />
|Toffee<br />
|0010 Bulk <br />
| <br />
| <br />
|<br />
|-<br />
| COLA<br />
|Cola<br />
|0040 Liquid <br />
| <br />
| <br />
|<br />
|-<br />
| CTCD<br />
|Cotton Candy (Candyfloss)<br />
|0010 Bulk <br />
| <br />
| <br />
|<br />
|-<br />
| BUBL<br />
|Bubbles<br />
|0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| PLST<br />
|Plastic<br />
|0040 Liquid <br />
| <br />
| <br />
|Toyland; see also PLAS<br />
|-<br />
| FZDR<br />
|Fizzy Drinks<br />
|0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| align="center" colspan="6" | '''NewCargos'''<br />
|-<br />
| AORE<br />
|Bauxite (Aluminium ore)<br />
|0010 Bulk <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| BEER<br />
|Alcohol<br />
|0064 Express, piece goods, liquids <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| BDMT<br />
|Building Materials<br />
|0220 Piece goods, covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| BRCK<br />
|Bricks<br />
| 0020 Piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| CERA<br />
|Ceramics<br />
| 0020 Piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| CERE<br />
|Cereals<br />
| 0210 Bulk, covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<ref name="ecs_cargo_change" /><br />
|-<br />
| CARB<br />
|Carbon Brick<br />
|0010 Bulk <br />
| <br />
| <br />
|<br />
|-<br />
| CLAY<br />
|Clay<br />
|0210 Bulk covered/sheltered <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| CMNT<br />
|Cement<br />
| 0210 Bulk covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| COPR<br />
|Copper<br />
|0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| DURA<br />
|Depleted Uranium<br />
|0100 Hazardous <br />
| <br />
| <br />
|<br />
|-<br />
| DYES<br />
|Dyes<br />
| 0060 Piece goods, liquids <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| ENSP<br />
|Engineering Supplies<br />
|0024 Express, piece goods <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| FERT<br />
|Fertiliser<br />
| 0030 Bulk, piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<ref name="ecs_cargo_change" /><br />
|-<br />
| FICR<br />
|Fibre crops<br />
| 0030 Bulk, piece goods<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| FISH<br />
|Fish<br />
| 0084 Express, refrigerated <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| FMSP<br />
|Farm Supplies<br />
|0024 Express, piece goods <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| FRVG<br />
|Fruit (and optionally Vegetables)<br />
|00A4 Express, piece goods, refrigerated<br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| FUEL<br />
|Fuel<br />
|0040 Liquid <br />
| <br />
| <br />
|Use PETR for refined-oil fuel<br />
|-<br />
| GEAR<br />
|Locomotive regearing<br />
|8000 Special <br />
| <br />
| <br />
|<br />
|-<br />
| GLAS<br />
|Glass<br />
| 0420 Piece goods, oversized <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| GRVL<br />
|Gravel / Ballast<br />
|0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| LIME<br />
|Lime stone<br />
| 0010 Bulk <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| MATE<br />
|Materials<br />
|0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| MILK<br />
|Milk<br />
|00C4 Express, liquid, refrigerated <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| MNSP<br />
|Manufacturing Supplies<br />
|0024 Piece Goods, express <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| OLSD<br />
|Oil seed<br />
| 0210 Bulk, covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<ref name="ecs_cargo_change" /><br />
|-<br />
| OXYG<br />
|Oxygen<br />
|0040 Liquid <br />
| <br />
| <br />
|<br />
|-<br />
| PETR<br />
|Petrol / Fuel Oil<br />
| 0040 Liquid <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| PLAS<br />
|Plastic<br />
| 0060 Piece goods, liquid<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| POTA<br />
|Potash<br />
| 0210 Bulk, covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<ref name="ecs_cargo_change" /><br />
|-<br />
| RCYC<br />
|Recyclables<br />
|0220 Piece Goods, covered<br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| RCKT<br />
|Rockets<br />
|0000 None<br />
| <br />
| <br />
|<br />
|-<br />
| RFPR<br />
|Refined products<br />
| 0040 Liquid <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| RSGR<br />
|Raw Sugar<br />
|0010 Bulk <br />
| <br />
|<br />
| Deprecated in FIRS. See SGBT and SGCN<br />
|-<br />
| SAND<br />
|Sand<br />
| 0010 Bulk <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| SCRP<br />
|Scrap Metal<br />
|0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|-<br />
| SGBT<br />
|Sugar beet<br />
|0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| not in tropical<br />
|-<br />
| SGCN<br />
|Sugarcane<br />
|0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| only tropical<br />
|-<br />
| SILI<br />
|Silicate<br />
|0010 Bulk <br />
| <br />
| <br />
|<br />
|-<br />
| SULP<br />
|Sulphur<br />
| 0210 Bulk, covered/sheltered <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<ref name="ecs_cargo_change">ECS cargo classes changed as of Dec 31, 2010</ref><br />
|-<br />
| TOUR<br />
|Tourists<br />
| 0005 Passengers, express <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| TWOD<br />
|Tropic Wood<br />
|0020 Piece goods <br />
| <br />
| <br />
|<br />
|-<br />
| UORE<br />
|Uranium Ore<br />
|0110 Hazardous, Bulk <br />
| <br />
| <br />
|<br />
|-<br />
| URAN<br />
|Uranium<br />
|0100 Hazardous <br />
| <br />
| <br />
|<br />
|-<br />
| VEHI<br />
|Vehicles<br />
| 0420 Piece goods, oversized <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| <br />
|<br />
|-<br />
| WATT<br />
|Electricity<br />
|0000 None <br />
| <br />
| <br />
|<br />
|-<br />
| WDPR<br />
|Wood Products<br />
| 0030 Bulk, piece goods <br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
| <br />
|-<br />
| WOOL<br />
|Wool<br />
| 0220 Piece goods, covered/sheltered<br />
| style="background: #FFCC00; color: black" | [[ttwiki:ECS|ECS]]<br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<ref name="ecs_cargo_change" /><br />
|-<br />
| WSTE<br />
|Waste<br />
|0010 Bulk <br />
| <br />
| style="background: #1AD74C; color: white" | [[ttwiki:FIRS|FIRS]]<br />
|<br />
|}<br />
<br />
<references /></div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action4&diff=2734Action42011-10-24T19:36:32Z<p>Pm-bot: Feat 08 is 'Global Settings'</p>
<hr />
<div>==Introduction==<br />
Define strings, e.g vehicle, house or industry names<br />
<br />
When making new vehicle graphics, you also need to name the new vehicles, or they'll show up with their original name from TTD.<br />
However, custom vehicle names assigned by the player in-game (or for TTDPatch also via TTD's vehicle.dat) will always take precendence.<br />
<br />
In TTDPatch you can also use this action to change most of TTD's text strings.<br />
<br />
== Syntax ==<br />
<br />
The data looks as follows:<br />
<br />
&lt;Sprite-number&gt; * &lt;Length&gt; '''04''' &lt;feature&gt; &lt;language-id&gt; &lt;num-ent&gt; &lt;offset&gt; &lt;text&gt;<br />
<br />
{| |-<br />
!Element!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|&lt;Sprite-number&gt;||dec||A sequential sprite number<br />
|-<br />
|&lt;length&gt;||dec||The total number of bytes used in this action.<br />
|-<br />
|04||B||Defines action 04<br />
|-<br />
|&lt;feature&gt;||B||For what type of vehicle/station should this definition be used?<br />
|-<br />
|&lt;language-id&gt;||B||Which of TTD's languages this name is for<br />
|-<br />
|&lt;num-ent&gt;||B||Number of consecutive strings to change<br />
|-<br />
|&lt;offset&gt;||B/W||First ID to change<br />
|-<br />
|&lt;text&gt;||S||New text strings<br />
|}<br />
<br />
Whether &lt;offset&gt; is a '''BYTE''' (extended byte in openttd for vehicles) or a '''WORD''' is decided by bit 7 of &lt;language-id&gt;, see below.<br />
<br />
== Descriptions ==<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 [[Features|feature]] that you wish to change. Set it to:<br />
<br />
{|- |<br />
!Value!![[Features|Feature]]<br />
|-<br />
|00||Trains<br />
|-<br />
|01||Road Vehicles<br />
|-<br />
|02||Ships<br />
|-<br />
|03||Aircraft<br />
|-<br />
|04||Stations<br />
|-<br />
|07||Houses<br />
|-<br />
|0A||Industries<br />
|-<br />
|0B||Cargos<br />
|-<br />
|0D||Airports<br />
|-<br />
|0F||Objects<br />
|-<br />
|10||Railtypes<br />
|-<br />
|48||Original strings; see [[TextIDs]] for a list of TTD's text IDs.<br />
|}<br />
<br />
=== language IDs ===<br />
The meaning of this byte depends on the GRF version of the .grf file as set in [[Action8#version|action 8]].<br />
<br />
{{grf|6}} Up to version 6, this is a bit mask of the following bits:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||01||American or "other"<br />
|-<br />
|1||02||English<br />
|-<br />
|2||04||German<br />
|-<br />
|3||08||French<br />
|-<br />
|4||10||Spanish<br />
|-<br />
|7||80||Flag for 16 bit string IDs<br />
|}<br />
<br />
Add the bits of all languages for which the following strings apply. Bit 7 controls, whether the following string ID consists of 16 or 8 bit. Unknown languages will use the American strings as fallback. Otherwise the string would remain undefined for these languages. To actually define strings for any new language, you must use grf version 7.<br />
<br />
{{grf|7}} For version 7 and higher, it is a simple language ID from the list below. (This has changed with TTDPatch 2.5 beta 4). Bit 7 has the same meaning as in the earlier versions above.<br />
<br />
In either scheme, you can use the value 7F or FF, respectively, to define strings shown for languages that you do not provide translation for. First set all strings to a default value using this, and later override the language specific ones if they exist.<br />
<br />
Currently, the scheme is to use international phone codes as language IDs, unless they're out of range, in which case pick a number vaguely related in some way. Or something else.<br />
<br />
{| |-<br />
!ID (hex)!!Language!!Plural form <ref>For a list of plural forms see [[StringCodes]]. As the assignment of plural forms to languages is in fact not as fixed as one might expect, the used plural form is defined by each GRF separately for its strings using [[Action0/Global Settings]] property 15.</ref><br />
|-<br />
|00||American||0<br />
|-<br />
|01||English||0<br />
|-<br />
|02||German||0<br />
|-<br />
|03||French||2<br />
|-<br />
|04||Spanish||0<br />
|-<br />
|05||Esperanto||0<br />
|-<br />
|06||Ido||0<br />
|-<br />
|07||Russian||6<br />
|-<br />
|08||Irish||4<br />
|-<br />
|09||Maltese||12<br />
|-<br />
|0A||Tamil||0<br />
|-<br />
|0B||Chuvash||0<br />
|-<br />
|0C||Chinese (Traditional)||1<br />
|-<br />
|0D||Serbian||6<br />
|-<br />
|0E||Norwegian (Nynorsk)||0<br />
|-<br />
|0F||Welsh||0<br />
|-<br />
|10||Belarusian||6<br />
|-<br />
|11||Marathi||0<br />
|-<br />
|12||Faroese||0<br />
|-<br />
|14||Arabic (Egypt)||1<br />
|-<br />
|15||Czech||10<br />
|-<br />
|16||Slovak||10<br />
|-<br />
|18||Bulgarian||0<br />
|-<br />
|1B||Afrikaans||0<br />
|-<br />
|1E||Greek||2<br />
|-<br />
|1F||Dutch||0<br />
|-<br />
|21||Basque||0<br />
|-<br />
|22||Catalan||0<br />
|-<br />
|23||Luxembourgish||0<br />
|-<br />
|24||Hungarian||2<br />
|-<br />
|26||Macedonian||0<br />
|-<br />
|27||Italian||0<br />
|-<br />
|28||Romanian||0<br />
|-<br />
|29||Icelandic||0<br />
|-<br />
|2A||Latvian||3<br />
|-<br />
|2B||Lithuanian||5<br />
|-<br />
|2C||Slovenian||8<br />
|-<br />
|2D||Danish||0<br />
|-<br />
|2E||Swedish||0<br />
|-<br />
|2F||Norwegian (Bokmal)||0<br />
|-<br />
|30||Polish||7<br />
|-<br />
|31||Galician||0<br />
|-<br />
|32||Frisian||0<br />
|-<br />
|33||Ukrainian||6<br />
|-<br />
|34||Estonian||0<br />
|-<br />
|35||Finnish||0<br />
|-<br />
|36||Portuguese||0<br />
|-<br />
|37||Brazilian Portuguese||2<br />
|-<br />
|38||Croatian||6<br />
|-<br />
|39||Japanese||1<br />
|-<br />
|3A||Korean||11<br />
|-<br />
|3C||Malay||0<br />
|-<br />
|3E||Turkish||1<br />
|-<br />
|42||Thai||1<br />
|-<br />
|54||Vietnamese||1<br />
|-<br />
|56||Chinese (Simplified)||1<br />
|-<br />
|5A||Indonesian||1<br />
|-<br />
|5C||Urdu||0<br />
|-<br />
|61||Hebrew||0<br />
|-<br />
|62||Persian||0<br />
|-<br />
|80||Flag 16 bit string IDs (added to language ID)||<br />
|-<br />
|7F||any (will be applied no matter what language is active)||<br />
|}<br />
<br />
<references/><br />
<br />
When translating for a new language, please simply edit this document and add the new definition here.<br />
<br />
=== num-ent ===<br />
<br />
How many consecutive entries to change.<br />
<br />
=== offset ===<br />
<br />
The ID of the first string to change.<br />
<br />
When language-id bit 7 is clear, this is a byte value; For OpenTTD since r13482, where it is an extended byte value for vehicles.<br />
<br />
When language-id bit 7 is set, this is a word value in little endian notation, e.g. 8134 becomes 34 81.<br />
<br />
The 8 bit version is only allowed for vehicles to set their name, in which case the text ID is just the vehicle ID.<br />
To replace original texts, or to define texts for usage in callbacks or properties of vehicles, stations, houses or industries you have to use the 16 bit version. However, town names are changed with [[ActionF|Action F]].<br />
<br />
For the usable 16 bit text IDs see the table below, resp. for feature 48 see [[TextIDs]].<br />
<br />
Though these ranges are shared across all features, you should still set the proper feature you are using them for.<br />
<br />
{| |-<br />
!ID!!Content<br />
|-<br />
|C4xx||Set name of station class associated with station ID xx; this is the text above the preview (where otherwise TTD shows "Orientation")<br />
|-<br />
|C5xx||New station names, this changes the text "number of platforms" into the given text when the station with this ID from the current set is selected (i.e. xx=station-id from action 3 and 0)<br />
|-<br />
|C9xx||Name of the house type of this ID. If both property 12 and this is set, the latest definition is used always. You should prefer setting property 12 instead of this, so executables translated with TTD Translator will show the name in the current language. However, if you can't find any suitable old TTD texts, this can be used to specify your custom name. Don't forget to set the same text for all parts of a multi-tile building.<br />
|-<br />
|D0xx||Miscellaneous graphics texts, unique to each .grf file. Used for newobjects and several callbacks. Some callbacks as well as newobjects support IDs up to D3FF.<br />
|-<br />
|D4xx||'''Never use in Action4''', only for displaying textids in range D000-D3FF (grf specific), see [[TextIDs]]<br />
|-<br />
|D8xx||'''Never use in Action4''', only usable in Action0 features, see [[TextIDs]]<br />
|-<br />
|DCxx||Set miscellaneous persistent GRF texts. Unlike the D0xx GRF texts, these IDs can be used to set properties. The text ID must be set before any action 0 references it.<br />
|}<br />
<br />
The DCxx IDs are allocated internally when defined, and are persistent in the savegame data. Each .grf file gets its own separate map of these internal IDs and thus may set all 256 of them. &nbsp;However, only 1024 IDs are available in total, to be shared by all .grf files ever activated in the savegame. This means these IDs should be used as sparingly as possible. But use them when they are useful!<br />
<br />
=== text ===<br />
<br />
This is a list of zero-terminated strings, there must be as many strings as num-ent specifies.<br />
<br />
Grfcodec version 0.9.6 or later accepts literal strings in the .nfo. These are encoded exactly as written, in whatever encoding your text editor uses; if you need a 00, put it immediately after the literal string.<br />
For the supported encodings, format, and restrictions on what characters you may use, please see [[GRFActionsDetailed#Strings|GRFActionsDetailed]] and StringCodes.<br />
<br />
A large number of original TTD strings require a colour code in front of the actual string. You can also use these colour codes in most of your custom strings. Use them wisely! In case a string requires a colour code, the string will have the code displayed in front of the default text as listed in [[TextIDs]].Typically, a colour coded string starts with the escape character (backslash), followed by hex byte and then the actual text string itself. I.e. string 0001 ("\94Off edge of map") has colour code 0x94 in front of the text string, which will colour it white. You can also put the plain hex byte outside the quoted string without having to escape it. ''94 "Off edge of map"'' would be the same as ''"\94Off edge of map"''<br />
<br />
The following 16 colour codes are available for use:<br />
<br />
{| |-<br />
!'''Code'''!!'''Colour'''<br />
|-<br />
|88||Blue<br />
|-<br />
|89||Light Grey<br />
|-<br />
|8A||Yellow<br />
|-<br />
|8B||Red<br />
|-<br />
|8C||Light Purple<br />
|-<br />
|8D||Beige<br />
|-<br />
|8E||Light Orange<br />
|-<br />
|90||Light Yellow<br />
|-<br />
|91||Light Green<br />
|-<br />
|92||Light Pink<br />
|-<br />
|93||Brown<br />
|-<br />
|94||White<br />
|-<br />
|95||Light Blue<br />
|-<br />
|96||Grey<br />
|-<br />
|97||Purple<br />
|-<br />
|98||Black<br />
|}<br />
<br />
==Example==</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action3&diff=2733Action32011-10-24T19:36:22Z<p>Pm-bot: Feat 08 is 'Global Settings'</p>
<hr />
<div>== Introduction ==<br />
<br />
Action 3 assigns graphics sets (referenced to by (chains of) [[Action2|action 2(s]]) to feature IDs (vehicles, stations, houses, industries, ...).<br />
<br />
== Format ==<br />
<br />
The format of the data is feature-dependent.<br />
<br />
The data is:<br />
<br />
<pre> &lt;Sprite-number&gt; * &lt;Length&gt; 03 &lt;feature&gt; &lt;n-id&gt; &lt;ids...&gt; &lt;num-cid&gt; (&lt;cargo-type&gt; &lt;set-ID&gt;)... &lt;default set-ID&gt;</pre><br />
<br />
{| class="wikitable"<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 used in this action<br />
|-<br />
|03<br />
|B<br />
|Defines action 03<br />
|-<br />
|&lt;feature&gt;<br />
|B<br />
|What type of feature the IDs refer to<br />
|-<br />
|&lt;n-id&gt;<br />
|B<br />
|Number of IDs this action 3 associates graphics with<br />
|-<br />
|&lt;ids...&gt;<br />
|B/B*<br />
|IDs of the current feature this action 3 associates graphics with. There must be as many IDs as &lt;n-id&gt; specifies<br />
|-<br />
|&lt;num-cid&gt;<br />
|B<br />
|Number of different cargo types to support<br />
|-<br />
|&lt;cargo-type&gt;<br />
|B<br />
|Cargo type for which to use the following set-ID<br />
|-<br />
|&lt;set-ID&gt;<br />
|W<br />
|Set-ID (from action 2 or from a varaction2 chain) to use for this cargo type<br />
|-<br />
|&lt;default set-ID&gt;<br />
|W<br />
|Default set-ID to use if none of the above matches<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 [[Features|feature]] that you wish to change. Set it to:<br />
<br />
{|- |<br />
!Value!![[Features|Feature]]<br />
|-<br />
|00||Trains<br />
|-<br />
|01||Road Vehicles<br />
|-<br />
|02||Ships<br />
|-<br />
|03||Aircraft<br />
|-<br />
|04||Stations<br />
|-<br />
|05||[[Action3/Canals|Canals/Rivers]]<br />
|-<br />
|07||Houses<br />
|-<br />
|09||Industry Tiles<br />
|-<br />
|0A||Industries<br />
|-<br />
|0B||Cargos<br />
|-<br />
|0C||Sound Effects (generic callback only)<br />
|-<br />
|0D||Airports<br />
|-<br />
|0E||Signals (generic callback only)<br />
|-<br />
|0F||Objects<br />
|-<br />
|10||[[Action3/Railtypes|Railtypes]]<br />
|-<br />
|11||Airport Tiles<br />
|}<br />
<br />
=== n-id ===<br />
<br />
How many items of the current feature this action 3 defines new graphics for. If this is more than one, all items listed will get the same graphics. If this value has bit 7 set (i.e. 80 added), it is a wagon override. See [[Action3LiveryOverride|Action 3 - Livery Override]] for more info on this feature.<br />
<br />
You can make a definition with n-id equal to zero (and thus no ids that follow). &nbsp;This creates a generic feature-specific definition not associated with any particular item. &nbsp;At the moment, this is used for generic callbacks, but might be extended to other functions eventually.<br />
<br />
=== ids ===<br />
<br />
Feature IDs to use this action 3 for. All IDs are counted from the first of their class, i.e. the first road vehicle has 00, as does the first plane, the first ship, and the first train vehicle.<br />
<br />
In OpenTTD since r13482, each ID is an extended byte for vehicles, otherwise the ID is a regular byte.<br />
<br />
For canals and rivers the id has a special meaning, see its [[Action3/Canals|own Action 3 page]]<br />
<br />
For town buildings, the IDs are the house IDs, and specifying a house ID that haven't been defined before (by setting its property 08) doesn't do anything, but doesn't cause an error, either. Note that you don't necessarily have to assign a set-ID to a house ID, the old TTD sprite of the substitute type will be used if you don't do so. &nbsp;Industry tile IDs work in the same manner.<br />
<br />
=== num-cid ===<br />
<br />
Number of cargo type definitions that follow. Can be zero if only the default follows.<br />
<br />
For features 05 (canals/rivers), 07 (houses), 09 (industry tiles), 0A (industries), and 0B (cargoes) this must always be zero.<br />
<br />
=== cargo-type ===<br />
<br />
<u>For vehicles (features 00 .. 03) and stations (feature 04)</u><br />
<br />
The cargo-type for which the set-ID applies. &nbsp;If the item is built to use this type of cargo, or if it is refitted for it, the given set-ID is used as its graphics. &nbsp;See column "type A" in the table at [[CargoTypes]] for a list of cargo-type values.<br />
<br />
If the grf file has installed a [[Action0/Global Settings#Cargo translation table 09|cargo translation table]], the cargo type here refers to the cargo with the label in the given slot of the translation table, e.g. if you use cargo-type=08, it refers to the cargo that has the label in the ninth slot (numbered 08) in the translation table.<br />
<br />
If defined, cargo-type FF is used for graphics shown in the purchase or construction window.<br />
<br />
For stations, you can additionally define a special cargo-type of FE which prevents the default from being used (which would show the sum of all cargo). &nbsp;Instead, the given set-ID is displayed with no cargo at all.<br />
<br />
<u>Railtypes are available only in OpenTTD &gt; r19056 and its action 3 re-uses the 'cargo'-type definition.</u><br />
<br />
For details see its [[Action3/Railtypes|own Action 3 page]]<br />
<br />
<u>For canals/rivers, houses, industry tiles, industries and cargoes (features 05, 07, 09, 0A and 0B)</u><br />
<br />
As &lt;num-cid&gt; is zero for features 05 (canals/rivers), 07 (houses), 09 (industry tiles), 0A (industries), and 0B (cargoes), &lt;cargo-type&gt; and &lt;set-ID&gt; need to be skipped and you only have to set &lt;default set-ID&gt;.<br />
<br />
<u>For objects (feature 0F)</u><br />
<br />
Objects support a buy menu sprite similar to vehicles (cargo-type FF).<br />
<br />
=== default set-ID ===<br />
<br />
Default set-ID if no entry from the cargo-type list above matches, or if there are no special cargo-types listed at all.<br />
<br />
== Example ==<br />
<br />
Below is an example of what a real action 3 pseudo-sprite could look like for a train engine.<br />
<br />
<pre> 13 * 7 &nbsp; 03 00 01 02 00 00 00</pre><br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Byte'''<br />
!'''Meaning'''<br />
|-<br />
|13<br />
|&lt;sprite-number&gt;<br />
|-<br />
|7<br />
|&lt;length&gt; of the action in bytes; start counting at 03 (&lt;action&gt;)<br />
|-<br />
|03<br />
|&lt;action&gt;: sets this pseudo-sprite to function as action 3<br />
|-<br />
|00<br />
|&lt;feature&gt;: 00 for trains<br />
|-<br />
|01<br />
|&lt;n-id&gt;: One ID to change in this case<br />
|-<br />
|02<br />
|&lt;ids...&gt;: vehicle ID (02 - Ploddyphut Choo-Choo)<br />
|-<br />
|00<br />
|&lt;num-cid&gt;: this engine doesn't have cargo-specific graphics<br />
|-<br />
|00 00<br />
|&lt;default set-ID&gt;: Use action 2 ID 00, because it is a word value you add 00<br />
|}</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Railtypes&diff=2732Action0/Railtypes2011-10-24T19:36:12Z<p>Pm-bot: Feat 08 is 'Global Settings'</p>
<hr />
<div>'''''Action 0 properties for rail types'''''<br />
<br />
= Action 0 - Properties for rail types =<br />
<br />
Defining properties of rail types.<br />
<br />
Note: This feature is only available in OpenTTD &gt; r18969<br />
<br />
== Properties ==<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Number'''<br />
!'''Version'''<br />
!'''Size'''<br />
!'''Description'''<br />
|-<br />
|08<br />
|{{ottdp|1.0}}<br />
|4*B<br />
|Rail type label<br />
|-<br />
|09<br />
|{{ottdp|1.0}}<br />
|W<br />
|StringID: Build rail toolbar caption<br />
|-<br />
|0A<br />
|{{ottdp|1.0}}<br />
|W<br />
|StringID: Rail construction dropdown text<br />
|-<br />
|0B<br />
|{{ottdp|1.0}}<br />
|W<br />
|StringID: Build vehicle window caption<br />
|-<br />
|0C<br />
|{{ottdp|1.0}}<br />
|W<br />
|StringID: Autoreplace text<br />
|-<br />
|0D<br />
|{{ottdp|1.0}}<br />
|W<br />
|StringID: New engine text<br />
|-<br />
|0E<br />
|{{ottdp|1.0}}<br />
|B n*D <br />
|Compatible rail type list<br />
|-<br />
|0F<br />
|{{ottdp|1.0}}<br />
|B n*D <br />
|Powered rail type list<br />
|-<br />
|10<br />
|{{ottdp|1.0}}<br />
|B<br />
|Rail type flags<br />
|-<br />
|11<br />
|{{ottdp|1.0}}<br />
|B<br />
|Curve speed advantage multiplier<br />
|-<br />
|12<br />
|{{ottdp|1.0}}<br />
|B<br />
|Station (and depot) graphics<br />
|-<br />
|13<br />
|{{ottdp|1.0}}<br />
|W <ref>In r18969 to 19306 this property was byte-sized.</ref><br />
|Construction costs<br />
|-<br />
|14<br />
|{{ottdp|1.0}}<br />
|W<br />
|Speed limit<br />
|-<br />
|15<br />
|{{ottdp|1.0}}<br />
|B<br />
|Acceleration model<br />
|-<br />
|16<br />
|{{ottdp|1.0|no|ottdrev=r19307}}<br />
|B<br />
|Minimap colour<br />
|-<br />
|17<br />
|{{ottdp|1.1|no|ottdrev=r21842}}<br />
|D<br />
|Introduction date<br />
|-<br />
|18<br />
|{{ottdp|1.1|no|ottdrev=r21842}}<br />
|B n*D <br />
|Introduction required rail type list<br />
|-<br />
|19<br />
|{{ottdp|1.1|no|ottdrev=r21841}}<br />
|B n*D <br />
|Introduced rail type list<br />
|-<br />
|1A<br />
|{{ottdp|1.1|no|ottdrev=r21866}}<br />
|B<br />
|Sort order<br />
|}<br />
<br />
<references /><br />
<br />
In NFO, rail type IDs will be GRF local, with an ID to label mapping. Therefore to modify an existing rail type, specify its label in property 08. To create a new rail type, again just specify its label in property 08. This way there is no need for complex GRM mechanisms to allocate IDs. If a label 'clashes' with another GRF, then one GRF will end up modifying the properties instead of creating a new rail type.<br />
<br />
When a new rail type is created, it is populated with the information from the first rail type, except that the compatible and powered list contain only the rail type being created. However, no default values should be assumed, as the first rail type may have been modified.<br />
<br />
== Comments ==<br />
<br />
== Rail type label (08) ==<br />
<br />
These are globally unique four-letter identifiers for specific rail types (analoguous to [[Action0Cargos#Cargo label 17|cargo labels]]), used to make various rail types accessible from train vehicle grfs. Reserved labels for default rail types are:<br />
<br />
{| class="wikitable<br />
|-<br />
!'''Label'''<br />
!'''Rail Type'''<br />
|-<br />
|RAIL <br />
| Normal Rail<br />
|-<br />
|ELRL <br />
| Electrified Rail<br />
|-<br />
|MONO <br />
| Mono Rail<br />
|-<br />
|MGLV <br />
| Maglev Rail<br />
|}<br />
<br />
Rail type sets may use up to 16 railtypes and have to specify their own [[RailtypeLabels|labels]].<br />
<br />
See also [[Action0/Global Settings#Rail type translation table 12|Rail Type Translation Table]] for further info.<br />
<br />
== Build rail toolbar caption (09) ==<br />
<br />
String ID of the name of the rail type as shown in the toolbar caption.<br />
<br />
OpenTTD before r20342 and 1.0.3 require the string to start with the white control code. Later versions of OpenTTD will automatically default to white.<br />
<br />
== Rail construction dropdown text (0A) ==<br />
<br />
String ID for text in the dropdown of all rail types.<br />
<br />
This string must never start with a colour control code.<br />
<br />
== Build vehicle window caption (0B) ==<br />
<br />
String ID for build vehicle window caption.<br />
<br />
OpenTTD before r20342 and 1.0.3 require the string to start with the white control code. Later versions of OpenTTD will automatically default to white.<br />
<br />
== Autoreplace text (0C) ==<br />
<br />
String ID for rail type shown in autoreplace window.<br />
<br />
== New engines (0D) ==<br />
<br />
StringID to use for showing texts of the type "We have invented a new &lt;rail type&gt; engine".<br />
<br />
== Compatible rail type list (0E) ==<br />
<br />
List of rail types on which trains of this rail type can run, even though they might not be powered. E.g. wagons/engines of "eletrified rail"-type are also compatible to "normal rail" and "third rail" type, but they are not powered (there need to be an other powered engine in the consist to move the train).<br />
<br />
The format is:<br />
<br />
<pre>0E &lt;nvar&gt; (&lt;rail type label&gt;){n}</pre><br />
<br />
That is you give the number of compatible rail types in a single byte followed by a list of that length of rail type labels. A rail type is automatically compatible (and powered) with itself, so you don't need to list the current rail type.<br />
<br />
Note that these properties apply to trains of this rail type, not the track. If you want trains of other rail types to be able to run on your rail types, you must set the compatible rail types property for each rail type. Setting these properties behaves always incremental, so you only need to the set additional bits for each other rail type, you cannot remove compatibility/poweredness once it is set (by some other grf).<br />
<br />
== Powered rail type list (0F) ==<br />
<br />
List of rail types on which trains of this rail type are powered. E.g. engines of "normal rail"-type are powered on "electrified rail"- and "third-rail"-type as well.<br />
<br />
Same format as for property 0E above.<br />
<br />
== Rail type flags (10) ==<br />
<br />
Flags to define properties related to the rail type:<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Bit'''<br />
!'''Value'''<br />
!'''Version'''<br />
!'''Meaning'''<br />
|-<br />
|0<br />
|1<br />
||{{ottdp|1.0}}<br />
|Draw catenary for this rail<br />
|-<br />
|1<br />
|2<br />
||{{ottdp|1.1|no|ottdrev=r20049}}<br />
|Disallow level crossings for this rail<br />
|}<br />
<br />
== Curve Speed advantage multiplier (11) ==<br />
<br />
This property sets the multiplier to the curve speed advantage which all trains running on this track type get. The base curve speed advantage is given by the multiplication of the value of this property with the base speed advantage - which depends on the curve length in wagons:<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Curve Length'''<br />
!'''Base Speed Adv.'''<br />
|-<br />
|0 (90° turn) <br />
|30<br />
|-<br />
|1 (2x45° turn) <br />
|44<br />
|-<br />
|2<br />
| 55<br />
|-<br />
|3<br />
| 66<br />
|-<br />
|4<br />
| 75<br />
|-<br />
|5<br />
| 84<br />
|-<br />
|6<br />
| 91<br />
|-<br />
|7<br />
| 98<br />
|-<br />
|8<br />
| 103<br />
|-<br />
|9<br />
| 108<br />
|-<br />
|10<br />
| 111<br />
|-<br />
|11<br />
| 114<br />
|-<br />
|12+<br />
| 115<br />
|}<br />
<br />
"Curve length" is the average number of wagons of the train between turns. However, very sharp turns (values 0 and 1) are not averaged out in longer trains.<br />
<br />
The maximum speed for a train in a curve is defined by "base speed advantage" * (2 + "property 11"). Tilting trains get an additional bonus of 20% to this value.<br />
<br />
For the default rail types this property is 0 for normal rail and electrified rail, 1 for monorail, and 2 for maglev.<br />
<br />
== Station (and depot) graphics (12) ==<br />
<br />
This property defines the default graphics for the stations. If no depot sprites are defined, this also defines at the same time the depot sprites to be used. There are three kind of default stations (and depots), usually associated with rail, monorail and maglev tracks. Valid values are:<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Value'''<br />
!'''Meaning'''<br />
|-<br />
|0<br />
|Normal Rail<br />
|-<br />
|1<br />
|Monorail<br />
|-<br />
|2<br />
|Maglev<br />
|}<br />
<br />
== Speed limit (14) ==<br />
<br />
Speed limit in mph*1.6 (approx. km/h). Set to "0" for no limit at all.<br />
<br />
== Acceleration model (15) ==<br />
<br />
This property defines the acceleration model used. Valid values range from 0 to 2:<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Value'''<br />
!'''Meaning'''<br />
|-<br />
|0<br />
|Normal Rail<br />
|-<br />
|1<br />
|Monorail<br />
|-<br />
|2<br />
|Maglev<br />
|}<br />
<br />
There is currently no difference between normal rail and monorail.<br />
<br />
== Map colour (16) ==<br />
<br />
This property defines the colour this track type is drawn in the minimap view. The byte value specifies the colour entry in the [[PalettesAndCoordinates|DOS palette]].<br />
<br />
== Introduction date (17) ==<br />
<br />
This property defines the long date formatted introduction date of this rail type. With this property set the rail type will be introduced at (or after) this date when all of the introduction required rail types are available to the company of the player, or whenever a vehicle using this rail type gets introduced whichever is first.<br />
<br />
== Introduction required rail type list (18) ==<br />
<br />
List of rail types on that need to be available to the company of the player for this rail type to be introduced at (or after) the introduction date. This limit does not apply when the rail type is introduced by the introduction of a vehicle.<br />
<br />
Same format as for property 0E above.<br />
<br />
This can, for example, be used to introduce a third rail with catenary track type when both third rail and catenary rail types are available.<br />
<br />
== Introduced rail type list (19) ==<br />
<br />
List of rail types that get introduced when this rail type is introduced. For example, to make sure that when a fast rail type is introduced the slow variant exists.<br />
<br />
Same format as for property 0E above.<br />
<br />
== Sort order (1A) ==<br />
<br />
Property for influencing the sort order of the drop down lists with rail types. Default values are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
!'''Value'''<br />
!'''Meaning'''<br />
|-<br />
|07<br />
|Normal Rail<br />
|-<br />
|17<br />
|Electrified Rail<br />
|-<br />
|27<br />
|Monorail<br />
|-<br />
|37<br />
|Maglev<br />
|-<br />
|n7<br />
|Railtype #n<br />
|}<br />
<br />
Thus the rail type that (internally) gets index 8 will get a default value of 87. These defaults are to keep the ordering when this property is not supported as they were.<br />
<br />
= Example =<br />
<br />
To be written</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Vehicles&diff=1811VariationalAction2/Vehicles2011-06-19T16:34:05Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
== Variables ==<br />
<br />
{|<br />
!Variable!!Version!![[GRFActionsDetailed|Size]]!!Description!!Available in purchase list<br />
|+<br />
|40||||D||Position in consist and length of consist||no<br />
|+<br />
|41||||D||Position in and length of chain of consecutive vehicles with same ID||no<br />
|+<br />
|42||||D||Cargo types transported by consist||no<br />
|+<br />
|43||||D||Player info||TTDPatch 2.5 beta 2, OpenTTD r4611<br />
|+<br />
|44||||D||Aircraft info||no<br />
|+<br />
|45||||D||Curvature info||no<br />
|+<br />
|46||||D||Motion counter||no<br />
|+<br />
|47||||D||Vehicle cargo info||(b) OpenTTD r15542<br />
|+<br />
|48||||D||Vehicle type information||TTDPatch 2.5 beta 2, OpenTTD r5338<br />
|+<br />
|49 (a)||||D||Year of construction (long format, 0 based)||(c) OpenTTD r13376<br />
|+<br />
|4A (d)||||D||Info about current rail type for trains||no<br />
|+<br />
|60||||D||Count Veh.ID occurence||no<br />
|+<br />
|97||||B||Tick counter, increased every engine tick||no<br />
|+<br />
|B4||||W||Current speed. Note, units differ for each vehicle type (e).||no<br />
|+<br />
|B9||||B||Cargo type (type B from the list at [[CargoTypes]]; climate dependent)||no<br />
|+<br />
|C0||||W||Vehicle age in days (not valid for wagons bought before alpha 61)||no<br />
|+<br />
|C4||||B||Year built (counted from 1920), note this is modified when Cht: Year is used||(c) OpenTTD r4611<br />
|+<br />
|C6||||W||Vehicle type ID (useful for [[Callbacks#Can wagon be attached (1D)|Callback 1D]])||no<br />
|+<br />
|C8||||B||Sprite type; FD for trains forward, FE or FF when reversed||no<br />
|+<br />
|C9||||B||Day counter; increased daily||no<br />
|+<br />
|DA||||W||Next wagon index, FFFF if last wagon (use shift-num=08 and check for FF)||no<br />
|+<br />
|F2||||B||Refit cycle, how many times refitted to the same cargo type||(b) OpenTTD r15542<br />
|+<br />
|FE||||W||Modflags||no<br />
|+<br />
|FF||||B||Modflags||no<br />
|}<br />
<br />
(a) OpenTTD r13376, TTDPatch r2216<br />
<br />
(b) Variable 47 refers to the default cargo of the vehicle, when in purchase list. This differs from the cargo used in Action 3, which is 0xFF in purchase list. The "refit cycle" (F2) is currently always zero in the purchase list.<br />
<br />
(c) This is the current date.<br />
<br />
(d) OpenTTD r20165.<br />
<br />
(e) See [[Action0Trains#Speed 09|train property 09]], [[Action0RoadVehicles|road vehicle property 08]] (not 15, even when using realistic acceleration), [[Action0Ships|ship property 0B]] and [[Action0Planes|aircraft property 0C]].<br />
<br />
For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_VehicleArray|TTD vehicle structure].<br />
<br />
Variables 40, 41, 42 and 43 are cached. This means that while they are in principle computationally expensive, they can be used without impacting performance. Variables 45 and 60 are also computationally expensive but cannot be cached, and should therefore be used sparingly. If possible 80+x variables are to be preferred.<br />
<br />
Cached variables are updated when the game is loaded, when the consist enters or is rearranged in a depot, and when the train reverses.<br />
<br />
In the purchase list only a few variables are available. Especially the front vehicle (related object) cannot be accessed, nor other articulated parts.<br />
<br />
== Description ==<br />
=== Position and length (40, 41) ===<br />
<br />
'''Format:''' 00nnbbff<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|ff||position of vehicle within the consist counted from the engine (front), e.g. the engine would have ff=0, the 1st wagon or mail compartment of planes would have ff=1, the 2nd wagon or the rotor of helicopters would have ff=2, the 3rd wagon would have ff=3 etc<br />
|-<br />
|bb||same as ff, but counted from the end, i.e. the last wagon has bb=0, the next-to-last wagon has bb=1 etc.<br />
|-<br />
|nn||total number of vehicles in the consist minus one (i.e. a train with engine and three wagons has nn=3), including shadow and rotor for aircraft.<br />
|}<br />
<br />
For variable 40, these numbers refer to the whole consist, but for variable 41, they only refer to the chain of consecutive vehicles with the same ID as the current wagon (including itself, but possibly excluding the engine):<br />
<br />
[[File:vehicle_var40_41.png]]<br />
<br />
Note however, that accessing the "related" object (i.e. the locomotive) doesn´t make much sense for vars 40/41, except for var40 when in a [[Callbacks#Can wagon be attached 1D|callback 1D]] chain.<br />
<br />
=== Consist cargo (42) ===<br />
<br />
'''Format:''' uuiicctt<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|tt||a bit mask of all [[Action0Cargos#Cargo classes 16|cargo classes]] transported by the consist<br />
|-<br />
|cc||the most common [[CargoTypes|cargo type]] (from the column for type A)<br />
|-<br />
|ii||the most common refit cycle (var. F2) of cargo type cc<br />
|-<br />
|uu||the result of ORing the bits of prop. 25 from all vehicles in the train<br />
|}<br />
<br />
Note that even if the grf file has installed a [[Action0GeneralVariables#Cargo+translation+table+(09)|cargo translation table]], the value in "cc" is the actual bit number of that cargo. The reason for this is that it cannot be translated in general, because different vehicles can be from different .grf files and have different translation tables. Use variable 47 if you want the translated cargo type.<br />
<br />
If used with VarAction2 type 81 (vehicle) it returns only cargo from this vehicle on, with type 82 (engine) that of the whole consist.<br />
<br />
=== Player info (43) ===<br />
<br />
'''Format:''' Ccttmmnn<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|nn||the number of the current player from 0 to 7 (up to E (14) in OpenTTD since r14735)<br />
|-<br />
|mm||the multiplayer player number with the host player (or the single player) being 0 and the client player being 1<br />
|-<br />
|tt||the player type, see below for possible values<br />
|-<br />
|c||the primary player colour<br />
|-<br />
|C||the secondary player colour, equal to c if none (since r1405)<br />
|}<br />
<br />
<br />
{| |-<br />
!tt value!!Meaning<br />
|-<br />
|0||Player is human player (permanent company)<br />
|-<br />
|1||Player is AI player (not managed)<br />
|-<br />
|2||Player is a human managing an AI company<br />
|-<br />
|3||Player is human player's original company, now temporarily AI controlled<br />
|}<br />
<br />
This variable is available in the purchase list as well (since TTDPatch 2.5 beta 2).<br />
<br />
Since r1497, when the vehicle sprite is being displayed in an exclusive offer window or new vehicle news message, or in other circumstances when no player is associated with the vehicle, nn will be FF.<br />
<br />
=== Aircraft info (44) ===<br />
<br />
'''Format:''' xxxxhhtt<br />
<br />
(available from TTDPatch 2.0.1 alpha 48)<br />
<br />
hh is the height of the aircraft above ground, or more properly above the height of its shadow. Buildings, including the heliport, don't count as "ground", i.e. to get the height above a heliport, you have to subtract the heliport height from hh.<br />
<br />
tt is the type of the current airport: 0=small, 1=large, 2=heliport, 3=oil rig. The current airport is the target airport for aircraft that have finished the ascent and are in flight.<br />
<br />
=== Curvature info (45) ===<br />
<br />
'''Format:''' xxxTxBxF<br />
<br />
(available from TTDPatch 2.0.1 alpha 58)<br />
<br />
This returns the amount of curvature between the adjacent wagon pairs. It is useful for train vehicles that normally tilt in curves. The curvature is the difference in direction between the surrounding vehicles:<br />
<br />
F = for the front pair (previous wagon to current wagon, 0 if vehicle is first)<br />
<br />
B = for the back pair (current wagon to next wagon, 0 if wagon is last)<br />
<br />
T = for the triplet (previous wagon to next wagon; is zero in an S-bend)<br />
<br />
Possible values:<br />
<br />
{| |-<br />
!Decimal!!Hex!!Meaning<br />
|-<br />
|-4||C||180° curve left (T only)<br />
|-<br />
|-3||D||135° curve left (T only)<br />
|-<br />
|-2||E||90° curve left<br />
|-<br />
|-1||F||45° curve left<br />
|-<br />
|0||0||no curve<br />
|-<br />
|1||1||45° curve right<br />
|-<br />
|2||2||90° curve right<br />
|-<br />
|3||3||135° curve right (T only)<br />
|-<br />
|4||4||180° curve right (T only)<br />
|}<br />
<br />
=== Motion counter (46) ===<br />
<br />
'''Format:''' 32-bit value<br />
<br />
(available from TTDPatch 2.0.1 alpha 59)<br />
<br />
This variable counts the amount of motion that a vehicle has done. &nbsp;It is only valid for the first vehicle in a consist (i.e. use VarAction2 type 82!). &nbsp;Its value is in units of 1/4096 of a tile. &nbsp;A vehicle actually moves visibly every time the motion counter increases by 256, and since a tile consists of 16 such subunits, 16*256=4096 motion units mean motion across one tile.<br />
<br />
The most useful way to access it is probably with &lt;shiftnum&gt;=08 and an appropriate &lt;andmask&gt;. &nbsp;For example, to achieve an animation with one frame per vehicle motion and 16 frames in total for motion across an entire tile, you would use &lt;shiftnum&gt;=08 and &lt;andmask&gt;=0F. &nbsp;For an animation with one frame every two vehicle motions and 4 frames total, use &lt;shiftnum&gt;=09 and &lt;andmask&gt;=03.<br />
<br />
If the vehicle is going very fast (&gt;160 mph for trains), it may move by several 1/16ths of a tile at once, and thus some frames may be skipped, but the animation will still remain in sync with the motion.<br />
<br />
Note that vehicle graphics are only updated every time the vehicle actually moves, so checking the lower byte is probably pointless, and only needed internally to achieve sufficient precision.<br />
<br />
=== Vehicle cargo info (47) ===<br />
<br />
'''Format:''' ccccwwtt<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|tt||the [[CargoTypes|cargo type]] transported by the vehicle (from the column for type A); translated if a translation table has been installed<br />
|-<br />
|ww||cargo unit weight in 1/16 tons, same as [[Action0Cargos#Weight of one unit of the cargo 0F|cargo prop. 0F]]<br />
|-<br />
|cccc||the [[Action0Cargos#Cargo classes 16|cargo class]] value of the cargo transported by the vehicle<br />
|}<br />
|-<br />
|Note that if the grf has installed a [[Action0GeneralVariables#Cargo translation table 09|cargo translation table]], the value in "tt" is the slot number in that table, irrespective of which actual slot or bit the cargo is using in the game. If a table has been installed, but the current cargo is not listed there, "tt" will be set to FF.<br />
<br />
Unlike variable 42, this variable returns the info of the current vehicle only, not the consist.<br />
<br />
=== Vehicle type information (48) ===<br />
<br />
'''Format:''' xxxxxxff<br />
<br />
The bits of ff are:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||Vehicle type is available on the market<br />
|-<br />
|1||2||Vehicle type is in the testing phase<br />
|-<br />
|2||4||Exclusive testing offer for a human player active<br />
|}<br />
<br />
All other bits in ff are undefined and must be masked out.<br />
<br />
This variable is available in the purchase list as well (since TTDPatch 2.5 beta 2).<br />
<br />
=== Information about current rail type for trains (4A) ===<br />
<br />
'''Format:''' xxxxFFrr<br />
<br />
(available from OpenTTD r20165)<br />
<br />
The lower byte (rr) contains the (translated) rail type the train vehicle is currently driving on. If the rail type has no entry in the rail type translation table of the GRF, this value will be 0xFF. If no translation table is present, the raw value will be returned.<br />
<br />
The next byte (FF) contains the following flags:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||The vehicle is/would be powered on the current rail type (this is independent from powered/non-powered wagon or anything)<br />
|}<br />
<br />
All other bits are undefined.<br />
<br />
All other bytes and the result for non-rail vehicles are undefined.<br />
<br />
=== Count Veh.ID occurence (60) ===<br />
<br />
'''Format:''' xxxxxxnn<br />
<br />
(available from TTDPatch 2.0.1 alpha 57)<br />
<br />
The 60+x parameter is the vehicle ID to look for, and the returned nn is the number of vehicles in the consist that have this ID. If used with VarAction2 type 81, only the current vehicle and onwards will be check, with VarAction2 type 82, all vehicles in the consist will be counted.<br />
<br />
=== Modflags (FE and FF) ===<br />
<br />
The bits in FE mostly relate to gradualloading. &nbsp;A few useful bits for grf authors are;<br />
<br />
{| |-<br />
!Bit!!Value of the bit<br />
|-<br />
|5||Vehicle is powered (engine or powered wagon, mainly useful for the latter)<br />
|-<br />
|6||Vehicle would be powered (engine or powered wagon) if there were suitable track. (E.g. electric train in mixed train on normal track)<br />
|-<br />
|8 *||This bit is flipped every time the train reverses direction<br />
|-<br />
|10||Vehicle was built during the exclusive preview (since TTDPatch 2.5 r1334)<br />
|}<br />
<br />
<nowiki>*</nowiki> This bit is only accurate for the first vehicle in the consist.<br />
<br />
variable FF is actually the high byte of variable FE, so FE bit 8 is the same as FF bit 0.<br />
<br />
==Examples==</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Signals&diff=1810VariationalAction2/Signals2011-06-19T16:34:01Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
This is available from TTDPatch 2.6 alpha 0 r1247 onwards.<br />
<br />
This type of VarAction2 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>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Industries&diff=1809VariationalAction2/Industries2011-06-19T16:33:57Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</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 [[TownZones|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 TTDPatch 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 TTDPatch 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, TTDPatch 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 [[TownZones|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 [[TownZones|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|VarAction2]]) 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 TTDPatch 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>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Houses&diff=1808VariationalAction2/Houses2011-06-19T16:33:55Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
== Variables ==<br />
<br />
{| |-<br />
!Variable!!Version*!![[GRFActionsDetailed|'''Size''']]!!Description<br />
|-<br />
|40|| ||B||Construction stage and pseudo-random values<br />
|-<br />
|41|| ||B||Age of the building in years (or, strictly speaking, the difference between the current year and the year the building was built). Returns 255 for buildings older than 255 years.<br />
|-<br />
|42||2.0.1a43||B||Town zone where the building is situated.<br />
|-<br />
|43|| ||B||Terrain type: 0 normal, 1 desert, 2 rainforest, 4 on or above snowline<br />
|-<br />
|44||2.0.1a43||D||Building counts<br />
|-<br />
|45||2.0.1a38||B||Town expansion bits<br />
|-<br />
|46||2.0.1a67||B||Current animation frame<br />
|-<br />
|47||2.6r2020 / r14294||D||XY Coordinate of the building<br />
|-<br />
|60||2.0.1a56||D||Other building counts<br />
|-<br />
|61||2.0.1a56||D||Other building counts<br />
|-<br />
|62||2.0.1a72||D||Land info for nearby tiles<br />
|-<br />
|63||2.6r1665||B||Current animation frame of nearby house tiles<br />
|-<br />
|64||2.6r1672||B||Cargo acceptance history of nearby stations<br />
|-<br />
|65||2.6r2242 / r13603||B||Distance of nearest house matching a given criterion<br />
|-<br />
|66||2.6r2246||D||Class and ID of nearby house tile<br />
|-<br />
|67||2.6r2246||D||GRFID of nearby house tile<br />
|-<br />
|80+x||||||None defined, and none ever will because town buildings don't have an internal structure. Trying to access these variables crashes TTD.<br />
|}<br />
<br />
<nowiki>*</nowiki> Specified version is earliest known to support the variable in its current form. Some variables may have been available earlier.<br />
<br />
== Description ==<br />
<br />
=== Construction stage and pseudo-random values (40) ===<br />
<br />
{| |-<br />
!Bits!!Meaning<br />
|-<br />
|0..1||Construction state: 0..2: various states of construction, 3: construction finished<br />
|-<br />
|2..3||A pseudo-random value. It isn't actually random, but is derived from the position of the building. Old buildings use this value to randomize their colors. TTDPatch has a better way to randomize things, but you can still use that value to mimic unpatched TTD behaviour. Note that adjacent tiles aren't guaranteed to have the same pseudo-random bits<br />
|}<br />
<br />
=== Town zone (42) ===<br />
<br />
Town zone where the building is situated. The value is between 0 and 4, where 0 is the outermost zone of the town. Smaller towns have fewer zones. Roads are plain in zone 0 and 1, paved in zone 2, have trees in zone 3 and streetlights in zone 4<br />
<br />
=== Building counts (44) ===<br />
<br />
Returns dword LLllCCcc, where cc means how many buildings of the current type can be found in the current town, while CC is the same for the whole map. ll and LL are similar to cc and CC, but contain the number of tiles that have the same class as the current one. For tiles that have no class, ll and LL are always zero. Overridden old types are considered to be the new type they were overridden with. During [[Callbacks#House construction check (17)|callback 17]], the current building isn't on the map yet, and therefore isn't counted. In other cases, the building count is at least one, since the current building is counted as well.<br />
<br />
=== Town expansion bits (45) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||Set if TTD is currently creating a random town, clear otherwise. PLEASE NOTE: while TTD is generating a random town, town variables 82 (town population) and B6 (number of buildings) are incorrect. The population counter contains the population of buildings generated _yet_, which means the final value may be larger than you get. The building count variable, on the other hand, is surely higher than the final value will be. If you want to check these variables during [[Callbacks#House construction check (17)|callback 17]], you may need to check variable 45 as well and make adjustments if this bit is set.<br />
|}<br />
<br />
Other bits are currently reserved for future use.<br />
<br />
=== Current animation frame (46) ===<br />
<br />
The current animation frame being displayed. If you don't use animation callbacks, it's between zero and the value set in property 1A. Animation callbacks can set this to anything between 0 and 127.<br />
<br />
Enabling animation on a house tile by setting properties 9, 1A and probably 1B ensures that property 46 will indeed change with time, and the building is redrawn every time property 46 changes. This means that you can use a VarAction2 to choose the current frame according to property 46. Please note that this kind of animation needs more CPU time and more sprites, so you should prefer palette animation if possible.<br />
<br />
=== XY Coordinate of the building (47) ===<br />
<br />
The coordinate of the tile this part of the building is located. &nbsp;If the building is not yet constructed, like during [[Callbacks#House construction check (17)|callback 17]], the returned value will be the proposed location. &nbsp;The format of the var is YYYYXXXX.<br />
<br />
=== Other building counts (60, 61) ===<br />
<br />
For variable 60, the parameter is an old house type number. For variable 61, it is a new house type number defined in the current GRF file.<br />
<br />
These variables work like variable 44, but they count the given house type instead of the current one.<br />
<br />
Please note that, unlike random graphics, changes of deterministic building graphics don't automatically redraw the building (except when either the construction state or property 46 changes), resulting in temporary graphics glitches when a visible building changes its graphics. These glitches can be fixed by scrolling the building out of view, then back again.<br />
<br />
=== Land info for nearby tiles (62) ===<br />
<br />
This variable works exactly like [[VarAction2IndustryTiles#Land info of nearby tiles 60|var. 60 for industry tiles]], except that bit 0 of the '''bb''' part is undefined.<br />
<br />
=== Current animation frame of nearby house tiles (63) ===<br />
<br />
The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7, 8h=8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. Although you can query a 16x16 area with these parameters, it's currently useless to use offsets other than -1, 0 and +1; if you query a tile that doesn't belong to the same building as the current tile, the result is meaningless. It may even be junk if the queried tile isn't a house tile at all.<br />
<br />
=== Cargo acceptance history of nearby stations (64) ===<br />
<br />
The parameter of this variable is a cargo identifier. If your GRF is version 7 or later and has a cargo translation table, this is an index to that table; otherwise, it's a cargo slot number. Additionally, GRF register 100h should contain an offset relative to the current tile (use 0 for the current tile). The returned value looks like this:<br />
<br />
{| |-<br />
!Bit number!!Meaning<br />
|-<br />
|0||This cargo was accepted in a nearby station some time in the past<br />
|-<br />
|1||This cargo was accepted in a nearby station last month<br />
|-<br />
|2||This cargo was accepted in a nearby station this month<br />
|-<br />
|3||This cargo was accepted in a nearby station since the last periodic processing (which happens every 250 ticks)<br />
|-<br />
|4||This cargo is one of the types that triggered [[Callbacks#Watched cargo accepted (148) |callback 148]] (only during callback 148)<br />
|-<br />
|other bits||undefined; reserved for future use<br />
|}<br />
<br />
A station is considered nearby if the selected tile is inside its acceptance area. That's why you can give an offset - other tiles of your multi-tile building may have different stations "nearby".<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 />
=== Distance of nearest house matching a given criterion (65) ===<br />
<br />
This will perform a circular search around the current tile, trying to find another house tile that will match the same type, class or GRFID. (Note: other tiles of the originating house will not match.) &nbsp;Search result will be the [http://en.wikipedia.org/wiki/Taxicab_geometry|Manhattan distance] between both tiles or 0, if no house tile matching the given criteria has been found.<br />
<br />
The parameter of this variable is composed of two parts:<br />
<br />
Bits 0..5 indicate the radius of the search going to be performed (given in Manhattan metric). Maximum search radius is 63 while the minimum is 1. A radius of 0 is considered reserved - do not use.<br />
<br />
Bits 6..7 indicate the type of search to be carried out:<br />
<br />
0 : Search by house type as defined in the grf file<br />
<br />
1 : Search by building class<br />
<br />
2 : Search by GRFID<br />
<br />
Just like other search variables, be aware that this is a CPU intensive one<br />
<br />
=== Class and ID of nearby house tile (66) ===<br />
<br />
The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7, 8h=8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. The returned value is structured like this:<br />
<br />
{| |-<br />
!High word!!Information about house class<br />
|-<br />
|||'''FFFFh''' if the selected tile isn't a house tile<br />
|-<br />
|||'''0000h''' if the selected house doesn't have a class specified (including old houses, which cannot have a class)<br />
|-<br />
|||'''01XXh''' if the selected house has been defined in the current GRF with class XX<br />
|-<br />
|||'''02XXh''' if the selected house has been defined in a different GRF with class XX<br />
|-<br />
!Low word!!Information about house ID<br />
|-<br />
|||'''FFFFh''' if the selected tile isn't a house tile<br />
|-<br />
|||'''00XXh''' if the selected house is old house type XX<br />
|-<br />
|||'''01XXh''' if the selected house has been defined in the current GRF with ID XX<br />
|-<br />
|||'''02XXh''' if the selected house has been defined in a different GRF with ID XX<br />
|}<br />
<br />
In case the selected house comes from another GRF, you need to use variable 67 (see below) to find out the corresponding GRFID and identify the exact type of the house. Please note that variable 67 is cheaper to calculate than this one, so if you are looking for a specific GRFID/houseID combination, you should try matching the GRFID first, and get variable 66 only if the GRFID matches.<br />
<br />
=== GRFID of nearby house tile (67) ===<br />
<br />
The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7, 8h=8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. The returned value is one of the following:<br />
* '''FFFFFFFFh''' if the selected tile isn't a house tile<br />
* '''00000000h''' if the selected house is an old house type<br />
* otherwise, the GRFID of the GRF which defined the type of the selected house<br />
<br />
==Example==</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2&diff=1807VariationalAction22011-06-19T16:33:53Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
To support changes in graphics based on other factors than just the load states, you use a VarAction2. This provides a sophisticated way of deciding what graphics to use.<br />
<br />
A VarAction2 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 VarAction2, 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 "related" 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 "related" 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 OpenTTD 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 VarAction2<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, TTDPatch 2.6 r2049<br />
|-<br />
|24||D||current year; long format, year zero based since OpenTTD r13376, TTDPatch 2.6 r2049<br />
|-<br />
|25||D||GRFID of the grf that contains the corresponding Action3. Useful when accessing the "related" 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, TTDPatch 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 TTDPatch 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 TTDPatch 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 VarAction2]]<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 TTDPatch 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>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VarAction2Advanced&diff=1806VarAction2Advanced2011-06-19T16:33:41Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</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 VarAction2 blocks in several places on the NFO code.<br />
<br />
== Format ==<br />
<br />
An advanced VarAction2 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 TTDPatch 2.6 r1246. See [[Storages#Temporary storage|Temporary storage]].<br />
|-<br />
|0F||\2r or \2rst (a)||result = val2||Available since TTDPatch 2.6 r1246<br />
|-<br />
|10||\2psto (c)||var7C[val2] = val1, result = val1||Store result into persistent storage, available since TTDPatch 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 TTDPatch 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 TTDPatch 2.6 r1698 (*)<br />
|-<br />
|13||\2ucmp (c)||see notes||The same as 12, but operands are considered unsigned. Available since TTDPatch 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 TTDPatch 2.0.1 alpha 59, it is possible to access variables using both VarAction2 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 VarAction2 and makes it available to the next VarAction2 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 VarAction2, 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 TTDPatch 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 VarAction2, 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 VarAction2 in both the <set-id> and <default> positions.<br />
<br />
=== Using procedures ===<br />
<br />
When the variable in a VarAction2 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 VarAction2 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, VarAction2s 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 VarAction2. It is however valid to use any type of VarAction2, 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 "normal" chains.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=DebuggingGRFCode&diff=1805DebuggingGRFCode2011-06-19T16:33:29Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Introduction ==<br />
<br />
For the most part, writing NFO code, especially VarAction2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.<br />
<br />
OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: [http://wiki.openttd.org/NewGRF_Debugging| OpenTTD NewGRF debugging]<br />
<br />
TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.<br />
<br />
To activate the debugger, use the sign cheat "Cht: grfdebug 1 [<feature> [<id> [<callback>]]]".<br />
<br />
The "1" is there to activate the debugger. This creates a file "grfdebug.log" (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to "invalid parameter", it means the file "grfdebug.log" could not be created, possibly because a file of the same name exists but is not writable. If it fails with "unknown cheat", the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).<br />
<br />
For instance, "Cht: grfdebug 1 1 255 18" logs [[Callbacks#Load amount callback 12|callback 12]] (load amount, decimal 18) for all road vehicles.<br />
<br />
Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.<br />
<br />
When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250|tool] to parse the "grfdebug.log" file into a more descriptive text file.<br />
<br />
GET cccciiff <GRFID><br />
<br />
Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given GRFID is the one owning the action 3 in question.<br />
<br />
ACT2 <sprite> 00000000<br />
<br />
When processing a regular, random or VarAction2. The sprite number is the sprite number in the .NFO file minus one, given in hex.<br />
<br />
RND <value> <rndbits><br />
<br />
In a random action 2, the random value is <value> with <rndbits> being the bits used to choose the next action 2.<br />
<br />
VAR <value> <adjusted><br />
<br />
In a VarAction2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the VarAction2 type.<br />
<br />
RSLT <result> 00000000<br />
<br />
A callback result has been computed. When not in a callback, this causes the sprite determination to fail and default sprites to be used.<br />
<br />
SPRT <sprite> 00000000<br />
<br />
A sprite number has been computed. When in a callback, this causes the callback to fail if it isn't following a RSLT line indicating a valid callback result.<br />
<br />
Since the value is mapped into TTD's sprite number space, it is not directly related to sprite numbers in the NFO file. To translate the returned sprite number to an action 1 block sprite, it is necessary to have this grf file be loaded first in newgrf(w).cfg. Then the sprite numbers of action 1 blocks will be allocated consecutively starting from the base number (see below) for each feature.<br />
<br />
{|<br />
!Feature!!Base number<br />
<br />
|-<br />
|other||1324 (4900) Note: this includes all features not listed below as well as GRM sprite allocations<br />
<br />
|-<br />
|Trains||4000 (16384)<br />
<br />
|-<br />
|Road vehicles||6CDC (27868)<br />
<br />
|-<br />
|Aircraft||99B8 (39352)<br />
<br />
|-<br />
|Ships||BBCD (48077)<br />
<br />
|-<br />
|Houses||DDE2 (56802)<br />
|}<br />
<br />
The feature-specific base numbers are only valid if the extended sprite limit is active, otherwise all features use the "other" base number.<br />
<br />
For instance, the first sprite block of 32 (20 hex) sprites for a road vehicle would start at sprite 6CDC, then the following sprite block would start at 6CDC+20=6CFC.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callbacks&diff=1804Callbacks2011-06-19T16:33:23Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
A callback is a special action 2 that the patch "calls" in order to modify various features, an example being the visual effect of train vehicles. &nbsp;See the [[CallbacksTut|callback tutorial]] on how to use them.<br />
<br />
In the final action 2 of a chain of VarAction2s, the second byte of the matching entry has to have bit 7 set to identify it as a callback result. (Previously, it was required that the second byte be FF, but now only bit 7 needs to be set.)<br />
<br />
For example, 04 00 is not a callback result (but it may be the ID of another chained action 2), whereas 04 80 is a callback result with a value of 4. &nbsp;For some callbacks, 15 bit results are possible, in which case the upper 7 bits are stored in the second byte. &nbsp;For example, 54 C2 is a callback result with a value of 4254=16980, where again the second byte has bit 7 set, changing the 42 into C2.<br />
<br />
For compatibility with earlier patch versions, FF in the high byte is taken to mean the same thing as 80, so 04 FF also has a callback result of 4. &nbsp;Note that if your grf file needs to be compatible with versions before TTDPatch 2.0.1 alpha 40, you must set the high byte to FF, and so can use only 8 bit results.<br />
<br />
== List of callbacks ==<br />
<br />
The following callbacks are defined by the patch. &nbsp;The number of the callback is what will be stored in variable 0C so that you can return the right results if you have several callbacks. &nbsp;All callbacks are explained in more detail below.<br />
<br />
'''PLEASE NOTE:''' Since TTDPatch 2.5 beta 5, the size of variable 0C has changed, and now there are word-sized callback numbers as well. To maintain backwards compatibility, only callbacks 10..3F can be checked using a byte-sized check. Callbacks 140 and above, on the other hand, must be checked using a word or dword sized check, to make sure they are identified uniquely.<br />
<br />
{| |-<br />
!Number!!Feature(s)!!Meaning<br />
|-<br />
|10||Vehicles||[[Callback: Visual effect and wagon power|Visual effect and wagon power]]<br />
|-<br />
|11||Vehicles||[[Callback: Wagon length|Wagon length]]<br />
|-<br />
|12||Vehicles||[[Callback: Load amount|Load amount]]<br />
|-<br />
|13||Stations||[[Callback: Station availability|Station availability]]<br />
|-<br />
|14||Stations||[[Callback: Station sprite layout|Select sprite layout]]<br />
|-<br />
|15||Vehicles||[[Callback: Refitted capacity callback|Refitted capacity callback]]<br />
|-<br />
|16||Trains||[[Callback: Articulated engine|Build articulated engines]]<br />
|-<br />
|17||Houses||[[Callback: House construction check|House construction check]]<br />
|-<br />
|18||Several (G*)||[[Callback: AI construction/purchase selection|AI construction/purchase selection]]<br />
|-<br />
|19||Vehicles||[[Callback: Cargo Subtype Display|Cargo sub-type display]]<br />
|-<br />
|1A||Houses||Next animation frame<br />
|-<br />
|1B||Houses||Animation control<br />
|-<br />
|1C||Houses||Construction stage changes<br />
|-<br />
|1D||Trains||Can wagon be attached<br />
|-<br />
|1E||Houses||Decide colour of building<br />
|-<br />
|1F||Houses||Cargo acceptance<br />
|-<br />
|20||Houses||Length of animation frame<br />
|-<br />
|21||Houses||Trigger building destruction<br />
|-<br />
|22||Industries||Availability<br />
|-<br />
|23||Vehicles||Additional text in purchase screen<br />
|-<br />
|24||Stations||Custom station layout<br />
|-<br />
|25||Industry tiles||Animation control<br />
|-<br />
|26||Industry tiles||Next animation frame<br />
|-<br />
|27||Industry tiles||Length of animation frame<br />
|-<br />
|28||Industries||Industry location permissibility<br />
|-<br />
|29||Industries||Random production change<br />
|-<br />
|2A||Houses||Get accepted cargo types<br />
|-<br />
|2B||Industry tiles||Decide cargo acceptance<br />
|-<br />
|2C||Industry tiles||Get accepted cargo types<br />
|-<br />
|2D||Vehicles||Select colour mapping for vehicle<br />
|-<br />
|2E||Houses||Custom cargo production<br />
|-<br />
|2F||Industry tiles||Custom shape check<br />
|-<br />
|30||Industry tiles||Decide drawing default foundations<br />
|-<br />
|31||Vehicles||Start/stop check<br />
|-<br />
|32||Vehicles||32-day callback<br />
|-<br />
|33||Several||Sound effect callback<br />
|-<br />
|34||Vehicles (G*)||Autoreplace vehicle selection<br />
|-<br />
|35||Industries||Monthly random production change<br />
|-<br />
|36||Vehicles||Change vehicle Properties<br />
|-<br />
|37||Industries||Cargo sub-type display<br />
|-<br />
|38||Industries||Show additional text in fund window<br />
|-<br />
|39||Cargoes||Custom profit calculation<br />
|-<br />
|3A||Industries||Show additional text in industry window<br />
|-<br />
|3B||Industries||Control special effects<br />
|-<br />
|3C||Industry tiles||Disable autosloping<br />
|-<br />
|3D||Industries||Opt out of accepting cargo<br />
|-<br />
|40..13F|| ||--Reserved--<br />
|-<br />
|140||Stations||Animation control<br />
|-<br />
|141||Stations||Next animation frame<br />
|-<br />
|142||Stations||Length of animation frame<br />
|-<br />
|143||Houses||Protect building conditionally<br />
|-<br />
|144||Sounds (G*)||Ambient sound effects<br />
|-<br />
|145||Cargoes||Custom station rating calculation<br />
|-<br />
|146||New Signals (G*)||New signals sprite drawing||<br />
|-<br />
|147||Canals||Add sprite offset<br />
|-<br />
|148||Houses||Watched cargo accepted<br />
|-<br />
|149||Stations||Land slope check<br />
|-<br />
|14A||Industries||Decide industry color<br />
|-<br />
|14B||Industries||Decide input cargo types<br />
|-<br />
|14C||Industries||Decide output cargo types<br />
|-<br />
|14D||Houses||Customized building name<br />
|-<br />
|14E||Houses||Decide drawing default foundations<br />
|-<br />
|14F||Houses||Disable autosloping<br />
|-<br />
|150||Airport tiles||Decide drawing default foundations<br />
|-<br />
|152||Airport tiles||Animation control (OpenTTD &gt; r19197)<br />
|-<br />
|153||Airport tiles||Next Animation frame (OpenTTD &gt; r19197)<br />
|-<br />
|154||Airport tiles||Length of animation frame (OpenTTD &gt; r19197)<br />
|-<br />
|155||Airports||Extra information about airport layout in the build gui (OpenTTD &gt; r20372)<br />
|-<br />
|156||Airports||Airport layout name (OpenTTD &gt; r20373)<br />
|-<br />
|157||Objects||Land slope check<br />
|-<br />
|158||Objects||Next animation frame<br />
|-<br />
|159||Objects||Animation control<br />
|-<br />
|15A||Objects||Length of animation frame<br />
|-<br />
|15B||Objects||Decide colour of building<br />
|-<br />
|15C||Objects||Show additional text in building window<br />
|-<br />
|15D||Objects||Disable autosloping<br />
|}<br />
(*) Generic callbacks are called for the feature, not any specific vehicle ID. Read the [[Action3#n-id|Action 3]] entry on how to define these.<br />
<br />
{{:Callback: Visual effect and wagon power}}<br />
{{:Callback: Wagon length}}<br />
{{:Callback: Load amount}}<br />
{{:Callback: Station availability}}<br />
{{:Callback: Station sprite layout}}<br />
{{:Callback: Refitted capacity callback}}<br />
{{:Callback: Articulated engine}}<br />
{{:Callback: House construction check}}<br />
{{:Callback: AI construction/purchase selection}}<br />
{{:Callback: Cargo Subtype Display}}<br />
{{:Callback: Next animation frame}}<br />
{{:Callback: Animation control}}<br />
{{:Callback: Construction stage changes}}<br />
{{:Callback: Can wagon be attached}}<br />
{{:Callback: Building colour}}<br />
{{:Callback: Cargo acceptance}}<br />
{{:Callback: Length of animation frame}}<br />
{{:Callback: Trigger building destruction}}<br />
{{:Callback: Industry availability}}<br />
{{:Callback: Additional text in purchase screen}}<br />
{{:Callback: Custom station layout}}<br />
{{:Callback: Industry location permissibility}}<br />
{{:Callback: Random production change}}<br />
{{:Callback: Get accepted cargo types}}<br />
{{:Callback: Decide cargo acceptance}}<br />
{{:Callback: Select colour mapping for vehicle}}<br />
{{:Callback: Custom cargo production}}<br />
{{:Callback: Custom shape check}}<br />
{{:Callback: Decide drawing default foundations}}<br />
{{:Callback: Vehicle Start/stop check}}<br />
{{:Callback: 32-day callback}}<br />
{{:Callback: Sound effect}}<br />
{{:Callback: Autoreplace vehicle selection}}<br />
{{:Callback: Monthly random production change}}<br />
{{:Callback: Change vehicle properties}}<br />
{{:Callback: Cargo sub-type display for industries}}<br />
{{:Callback: Show additional text in fund/building window}}<br />
{{:Callback: Custom profit calculation for cargoes}}<br />
{{:Callback: Show additional text in industry window}}<br />
{{:Callback: Control special industry effects}}<br />
{{:Callback: Disable autosloping}}<br />
{{:Callback: Opt out of accepting cargo}}<br />
{{:Callback: Protect building conditionally}}<br />
{{:Callback: Ambient sound effects}}<br />
{{:Callback: Custom station rating calculation}}<br />
{{:Callback: New signals sprite drawing callback}}<br />
{{:Callback: Add sprite offset callback}}<br />
{{:Callback: Watched cargo accepted}}<br />
{{:Callback: Land slope check}}<br />
{{:Callback: Decide industry colour}}<br />
{{:Callback: Decide input and output cargo types}}<br />
{{:Callback: Customized building name}}<br />
{{:Callback: Extra information about layout in the build gui}}<br />
{{:Callback: Layout name}}<br />
{{:Callback: Decide object colour}}</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Refitted_capacity_callback&diff=1803Callback: Refitted capacity callback2011-06-19T16:33:11Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Refitted capacity callback (15) ==<br />
<br />
This callback is used when a vehicle is refitted, to find the new capacity. It is a 15 bit callback since TTDPatch 2.0.1 alpha 40, and allows return values up to 7EFF=32511 units of cargo.<br />
<br />
Vehicle variable B9 (for a VarAction2) will be set to the new, climate-specific cargo type (column 3, type B in the [[CargoTypes|cargo type list]]), or to FF when only checking whether the vehicle is refittable.<br />
<br />
Unlike regular refitted capacities (including those from callback 36), the return value is not subject to the usual division of capacities for cargoes other than passengers on trains and planes, instead the capacity is used exactly as returned by the callback. See also the summary page about &nbsp;[[VehicleRefitting|vehicle refitting]].<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_New_signals_sprite_drawing_callback&diff=1802Callback: New signals sprite drawing callback2011-06-19T16:33:07Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== New signals sprite drawing callback (146) ==<br />
<br />
This is a generic callback, and thus a generic action 3 must be used. It must be processed by a VarAction2 feature 0E, as indicated in the following link: [[VarAction2NewSignals]].<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Custom_cargo_production&diff=1801Callback: Custom cargo production2011-06-19T16:33:05Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Custom cargo production (2E) ==<br />
<br />
This callback can be used to customize cargo production of house tiles. It is called every 256 ticks when the tile can produce cargo.<br />
Because a tile can produce many types of cargo, this callback is called in a loop until it returns 20FFh (the loop count is limited<br />
to 256 to avoid endless loops). If the returned value is not 20FFh, the high byte must be a cargo type and the low byte must be the<br />
amount to be distributed. You can return a cargo type more than once if needed, so you can distribute more than 255 units from it.<br />
During the callback, the lowest byte of variable 10 contains the number of iterations happened so far and variable 18 contains a<br />
random value to help randomizing the production. (The old code randomizes production to make it look more natural, you can do the<br />
same via a VarAction2 with nvar=0)<br />
<br />
This is how the original passenger generation is done: In each periodic processing (i.e. every 256 ticks), a random value 0<=X<=255<br />
is generated for each house tile. If X isn't smaller than the population of the tile, no passengers are generated. Otherwise, X/8+1<br />
passengers are generated (rounded down). If there is a recession going on, the number of generated passengers is halved, but this<br />
division gets rounded up instead of down. Mail generation happens in a similar manner, but with a new random value, and checking<br />
against the mail generation multiplier instead of the population.<br />
<br />
Uses 15 return bits<br />
<br />
From GRF version 7 and above, the interpretation of the high byte in the returned value changes: instead of a climate-dependent<br />
cargo slot number, you have to return a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID<br />
is the index in that table; otherwise, it's the cargo bit. Trying to produce a cargo not currently present is not an error, but will be ignored.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Can_wagon_be_attached&diff=1800Callback: Can wagon be attached2011-06-19T16:32:58Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Can wagon be attached (1D) ==<br />
<br />
This callback is called for the train engine (i.e. from the engine's action 3) when attaching a new vehicle to the current train and determines whether it may in fact be attached to the train. The callback is always used when defined, no bit in the action 0 property needs to be set to activate it.<br />
<br />
You may use VarAction2s to check variables 40+x and 80+x. For var. action 2 type 81 (vehicle), they refer to variables of the wagon that is to be attached, not the engine it is being attached to, so you can check the wagon's properties like the cargo type to see whether it is appropriate for the given train engine.<br />
<br />
Var. action 2 type 82 (engine) refers to the engine the wagon is being attached to, starting from version TTDPatch 2.0.1 alpha 46. This allows you to for example find out the length of the train it is being attached to. In earlier patch versions, it refers to the engine of the source consist (or the wagon if the wagon is not attached to anything else), which was not really helpful.<br />
<br />
Return values:<br />
<br />
{| |-<br />
!Return!!Meaning<br />
|-<br />
|xx||Disallow attaching and use the D0xx text ID as second line of an error message,<br />
|-<br />
|FD||Disallow attaching with the standard message (incompatible rail types)<br />
|-<br />
|FE||Allow attaching<br />
|-<br />
|FF||Allow attaching if the rail types match (default)<br />
|}<br />
<br />
It you return FE, you would allow attaching for example a monorail wagon to a regular rail vehicle, so if that's not what you intend, return FF.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Vehicles/Trains&diff=1799Action0/Vehicles/Trains2011-06-19T16:32:54Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>=Introduction=<br />
Defining properties of train vehicles.<br />
<br />
= Properties =<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description!!Available for articulated parts<br />
|-<br />
|05|| ||B||Track type (see below)||should be same as front<br />
|-<br />
|08|| ||B||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no<br />
|-<br />
|09|| ||W||Speed in mph*1.6 (see below)||no<br />
|-<br />
|0B|| ||W||Power (0 for wagons)||should be zero<br />
|-<br />
|0D|| ||B||Running cost factor (0 for wagons)||should be zero<br />
|-<br />
|0E|| ||D||Running cost base, see below||should be zero<br />
|-<br />
|12|| ||B||Sprite ID (FD for new graphics)||yes<br />
|-<br />
|13|| ||B||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front<br />
|-<br />
|14|| ||B||Cargo capacity||yes<br />
|-<br />
|15|| ||B||Cargo type, see column 3 (type B) in [[CargoTypes]]||yes<br />
|-<br />
|16|| ||B||Weight in tons||should be zero<br />
|-<br />
|17|| ||B||Cost factor||should be zero<br />
|-<br />
|18|| ||B||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no<br />
|-<br />
|19||1||B||Engine traction type (see below)||no<br />
|-<br />
|1A||1/(f)||B/B*||Not a property, but an action: sort the purchase list.||no<br />
|-<br />
|1B||6||W||Power added by each wagon connected to this engine, see below||should be zero<br />
|-<br />
|1C||6||B||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes<br />
|-<br />
|1D||6||D||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]||yes<br />
|-<br />
|1E||6||B||Callback flags bit mask, see below||yes<br />
|-<br />
|1F||(a)||B||Coefficient of tractive effort||should be zero<br />
|-<br />
|20||(b)||B||Coefficient of air drag||should be zero<br />
|-<br />
|21||2||B||Make vehicle shorter by this amount, see below||yes<br />
|-<br />
|22||6||B||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes<br />
|-<br />
|23||6||B||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero<br />
|-<br />
|24||(c)||B||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero<br />
|-<br />
|25||(c)||B||User-defined bit mask to set when checking veh. var. 42||yes<br />
|-<br />
|26||(c)||B||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no<br />
|-<br />
|27||(d)||B||Miscellaneous flags||partly<br />
|-<br />
|28||(d)||W||Refittable cargo classes||yes<br />
|-<br />
|29||(d)||W||Non-refittable cargo classes||yes<br />
|-<br />
|2A||(e)||D||Long format introduction date||no<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|(a)||2.0.1 alpha 19<br />
|-<br />
|(b)||2.0.1 alpha 27<br />
|-<br />
|(c)||2.0.1 alpha 44<br />
|-<br />
|(d)||2.0.1 alpha 58<br />
|-<br />
|(e)||2.5 r1210, OpenTTD r7191<br />
|-<br />
|(f)||OpenTTD r13831<br />
|}<br />
<br />
= Comments =<br />
<br />
== Track type (05) ==<br />
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].<br />
In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.<br />
<br />
== Speed (09) ==<br />
<br />
Train speed is in units of mph*1.6, i.e. approximately km/h.<br />
<br />
For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed. &nbsp;This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.<br />
<br />
For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.<br />
<br />
== Power (0B) ==<br />
<br />
The power of the engine, in HP.<br />
<br />
A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.<br />
<br />
== Running cost base (0E) and factor (0D) ==<br />
<br />
TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor. &nbsp;The base amount is changed according to inflation, whereas the factor remains constant.<br />
<br />
For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):<br />
<br />
{| |-<br />
!Type!!Value!!in little-endian notation<br />
|-<br />
|Steam engines||4C30||30 4C 00 00<br />
|-<br />
|Diesel engines||4C36||36 4C 00 00<br />
|-<br />
|Electric engines||4C3C||3C 4C 00 00<br />
|-<br />
|Wagons||0||00 00 00 00<br />
|}<br />
<br />
Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.<br />
<br />
The following are some real values for maintenance costs depending on the setting of the above two factors. &nbsp;This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively. &nbsp;These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).<br />
<br />
'''Running cost base 4C30 (steam)'''<br />
<br />
{| |-<br />
!Running cost factor!!Maintenance cost<br />
|-<br />
|01||$ 42<br />
|-<br />
|10||$ 700<br />
|-<br />
|20||$ 1.400<br />
|-<br />
|80||$ 5.600<br />
|-<br />
|A0||$ 7.000<br />
|-<br />
|FF||$ 11.112<br />
|}<br />
<br />
'''Running cost base 4C36 (diesel)'''<br />
<br />
{| |-<br />
!Running cost factor!!Maintenance cost<br />
|-<br />
|01||$ 40<br />
|-<br />
|10||$ 650<br />
|-<br />
|20||$ 1.300<br />
|-<br />
|80||$ 5.200<br />
|-<br />
|A0||$ 6.500<br />
|-<br />
|FF||$ 10.318<br />
|}<br />
<br />
'''Running cost base 4C3C (electric)'''<br />
<br />
{| |-<br />
!Running cost factor!!Maintenance cost<br />
|-<br />
|01||$ 36<br />
|-<br />
|10||$ 600<br />
|-<br />
|20||$ 1.200<br />
|-<br />
|80||$ 4.800<br />
|-<br />
|A0||$ 6.000<br />
|-<br />
|FF||$ 9.524<br />
|}<br />
<br />
== Cost factor (17) ==<br />
<br />
The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.<br />
<br />
{| |-<br />
!Cost factor!!Price<br />
|-<br />
|01||$ 3.124<br />
|-<br />
|10||$ 50.000<br />
|-<br />
|20||$ 100.000<br />
|-<br />
|80||$ 400.000<br />
|-<br />
|A0||$ 500.000<br />
|-<br />
|FF||$ 796.874<br />
|}<br />
<br />
== Engine traction type (19) ==<br />
<br />
This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology. &nbsp;It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.<br />
<br />
The following ranges are available (and it does not matter which value you pick):<br />
<br />
{| |-<br />
!Values!!Traction type<br />
|-<br />
|00..07||Steam<br />
|-<br />
|08..27||Diesel<br />
|-<br />
|28..31||Electric<br />
|-<br />
|32..37||Monorail<br />
|-<br />
|38..41||Maglev<br />
|}<br />
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].<br />
In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.<br />
<br />
== Sort vehicle list (1A) ==<br />
<br />
This property is an extended byte in OpenTTD since r13831!<br />
<br />
This is not a property as such, but an action. &nbsp;It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property. &nbsp;The order of this list is only used in the train purchase window.<br />
<br />
For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...<br />
<br />
This property can not simply be overwritten, because the list is already shuffled when trying to do so. &nbsp;It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:<br />
<br />
<pre>-+00 00 01 00 00 1A+-</pre><br />
<br />
Resetting the list should however only be done by sets that contain replacements for all train vehicles.<br />
<br />
== Powered train wagons (1B and 23, see also 22) ==<br />
<br />
Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead. &nbsp;Therefore, to model real-life trains where wagons have power, a different mechanism is needed.<br />
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well. &nbsp;This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.<br />
<br />
In addition to adding power, these wagons are also heavier by the amount set in property 23.<br />
<br />
== Callbacks (1E) ==<br />
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 1E (certain other, not as frequently used callbacks are available without setting a bit here):<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||10||Powered wagons and visual effect<br />
|-<br />
|1||2||11||Wagon length<br />
|-<br />
|2||4||12||Load amount<br />
|-<br />
|3||8||15||Set refitted capacity<br />
|-<br />
|4||10||16||Build articulated engines<br />
|-<br />
|5||20||19||show a suffix after the cargo type name<br />
|-<br />
|6||40||2D||Select color mapping for vehicle<br />
|-<br />
|7||80||33||Sound effect callbacks<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 VarAction2 for callbacks.<br />
<br />
Callbacks 1D (Can wagon be attached?), 23 (Additional text in purchase screen), 31 (Start/stop check), 32 &nbsp; &nbsp;(32-day callback), 34 &nbsp; &nbsp; (Autoreplace vehicle selection) and 36 (Change Vehicle Properties) do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.<br />
<br />
== Coefficient of tractive effort (1F) ==<br />
<br />
This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort. &nbsp;This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.<br />
<br />
Theoretically, this value should be calculated by taking the ratio of adhesive weight W{SUB()}adh{SUB} (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:<br />
<br />
prop. 1F = HEX ((Wadh * µ / W) * 255)<br />
<br />
With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.<br />
<br />
Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TEreal) of 259 kN. To quickly find the value for property 1F you fill in the following formula:<br />
<br />
prop. 1F = HEX ((TEreal / (Mass * g) * 255)<br />
<br />
That may look confusing but you already know all variables:<br />
<br />
prop. 1F = HEX ((259 / (84 * 9.8) * 255)<br />
prop. 1F = HEX (0.3146 *255) = HEX(80.229)<br />
<br />
HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:<br />
<br />
HEX 80 = 50<br />
<br />
Property 1F for the NS 1600 (Electric) would then be: 1F 50.<br />
<br />
== Coefficient of air drag (20) ==<br />
<br />
This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).<br />
<br />
The default values are the following:<br />
<br />
{| |-<br />
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...<br />
|-<br />
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8<br />
|}<br />
<br />
<br />
For higher speeds, the series is continued in the same manner.<br />
<br />
Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.<br />
<br />
== Shorter train vehicles (21) ==<br />
<br />
This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly (**), except at the end of the train*. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).<br />
<br />
* This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.<br />
<br />
** This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.<br />
<br />
<br />
== Visual effects and wagon power (22) ==<br />
<br />
By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For OpenTTD r21230 and later positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.<br />
<br />
Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.<br />
<br />
Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).<br />
<br />
{| |-<br />
!Range !!Effect type<br />
|-<br />
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.<br />
|-<br />
|10..1F|| Steam puffs<br />
|-<br />
|20..2F|| Diesel fumes<br />
|-<br />
|30..3F|| Electric sparks<br />
|-<br />
|40|| Disable visual effect<br />
|-<br />
|80+10..80+3F|| Same as above, but disable wagon power<br />
|-<br />
|80+40|| Disable both visual effect and wagon power<br />
|}<br />
<br />
<br />
For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.<br />
<br />
== Miscellaneous flags (27) ==<br />
<br />
This is a bit mask, with the following bits:<br />
<br />
{| |-<br />
!Bit!! Value!! Meaning<br />
|-<br />
|0|| 1|| Vehicle tilts in curves, and thus gets speed bonus<br />
|-<br />
|1|| 2|| Uses two company colors<br />
|-<br />
|2|| 4|| Vehicle is a multiple unit (DMU/EMU), for colour selection<br />
|-<br />
|3|| 8|| Vehicle can be flipped around in the depot (OpenTTD r21966+)<br />
|}<br />
<br />
The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.<br />
<br />
When you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles. For multiheaded or articulated vehicles the flipping bit has no effect; these vehicles are never to be flipped around in the depot.<br />
<br />
In versions of OpenTTD before r21966 (~1.1.0-beta5) all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such this disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.<br />
== Cargo classes (28, 29) ==<br />
<br />
To make vehicle sets more compatible with future new cargo definitions, these two properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match the classes set in prop. 28 except for the ones that match the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is<br />
<br />
Refit list = (cargos from prop. 28 AND NOT cargos from prop. 29) XOR cargos from prop. 1D<br />
<br />
This means, if a cargo type is in the list because it matches prop. 28 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.<br />
<br />
As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.<br />
<br />
The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.<br />
<br />
[[Action0Cargos#Cargo classes 16|action0 cargos]] page for bits and classes defined so far.<br />
<br />
Note that cargo types may belong to several classes. This is the reason for making two properties, an additive and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).<br />
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load. &nbsp;In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VarAction2Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.<br />
About the interaction with other properties take a look at the summary page about &nbsp;[[VehicleRefitting|vehicle refitting]].<br />
<br />
== Long format introduction date (2A) ==<br />
<br />
Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect. In TTDPatch, dates after 2044 will be limited to 2044.<br />
<br />
= Example =<br />
<br />
Below is an example of what a real Action 0 pseudo-sprite could look like for a train engine.<br />
<br />
(A basic version)<br />
<br />
<pre>10 * 14 &nbsp;00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre><br />
<br />
{| |-<br />
!'''Bytes'''!!'''Meaning'''<br />
|-<br />
|10||&lt;Sprite-number&gt;<br />
|-<br />
|14||&lt;Length&gt;: of the action in bytes; start counting at 0 (&lt;action&gt;)<br />
|-<br />
|00||&lt;action&gt;: sets this pseudo-sprite to function as action 0<br />
|-<br />
|00||&lt;Feature&gt;: In this case Train<br />
|-<br />
|03||&lt;Num-props&gt;: 3 Properties to change<br />
|-<br />
|01||&lt;Num-info&gt;: 1 vehicle ID to make changes to<br />
|-<br />
|02||&lt;ids...&gt;: vehcile ID (02 - Ploddyphut Choo-Choo)<br />
|-<br />
|||'''Properties'''<br />
|-<br />
|09||&lt;Speed&gt;<br />
|-<br />
|C0 00||&lt;Value&gt;: Value for Speed (192 Km/h)<br />
|-<br />
|0B||&lt;Power&gt;<br />
|-<br />
|D8 0E||&lt;value&gt;: value for Power (3800 HP)<br />
|-<br />
|12||&lt;Sprite ID&gt;<br />
|-<br />
|FD||&lt;value&gt;: FD for new graphics<br />
|}<br />
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.<br />
<br />
Below is the same example as above, with escape sequences being used:<br />
<br />
<pre>-1 * 0 00 00 \b3 01 \b*2 // \b&lt;number of props to change&gt; \b*&lt;vehicle ID&gt;<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;09 \w192 // value for speed (192 Km/h)<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;0B \w3800 // value for power (3800 hp)<br />
<br />
&nbsp; &nbsp; &nbsp; &nbsp;12 FD // use new graphics</pre></div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Vehicles/Ships&diff=1798Action0/Vehicles/Ships2011-06-19T16:32:52Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Introduction ==<br />
<br />
Defining properties of ships.<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08|| ||B||Sprite (FF for new graphics)<br />
|-<br />
|09|| ||B||Refittable (0 no, 1 yes)<br />
|-<br />
|0A|| ||B||Cost factor<br />
|-<br />
|0B|| ||B||Speed in mph*3.2<br />
|-<br />
|0C|| ||B||Cargo type, see column 3 (type B) in [[CargoTypes]]<br />
|-<br />
|0D|| ||W||Capacity<br />
|-<br />
|0F|| ||B||Running cost factor<br />
|-<br />
|10|| ||B||Sound effect type (4=cargo ship, 5=passenger ship)<br />
|-<br />
|11||1||D||Bit mask of cargo types available for refitting, see column 2 (bit values) in [[CargoTypes]]<br />
|-<br />
|12||6||B||Callback flags bit mask, see below<br />
|-<br />
|13||(a)||B||Refit cost, using 1/32 of the default refit cost base<br />
|-<br />
|14||(b)||B||Ocean speed fraction, sets fraction of top speed available in the ocean; e.g. 00=100%, 80=50%, FF=0.4%<br />
|-<br />
|15||(b)||B||Canal speed fraction, same as above but for canals<br />
|-<br />
|16||(b)||B||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])<br />
|-<br />
|17||(c)||B||Miscellaneous vehicle flags<br />
|-<br />
|18||(c)||W||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]<br />
|-<br />
|19||(c)||W||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]<br />
|-<br />
|1A||(d)||D||Long format introduction date<br />
|-<br />
|1B||(e)||B*||Sort the purchase list<br />
|-<br />
|1C||(f)||B||Visual effect<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|(a)||2.0.1 alpha 30<br />
|-<br />
|(b)||2.0.1 alpha 44<br />
|-<br />
|(c)||2.0.1 alpha 58<br />
|-<br />
|(d)||2.5 r1210, OpenTTD r7191<br />
|-<br />
|(e)||OpenTTD r13831<br />
|-<br />
|(f)||OpenTTD r21240<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Callbacks (12) ===<br />
For ships, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 12 (certain other, not as frequently used callbacks are available without setting a bit here):<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|2||4||12||Load amount<br />
|-<br />
|3||8||15||Set refitted capacity<br />
|-<br />
|5||20||19||show a suffix after the cargo type name<br />
|-<br />
|6||40||2D||Select color mapping for vehicle<br />
|-<br />
|7||80||33||Sound effect callbacks<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 VarAction2 for callbacks.<br />
<br />
=== Miscellaneous flags (17) ===<br />
<br />
This is a bit mask, with the following bits:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||reserved, do not use<br />
|-<br />
|1||2||Uses two company colors<br />
|}<br />
<br />
=== Long format introduction date (1A) ===<br />
<br />
Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect. In TTDPatch, dates after 2044 will be limited to 2044.<br />
<br />
=== Sort vehicle list (1B) ===<br />
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.<br />
<br />
=== Visual effect (1C) ===<br />
See the equivalent [[Action0Trains#Visual effects and wagon power 22|train property]] for information about the meaning of all bits. There is no default effect for ships, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.<br />
<br />
== Example ==<br />
<br />
To be written</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Vehicles/RoadVehicles&diff=1797Action0/Vehicles/RoadVehicles2011-06-19T16:32:50Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Introduction ==<br />
<br />
Defining properties of road vehicles.<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description!!Available for articulated parts<br />
|-<br />
|08|| ||B||Speed in mph*3.2||no<br />
|-<br />
|09|| ||B||Running cost factor||should be zero<br />
|-<br />
|0A|| ||D||Running cost base, see below||should be zero<br />
|-<br />
|0E|| ||B||Sprite ID (FF for new graphics)||yes<br />
|-<br />
|0F|| ||B||Capacity||yes<br />
|-<br />
|10|| ||B||Cargo type, see column 3 (type B) in [[CargoTypes]]||yes<br />
|-<br />
|11|| ||B||Cost factor||should be zero<br />
|-<br />
|12|| ||B||Sound effect: 17/19/1A for regular, 3C/3E for toyland||no<br />
|-<br />
|13||2||B||Power in 10 hp, see below||should be zero<br />
|-<br />
|14||2||B||Weight in 1/4 tons, see below||should be zero<br />
|-<br />
|15||2||B||Speed in mph*0.8, see below||no<br />
|-<br />
|16||2||D||Bit mask of cargo types available for refitting (not refittable if 0 or unset), see column 2 (bit values) in [[CargoTypes]]||yes<br />
|-<br />
|17||6||B||Callback flags bit mask, see below||yes<br />
|-<br />
|18||(a)||B||Coefficient of tractive effort||should be zero<br />
|-<br />
|19||(a)||B||Coefficient of air drag||should be zero<br />
|-<br />
|1A||(a)||B||Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]||yes<br />
|-<br />
|1B||(b)||B||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no<br />
|-<br />
|1C||(c)||B||Miscellaneous vehicle flags||partly ("tram" should be same as front)<br />
|-<br />
|1D||(c)||W||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]||yes<br />
|-<br />
|1E||(c)||W||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]||yes<br />
|-<br />
|1F||(d)||D||Long format introduction date||no<br />
|-<br />
|20||(e)||B*||Sort the purchase list||no<br />
|-<br />
|21||(f)||B||Visual effect||yes<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|(a)||2.0.1 alpha 30<br />
|-<br />
|(b)||2.0.1 alpha 44<br />
|-<br />
|(c)||2.0.1 alpha 58<br />
|-<br />
|(d)||2.5 r1210, OpenTTD r7191<br />
|-<br />
|(e)||OpenTTD r13831<br />
|-<br />
|(f)||OpenTTD r21240<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Running cost base (0A) and factor (09) ===<br />
<br />
TTD calculates all costs by multiplying a 48-bit base amount with an 8-bit factor. &nbsp;The base amount is changed according to inflation, whereas the factor remains constant.<br />
<br />
For the running costs of road vehicles, the following base amounts are available:<br />
<br />
{| |-<br />
!Type!!Value!!in little-endian notation<br />
|-<br />
|Road vehicle running cost base||4C48||48 4C 00 00<br />
|}<br />
|-<br />
|Theoretically, you could use pointers to other [[BaseCosts|base amounts]] available in TTD, but these are the numbers TTD uses for road vehicles.<br />
<br />
=== Cost factor (11) ===<br />
<br />
The cost factor is a bit-coded value which determines how expensive a vehicle is. The table below gives you some values to use for finding the right price for your vehicles.<br />
<br />
{| |-<br />
!Cost factor!!Price<br />
|-<br />
|00||$ 0<br />
|-<br />
|01||$ 108<br />
|-<br />
|10||$ 1,750<br />
|-<br />
|20||$ 3,500<br />
|-<br />
|80||$ 14,000<br />
|-<br />
|FF||$ 27,890<br />
|}<br />
<br />
=== Realistic acceleration properties (13, 14, 15) ===<br />
<br />
TTDPatch uses these properties only if road vehicles are set to realistic acceleration in the NewCurveAndMountainHandling switch. They are ignored otherwise.<br />
<br />
OpenTTD uses these properties always, if they are defined and gives the speed defined here precedence over the one defined in property 08.<br />
<br />
Using property 15 to set the speed, it is possible to achieve speeds larger than 80 mph (127 km/h), to which property 08 is limited. When setting property 15, always set property 08 as well, so that the vehicle works reasonably well whether realistic acceleration is turned on or off. If property 15 is not set, the value from property 08 is used instead.<br />
<br />
=== Callbacks (17) ===<br />
|-<br />
|For road vehicles, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 17 (certain other, not as frequently used callbacks are available without setting a bit here):<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|1||2||11||Wagon length<br />
|-<br />
|2||4||12||Load amount<br />
|-<br />
|3||8||15||Set refitted capacity<br />
|-<br />
|4||10||16||Build articulated vehicle<br />
|-<br />
|5||20||19||show a suffix after the cargo type name<br />
|-<br />
|6||40||2D||Select color mapping for vehicle<br />
|-<br />
|7||80||33||Sound effect callbacks<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 VarAction2 for callbacks.<br />
<br />
=== Coefficient of tractive effort (18) ===<br />
<br />
This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort. &nbsp;This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.<br />
<br />
For a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. &nbsp;If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.<br />
<br />
=== Coefficient of air drag (19) ===<br />
<br />
This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. &nbsp;00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).<br />
<br />
The default values are the following:<br />
<br />
{| |-<br />
!top speed (mph/1.6)!!&lt;16!!16!!24!!32!!48!!64!!96!!128!!192!!256!!...<br />
|-<br />
|c2||192||128||96||64||48||32||24||16||12||8<br />
|}<br />
<br />
For higher speeds, the series is continued in the same manner.<br />
<br />
Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTd's consistent scaling. &nbsp;If a vehicle doesn't reach its historical top speed, you might try setting prop. 19 one or two higher than the default above, otherwise it's probably a good idea to leave it at the default.<br />
<br />
=== Miscellaneous flags (1C) ===<br />
<br />
This is a bit mask, with the following bits:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||Vehicle is a tram/light rail vehicle and requires tram tracks to operate<br />
|-<br />
|1||2||Uses two company colors<br />
|}<br />
<br />
=== Long format introduction date (1F) ===<br />
<br />
Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect. In TTDPatch, dates after 2044 will be limited to 2044.<br />
<br />
=== Sort vehicle list (20) ===<br />
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.<br />
<br />
=== Visual effect (21) ===<br />
See the equivalent [[Action0Trains#Visual effects and wagon power 22|train property]] for information about the meaning of all bits. There is no default effect for road vehicles, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.<br />
<br />
== Example ==<br />
<br />
To be written</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Vehicles/Planes&diff=1796Action0/Vehicles/Planes2011-06-19T16:32:48Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>== Introduction ==<br />
<br />
Defining properties of planes.<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08|| ||B||Sprite (FF for new graphics)<br />
|-<br />
|09|| ||B||Is helicopter? 2=no, 0=yes<br />
|-<br />
|0A|| ||B||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)<br />
|-<br />
|0B|| ||B||Cost factor<br />
|-<br />
|0C|| ||B||Speed in mph*8<br />
|-<br />
|0D|| ||B||Acceleration<br />
|-<br />
|0E|| ||B||Running cost factor<br />
|-<br />
|0F|| ||W||Passenger capacity<br />
|-<br />
|11|| ||B||Mail capacity<br />
|-<br />
|12|| ||B||Sound effect<br />
|-<br />
|13||6||D||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]<br />
|-<br />
|14||6||B||Callback flags bit mask, see below<br />
|-<br />
|15||(a)||B||Refit cost, using 1/32 of the default refit cost base<br />
|-<br />
|16||(b)||B||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])<br />
|-<br />
|17||(c)||B||Miscellaneous vehicle flags<br />
|-<br />
|18||(c)||W||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]<br />
|-<br />
|19||(c)||W||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]<br />
|-<br />
|1A||(d)||D||Long format introduction date<br />
|-<br />
|1B||(e)||B*||Sort the purchase list<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|(a)||TTDPatch 2.0.1 alpha 30<br />
|-<br />
|(b)||TTDPatch 2.0.1 alpha 44<br />
|-<br />
|(c)||TTDPatch 2.0.1 alpha 58<br />
|-<br />
|(d)||TTDPatch 2.5 r1210, OpenTTD r7191<br />
|-<br />
|(e)||OpenTTD r13831<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Sound effect (12) ===<br />
<br />
The following sound effects are used by planes (note, the setting is ignored for helicopters):<br />
<br />
{| |-<br />
!Number!!Sound<br />
|-<br />
|06||Propeller sound 1<br />
|-<br />
|07||Jet sound 1<br />
|-<br />
|3B||Supersonic<br />
|-<br />
|3D||Jet sound 2<br />
|-<br />
|45||Propeller sound 2<br />
|-<br />
|46||Jet sound 3<br />
|}<br />
<br />
=== Callbacks (14) ===<br />
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|2||4||12||Load amount<br />
|-<br />
|3||8||15||Set refitted capacity<br />
|-<br />
|5||20||19||show a suffix after the cargo type name<br />
|-<br />
|6||40||2D||Select color mapping for vehicle<br />
|-<br />
|7||80||33||Sound effect callbacks<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 VarAction2 for callbacks.<br />
<br />
=== Miscellaneous flags (17) ===<br />
<br />
This is a bit mask, with the following bits:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||reserved, do not use<br />
|-<br />
|1||2||Uses two company colors<br />
|}<br />
<br />
=== Long format introduction date (1A) ===<br />
<br />
Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect. In TTDPatch, dates after 2044 will be limited to 2044.<br />
<br />
=== Sort vehicle list (1B) ===<br />
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.<br />
<br />
== Example ==<br />
<br />
To be written</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Stations&diff=1795Action0/Stations2011-06-19T16:32:46Z<p>Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
Defining properties of new stations.<br />
<br />
<br />
Unlike vehicles, the new stations have no equivalent in TTD. The IDs are therefore free to be chosen and will in fact be allocated automatically by the patch. In action 0, you only specify IDs relative to the set, i.e. the ID of the first station type is 00, the second station type is 01 and so on. In total, each game can only have 255 station IDs for all active grf files.<br />
The only property you '''must''' set for each station ID is 08 (in addition to defining an [[Action3|action 3]] for it), anything else can be left at the default. It must be the first property you set for each station ID, because the station ID is actually undefined until it has been assigned a class through property 08. Also, all station IDs must get their classes in the right order, starting from ID 00 onwards.<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08||a||D||Class ID, see below<br />
|-<br />
|09||b||V||Sprite layout, see below<br />
|-<br />
|0A||b||B||Copy sprite layout<br />
|-<br />
|0B||c||B||Callback flags<br />
|-<br />
|0C||c||B||Bit mask of disabled numbers of platforms<br />
|-<br />
|0D||c||B||Bit mask of disabled platform lengths<br />
|-<br />
|0E||c||V||Define custom layout, see below<br />
|-<br />
|0F||c||B||Copy custom layout from stationid given by argument<br />
|-<br />
|10||d||W||Little/lots threshold<br />
|-<br />
|11||e||B||Pylon placement<br />
|-<br />
|12||f||D||Bit mask of cargo type triggers for random sprites<br />
|-<br />
|13||f||B||General flags<br />
|-<br />
|14||g||B||Overhead wire placement<br />
|-<br />
|15||h||B||Can train enter tile<br />
|-<br />
|16||i||W||Animation information<br />
|-<br />
|17||i||B||Animation speed<br />
|-<br />
|18||i||W||Animation triggers||<br />
|-<br />
|19||-||V||Road routing (reserved for future use)<br />
|-<br />
|20||j||V||Advanced sprite layout with register modifiers (to be documented)<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|a||TTDPatch 2.0.1 alpha 19<br />
|-<br />
|b||TTDPatch 2.0.1 alpha 20<br />
|-<br />
|c||TTDPatch 2.0.1 alpha 22<br />
|-<br />
|d||TTDPatch 2.0.1 alpha 25<br />
|-<br />
|e||TTDPatch 2.0.1 alpha 27<br />
|-<br />
|f||TTDPatch 2.0.1 alpha 30<br />
|-<br />
|g||TTDPatch 2.0.1 alpha 47<br />
|-<br />
|h||TTDPatch 2.0.1 alpha 51<br />
|-<br />
|i||TTDPatch 2.5 beta 5<br />
|-<br />
|j||OpenTTD r22518<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Station class (08) ===<br />
TTDPatch groups sets of new station graphics into various classes. &nbsp;The classes can be selected by the top dropdown list in the construction window, and the individual stations within the class from the bottom dropdown list. &nbsp;In addition, each station can alter its appearance using [[VariationalAction2|variational]] and/or [[RandomAction2|random]] action 2 entries.<br />
<br />
Only two classes are pre-defined:<br />
<br />
{| |-<br />
!Name!!Class ID!!Intended use for station<br />
|-<br />
|DFLT||44 46 4C 54||Default, no special station type<br />
|-<br />
|WAYP||57 41 59 50||Non-cargo stations, waypoints, signal boxes etc.<br />
|}<br />
<br />
You may simply use other classes than the above, as long as no more than (at the moment) 16 classes are used among all active .grf files at any time.<br />
<br />
When a WAYP station is built, it will not accept cargo nor will any cargo appear from nearby industries or towns. &nbsp;Trains will not stop at WAYP stations, regardless of the non-stop order and/or the nonstop switch.<br />
<br />
=== Sprite layout (09) ===<br />
This controls what sprites are displayed, where they are displayed, and in what order. &nbsp;The property is variable sized, and contains the data for all 8 possible station tile types. &nbsp;If this property is set, the num-ent in the corresponding [[Action1|action 1]] need not be equal to 12 (hex), it can in fact be any number, and any number of sprites can be displayed in any order.<br />
<br />
The data is specified as data for all eight tiles in this way:<br />
<br />
<pre>-+&lt;num&gt; &lt;data1&gt; &lt;data2&gt; ... &lt;datan&gt;+-</pre><br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B*||num||Number of different tiles supported (see below)<br />
|-<br />
|V||data1...||The variable size data for each of the &lt;num&gt; tiles, as specified below<br />
|}<br />
<br />
===== Number of tiles supported =====<br />
* Normally this is 8, but you can specify fewer as well<br />
* Using callback flags bit 1, specifying more makes sense too<br />
* This value must be the same for all stations set by this action 0, even though it must be repeated for the prop. 09 definition of each station ID as well<br />
<br />
(Note that num is an extended byte, see [[GRFActionsDetailed]].)<br />
<br />
The content of each of the (usually eight) data sets is either a new sprite layout:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|D||groundsprite||the sprite to draw for the rails; this is by default a TTD sprite, but with bit 31 set an [[Action1|action 1]] sprite (42D+X) may be specified<br />
|-<br />
|V||spritedata||the data for station sprites, see below; each has a size of 10 bytes, and there may be several<br />
|-<br />
|B||80||a literal 80 ends the list of sprites for this tile<br />
|}<br />
or, alternatively, the instruction to use TTD's layout by using four zero bytes 00 00 00 00 instead of the groundsprite bytes. You can use [http://www.bytetransfer.de/projects/ttdpatch/docs/spriteidmapping.php the online sprite ID converter] to look up the sprite IDs you can use for all the climates. However, using presumed-to-be "unused" sprites is likely to cause incompatibilities with other sets using them and can cause crashes, so the preferred way of obtaining new sprites for ground sprites is to reserve them via [[GRFResourceManagement|GRF Resource Management]] and apply them to your action 0 with an [[Action6|action 6]] (see the example there).<br />
<br />
One can draw two types of sprites. &nbsp;One type is one that establishes a new 3D bounding box for use by the sprite sorter. &nbsp;The other type shares the 3D bounding box of the previous sprite(s). &nbsp;It must not be larger than the sprite which established the bounding box, nor must any part of it be outside this box. &nbsp;For simplicity, it should have the exact same dimensions as the sprite it shares the bounding box with. &nbsp;The latter type is supported in the station construction window display only since TTDPatch 2.6 r1684.<br />
<br />
The spritedata of sprites with their own bounding box has this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||xofs||x-offset from northern tile corner<br />
|-<br />
|B||yofs||y-offset from northern tile corner<br />
|-<br />
|B||zofs||z-offset from northern tile corner<br />
|-<br />
|B||xextent||size of sprite in x direction<br />
|-<br />
|B||yextent||size of sprite in y direction<br />
|-<br />
|B||zextent||size of sprite in z direction<br />
|-<br />
|D||sprite||sprite number to draw<br />
|}<br />
<br />
The spritedata of sprites sharing the bounding box has this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||xofs||x-offset relative to previous sprite<br />
|-<br />
|B||yofs||y-offset relative to previous sprite<br />
|-<br />
|B||80||a literal 80<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|D||sprite||sprite number to draw<br />
|}<br />
<br />
Since OpenTTD r18959 you can draw multiple ground sprites for a tile, which is useful if you want to use the usual rail/grass/concrete groundtile, but still need to add features to it without using a new bounding box. To do so use the syntax of sprites sharing the previous bounding box, but use it before the first bounding box definition. xpixeloffset and ypixeloffset refer to the usual spot of groundtiles. The same feature is also partially supported in TTDPatch since TTDPatch 2.6 r2312: TTDPatch ignores the xofs and yofs fields and always uses (0,0) for the offset. If you are developing a GRF that needs to be compatible with both OpenTTD and TTDPatch, you should always keep xofs and yofs zero to get the same effect in both games.<br />
Note however that both implementations do not consider the [[Action0Stations#General Flags 13|setting of prop13 bit 0]], hence these "multiple ground sprites" have to be always part of the building sprites set and cannot be part of the different sprite set for ground sprites.<br />
<br />
The sprite number can have the following values (remember to use little endian, i.e. reversed byte order):<br />
<br />
{| |-<br />
!Number!!Sprite<br />
|-<br />
|0000042D+X||use sprite X from the corresponding [[Action1|action 1]] block (i.e. 0000042D for the first, 0000042E for the second, etc.)<br />
|-<br />
|0000842D+X||same, but draw it using company colour translation<br />
|-<br />
|0322442D+X||same, but draw in transparent mode (actual colours of the sprite are disregarded entirely); supported in station construction window display since TTDPatch 2.6 r1683<br />
|-<br />
|RRRR842D+X||draw sprite with colour translation defined in sprite RRRR; available since TTDPatch 2.6 r1683<br />
|}<br />
<br />
With bit 31 set, this sprite will refer to a TTD sprite, not the action 1 sprite. For the first ground sprite the reverse meaning applies.<br />
<br />
Depending on the railtype the sprites may get additional offsets:<br />
<br />
{| |-<br />
! !! Normal/electrified rail !! Monorail !! Maglev<br />
|-<br />
|TTD sprites || 0 || 82 || 164<br />
|-<br />
|Action 1 sprite (first ground sprite) || 0 || 1 || 2<br />
|-<br />
|Action 1 sprite (other sprites in the layout) || 0 || 0 || 0<br />
|}<br />
<br />
So, TTD sprites and the first ground sprite are affected by the railtype, while other action 1 sprites in the layout are not. The offset "82" refers to the offset between the default TTD track sprites; if you are using non-track ground sprites which are not from an action 1, you need to supply fake spritenumbers which preemptively reverse the offsets (that is, you need different sprite layouts for every railtype your station is available for).<br />
<br />
Setting bit 30 forces this sprite to be displayed normally even in "transparent buildings" mode (supported only in TTDPatch 2.6 r1695 and later).<br />
<br />
See below for an example of linked sprites as well as transparent sprites (e.g. for a station roof).<br />
<br />
Note that the coordinates here are 3D coordinates with x running from top-right to bottom-left and y running from top-left to bottom-right, with the tile dimensions being 16x16 (and 8 for one height level). This means the x and y values should always be within 0-15 (decimal).<br />
<br />
This is different to and independent from the x/y offsets used in the actual .NFO file. &nbsp;The 3D bounding box is used by TTD's sprite sorter to figure out the order in which to draw the sprites, as well as telling it which sprites to draw, because those whose bounding box falls outside the currently updated screen rectangle will not be drawn. &nbsp;Make sure the 3D bounding box is large enough to contain the entire sprite, but not so large that the sprite sorter can't determine which sprites should be in front.<br />
<br />
This means that the order in which you specify sprites is irrelevant. &nbsp;Sprites will get drawn from back to front, in the order which the sprite sorter determines as correct, from their bounding boxes. &nbsp;There are two exceptions, however:<br />
* Sprites sharing the same bounding box will always be drawn in the given order.<br />
* The station construction window display doesn't use the sprite sorter. Tiles that may be displayed in that window need to be specified in the correct drawing order, back to front.<br />
<br />
=== Copy sprite layout (0A) ===<br />
<br />
This is not a property as such, but an action. &nbsp;It takes as argument a byte which is interpreted as station-ID to copy the custom sprite layout from.<br />
<br />
=== Callback flags (0B) ===<br />
For stations, the following [[callbacks]] can be defined by setting the corresponding bit in property 0B:<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||13||Whether to make station available in construction window (non-zero callback return) or not (callback returns zero)<br />
|-<br />
|1||2||14||Use callback to select sprite layout<br />
|-<br />
|2||4||141||Decide next animation frame<br />
|-<br />
|3||8||142||Decide animation speed<br />
|-<br />
|4||10||149||Custom slope check<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 [[VariationalAction2|VarAction2]] for callbacks.<br />
<br />
=== Selection of numbers of platforms and length (0C, 0D) ===<br />
<br />
By default all platform lengths and any number of platforms is available for the new stations. &nbsp;Using these properties, you can choose which ones should be unavailable by setting the corresponding bit in the property.<br />
<br />
The values are a byte, used as a bit mask. &nbsp;Bits 0 to 6 control the availability of number or length 1 to 7, and bit 7 controls the availability of the "+7" button. &nbsp;Each bit that is set disables the corresponding length or number of platforms.<br />
<br />
For compatibility with "largestations off", at least one length between 1 and 5 (bits 0 to 4) and one number of platforms between 1 and 4 (bits 0 to 3) must be available, i.e. at least one of these bits must be unset.<br />
<br />
=== Define custom layout (0E) ===<br />
<br />
This allows choosing which tile type is built at which tile of a newly built<br />
<br />
station. &nbsp;There are four different types, which TTD normally defines as<br />
<br />
{| |-<br />
!Tile type!!Appearance<br />
|-<br />
|00||plain platform<br />
|-<br />
|02||platform with building<br />
|-<br />
|04||platform with roof, left side<br />
|-<br />
|06||platform with roof, right side<br />
|}<br />
<br />
These numbers are used for stations in NE-SW direction, or these numbers plus one for stations in the NW-SE direction. &nbsp;To define a custom layout, use this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||length||length of platforms for this layout<br />
|-<br />
|B||number||number of platforms for this layout<br />
|-<br />
|V||tiles||length*number bytes of tile types, one platform after another, only 00, 02, 04 or 06 are allowed as values<br />
|}<br />
<br />
Repeat this as often as necessary to define the layouts for all supported combinations of length and number. &nbsp;End the definitions with a 00 00 (zero length and zero number). &nbsp;Any combinations that are not defined will be built using TTD's default layout.<br />
Note that it may be easier to draw different sprite sets using a [[VariationalAction2|VarAction2]] based on [[VarAction2Stations#Platform info 40 41 46 47 49|station variable 40]], rather than redefining the layout. &nbsp;In addition, [[Callbacks#Custom station layout 24|callback 24]] will be used to further customize the layout as defined by this property (or by TTD if no prop 0E layout is available). This may also be easier than defining a prop 0E layout for every combination of length and number of platforms.<br />
<br />
=== Copy custom layout (0F) ===<br />
<br />
Similar to property 0A, this copies the custom layout from the station-ID given by the argument.<br />
<br />
=== Little/lots threshold (10) ===<br />
Amount of cargo for switching from "little" to "lots" of cargo. &nbsp;TTDPatch separates the full range of cargo amounts (0 to 4095) into two separate subranges, "little" and "lots" of cargo. &nbsp;This allows better control of cargo amount based graphics (if needed). &nbsp;Property 10 specifies at what amount of cargo the patch is to switch from one to the other subrange. &nbsp;See [[Action2Stations|Action 2 for stations]] for more information.<br />
<br />
=== Pylon placement (11) and wire placement (14) ===<br />
Prop. 11 sets which tile types should have pylons when used with electrified tracks. By default, tiles 4-7 have pylons, and tiles 0-3 don't. This is a bit mask of tile types, with a bit set meaning that a pylon should be drawn. The tile types here do not consider [[Callbacks#Station sprite layout 14|callback 14]], but rather the type as it was built, i.e. from prop. 0E.<br />
<br />
Prop. 14 works in a similar way, except that it sets the tile types on which there should be ''no'' wires displayed. With the default value of "00", wires are displayed everywhere, and for each bit set, the wire is omitted on that tile type.<br />
<br />
This property should only be used when the wires cause problems with the sprite sorter, because even when the wire is obscured by a station hall or similar, it should still show up in transparent mode so that each tile can easily be verified as being electrified.<br />
<br />
=== Cargo types for random triggers (12) ===<br />
<br />
This sets which cargo types should trigger re-randomizing. The cargo types are given as a bitmask of the bits from column 3 (type B) in CargoTypes. &nbsp;If nothing is set (the default), the no random triggers will happen, to conserve CPU time.<br />
<br />
=== General Flags (13) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||use different sprite set for ground sprites (var. 10 is 1 for ground sprites, 0 otherwise)<br />
|-<br />
|1||2||when calculating the cargo amount to display, divide the amount by the station size (to simulate cargo distributed over the area of the station)<br />
|-<br />
|2||4||[[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] needs random bits in var. 10<br />
|-<br />
|3||8||Use custom foundations on sloped tiles (the lowest byte of var. 10 is 2 for foundation sprites)<br />
|-<br />
|4||10||When bit 3 is set, use extended foundation block instead of the simple one<br />
|}<br />
<br />
Bit 3 works somewhat similarly to bit 0: your sprite selection will be called again, with 2 in the lowest byte of variable 10. If the chain ends on a callback result, the programme will assume the foundation selection has failed and will use the default foundaton sprites. The low word of variable 18 will contain the tile type of the current tile; if you have [[Callbacks#Station sprite layout (14)|callback 14]] enabled, this will be the its return value - otherwise, the default TTD types (platform with building, platform with left roof etc.) are used. In either case, one is added for the NW-SE orientation, in case your station needs different foundations depending on its orientation. Bits 16 and 17 are set if the NW and and NE foundations are to merged with the corresponding neighbour tile, so you shouldn't draw the corresponding edge in the foundation sprite. Other bits of variable 10 and variable 18 are reserved for future use.<br />
<br />
Your sprite selection code should select a foundation sprite block. The contents of this block depends on whether bit 4 is set or not.<br />
* Bit 4 clear (simple foundations):<br />
[[File:simple_foundations.png]]<br />
<br />
The programme will combine the needed foundation from these 8 sprites depending on the current slope. You don't need to care about the merge data in bits 16..17 of variable 18; it will be taken care of that automatically by adding the 7th and 8th sprite only when necessary.<br />
* Bit 4 set (extended foundations):<br />
[[File:extended_foundations.png]]<br />
<br />
You need to have one sprite for every slope that's possible below a rail station. The correct one will be automatically selected depending on the current slope. It can't handle the merging itself, however, so you need four foundation blocks: one with no edges removed, one with the NW edge removed, one with the NE edge removed and one with both north edges removed. Your sprite selection code is responsible for selecting the correct of those blocks according to the merge info in variable 18.<br />
<br />
In both cases, you can put an additional value into register 100h, which will serve as an offset into the selected block. If you don't modify register 100h during the chain, it will default to 0. It is important that the dimensions of these sprites remain the same - thus bit 6 in the real sprites must be set to prevent trimming the empty blue areas. The offset of these foundations must be -31 to the X direction and -9 to the Y direction.<br />
<br />
=== Can train enter tile (15) ===<br />
<br />
Like props. 11 and 14, this value contains eight bits relating to the eight possible tile types. If a bit is set, trains are prevented from routing through or entering any tile of this type.<br />
<br />
=== Animation information (16) ===<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 station (this is the default value).<br />
Since you can't have properties for individual station tiles, this property applies for every tile of the station. If you don't want to animate some tiles, you should check the current position during [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]] and return FD if the current tile doesn't need to be animated. If you also need animations of different length per tile, you'll have to use [[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] for that.<br />
<br />
=== Animation speed (17) ===<br />
The meaning is the same as for [[Action0Houses#Animation Speed 1B|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 />
=== Animation triggers (18) ===<br />
This is a bit mask of events that should trigger [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]], allowing to change the animation state<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning!!Happens on<br />
|-<br />
|0||1||Station part is built||the newly built tiles<br />
|-<br />
|1||2||New cargo arrives to station||whole station<br />
|-<br />
|2||4||A cargo type gets removed from station||whole station<br />
|-<br />
|3||8||Train enters station (starts loading/unloading)||platform where the train is<br />
|-<br />
|4||10||Train leaves station (done loading/unloading)||platform where the train is<br />
|-<br />
|5||20||Train loads/unloads cargo||platform where the train is<br />
|-<br />
|6||40||Every 250 ticks||whole station<br />
|}<br />
<br />
The remaining bits are reserved for future triggers, they must be zero for now.<br />
<br />
The "happens on" column tells which tiles will [[Callbacks#Animation control (1B/25/140/152/159) |callback 140]] be called on.<br />
<br />
Triggers 1 and 2 put extra information to bits 8..15 of variable 18: the cargo type in question. If your GRF has a cargo translation table, the cargo type will be an index in that table, or FFh if the cargo isn't in the table. If you don't have a cargo translation table, the cargo type will simply be the climate-dependent cargo type number.<br />
<br />
=== Road routing (19 - reserved for future use) ===<br />
<br />
Will allow to have routing informations for road vehicles on rail stations,<br />
<br />
generally you need to deny rail vehicle traveling via prop 15<br />
<br />
== Examples ==<br />
<br />
=== Using TTD's sprite layouts for certain tiles ===<br />
<br />
To use TTD's layout, you use <code>00 00 00 00</code> for the ground sprite number and leave off everything else.<br />
<br />
So instead of for example<br />
<br />
F4 03 00 00<br />
00 00 00 10 05 02 2E 84 00 00<br />
00 0B 00 10 05 02 30 84 00 00<br />
80<br />
<br />
you just put<br />
<br />
00 00 00 00<br />
<br />
=== Using transparent sprites ===<br />
<br />
You can use transparent sprites to make for example the roof translucent like in TTD's stations. The roof of TTD's stations is made like this:<br />
<br />
00 00 10 10 10 0A 37 84 00 00<br />
00 00 80 00 00 00 3B 44 22 03<br />
<br />
The first sprite here is the non-transparent frame of the roof, drawn in company colours (it has bit 15 set). The second part is a special "linked" sprite without its own bounding box, it shares that of the previous sprite. That's done by setting the z offset to 80.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Houses&diff=1794Action0/Houses2011-06-19T16:31:59Z<p>Pm-bot: Bot: Automated text replacement (-action 2 +Action2)</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 Action2 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 Action2, 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>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2/Vehicles&diff=1793VariationalAction2/Vehicles2011-06-19T16:31:22Z<p>Pm-bot: Bot: Automated text replacement (-var.action 2 +VarAction2)</p>
<hr />
<div>==Introduction==<br />
<br />
== Variables ==<br />
<br />
{|<br />
!Variable!!Version!![[GRFActionsDetailed|Size]]!!Description!!Available in purchase list<br />
|+<br />
|40||||D||Position in consist and length of consist||no<br />
|+<br />
|41||||D||Position in and length of chain of consecutive vehicles with same ID||no<br />
|+<br />
|42||||D||Cargo types transported by consist||no<br />
|+<br />
|43||||D||Player info||TTDPatch 2.5 beta 2, OpenTTD r4611<br />
|+<br />
|44||||D||Aircraft info||no<br />
|+<br />
|45||||D||Curvature info||no<br />
|+<br />
|46||||D||Motion counter||no<br />
|+<br />
|47||||D||Vehicle cargo info||(b) OpenTTD r15542<br />
|+<br />
|48||||D||Vehicle type information||TTDPatch 2.5 beta 2, OpenTTD r5338<br />
|+<br />
|49 (a)||||D||Year of construction (long format, 0 based)||(c) OpenTTD r13376<br />
|+<br />
|4A (d)||||D||Info about current rail type for trains||no<br />
|+<br />
|60||||D||Count Veh.ID occurence||no<br />
|+<br />
|97||||B||Tick counter, increased every engine tick||no<br />
|+<br />
|B4||||W||Current speed. Note, units differ for each vehicle type (e).||no<br />
|+<br />
|B9||||B||Cargo type (type B from the list at [[CargoTypes]]; climate dependent)||no<br />
|+<br />
|C0||||W||Vehicle age in days (not valid for wagons bought before alpha 61)||no<br />
|+<br />
|C4||||B||Year built (counted from 1920), note this is modified when Cht: Year is used||(c) OpenTTD r4611<br />
|+<br />
|C6||||W||Vehicle type ID (useful for [[Callbacks#Can wagon be attached (1D)|Callback 1D]])||no<br />
|+<br />
|C8||||B||Sprite type; FD for trains forward, FE or FF when reversed||no<br />
|+<br />
|C9||||B||Day counter; increased daily||no<br />
|+<br />
|DA||||W||Next wagon index, FFFF if last wagon (use shift-num=08 and check for FF)||no<br />
|+<br />
|F2||||B||Refit cycle, how many times refitted to the same cargo type||(b) OpenTTD r15542<br />
|+<br />
|FE||||W||Modflags||no<br />
|+<br />
|FF||||B||Modflags||no<br />
|}<br />
<br />
(a) OpenTTD r13376, TTDPatch r2216<br />
<br />
(b) Variable 47 refers to the default cargo of the vehicle, when in purchase list. This differs from the cargo used in Action 3, which is 0xFF in purchase list. The "refit cycle" (F2) is currently always zero in the purchase list.<br />
<br />
(c) This is the current date.<br />
<br />
(d) OpenTTD r20165.<br />
<br />
(e) See [[Action0Trains#Speed 09|train property 09]], [[Action0RoadVehicles|road vehicle property 08]] (not 15, even when using realistic acceleration), [[Action0Ships|ship property 0B]] and [[Action0Planes|aircraft property 0C]].<br />
<br />
For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_VehicleArray|TTD vehicle structure].<br />
<br />
Variables 40, 41, 42 and 43 are cached. This means that while they are in principle computationally expensive, they can be used without impacting performance. Variables 45 and 60 are also computationally expensive but cannot be cached, and should therefore be used sparingly. If possible 80+x variables are to be preferred.<br />
<br />
Cached variables are updated when the game is loaded, when the consist enters or is rearranged in a depot, and when the train reverses.<br />
<br />
In the purchase list only a few variables are available. Especially the front vehicle (related object) cannot be accessed, nor other articulated parts.<br />
<br />
== Description ==<br />
=== Position and length (40, 41) ===<br />
<br />
'''Format:''' 00nnbbff<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|ff||position of vehicle within the consist counted from the engine (front), e.g. the engine would have ff=0, the 1st wagon or mail compartment of planes would have ff=1, the 2nd wagon or the rotor of helicopters would have ff=2, the 3rd wagon would have ff=3 etc<br />
|-<br />
|bb||same as ff, but counted from the end, i.e. the last wagon has bb=0, the next-to-last wagon has bb=1 etc.<br />
|-<br />
|nn||total number of vehicles in the consist minus one (i.e. a train with engine and three wagons has nn=3), including shadow and rotor for aircraft.<br />
|}<br />
<br />
For variable 40, these numbers refer to the whole consist, but for variable 41, they only refer to the chain of consecutive vehicles with the same ID as the current wagon (including itself, but possibly excluding the engine):<br />
<br />
[[File:vehicle_var40_41.png]]<br />
<br />
Note however, that accessing the "related" object (i.e. the locomotive) doesn´t make much sense for vars 40/41, except for var40 when in a [[Callbacks#Can wagon be attached 1D|callback 1D]] chain.<br />
<br />
=== Consist cargo (42) ===<br />
<br />
'''Format:''' uuiicctt<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|tt||a bit mask of all [[Action0Cargos#Cargo classes 16|cargo classes]] transported by the consist<br />
|-<br />
|cc||the most common [[CargoTypes|cargo type]] (from the column for type A)<br />
|-<br />
|ii||the most common refit cycle (var. F2) of cargo type cc<br />
|-<br />
|uu||the result of ORing the bits of prop. 25 from all vehicles in the train<br />
|}<br />
<br />
Note that even if the grf file has installed a [[Action0GeneralVariables#Cargo+translation+table+(09)|cargo translation table]], the value in "cc" is the actual bit number of that cargo. The reason for this is that it cannot be translated in general, because different vehicles can be from different .grf files and have different translation tables. Use variable 47 if you want the translated cargo type.<br />
<br />
If used with variational action 2 type 81 (vehicle) it returns only cargo from this vehicle on, with type 82 (engine) that of the whole consist.<br />
<br />
=== Player info (43) ===<br />
<br />
'''Format:''' Ccttmmnn<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|nn||the number of the current player from 0 to 7 (up to E (14) in OpenTTD since r14735)<br />
|-<br />
|mm||the multiplayer player number with the host player (or the single player) being 0 and the client player being 1<br />
|-<br />
|tt||the player type, see below for possible values<br />
|-<br />
|c||the primary player colour<br />
|-<br />
|C||the secondary player colour, equal to c if none (since r1405)<br />
|}<br />
<br />
<br />
{| |-<br />
!tt value!!Meaning<br />
|-<br />
|0||Player is human player (permanent company)<br />
|-<br />
|1||Player is AI player (not managed)<br />
|-<br />
|2||Player is a human managing an AI company<br />
|-<br />
|3||Player is human player's original company, now temporarily AI controlled<br />
|}<br />
<br />
This variable is available in the purchase list as well (since TTDPatch 2.5 beta 2).<br />
<br />
Since r1497, when the vehicle sprite is being displayed in an exclusive offer window or new vehicle news message, or in other circumstances when no player is associated with the vehicle, nn will be FF.<br />
<br />
=== Aircraft info (44) ===<br />
<br />
'''Format:''' xxxxhhtt<br />
<br />
(available from TTDPatch 2.0.1 alpha 48)<br />
<br />
hh is the height of the aircraft above ground, or more properly above the height of its shadow. Buildings, including the heliport, don't count as "ground", i.e. to get the height above a heliport, you have to subtract the heliport height from hh.<br />
<br />
tt is the type of the current airport: 0=small, 1=large, 2=heliport, 3=oil rig. The current airport is the target airport for aircraft that have finished the ascent and are in flight.<br />
<br />
=== Curvature info (45) ===<br />
<br />
'''Format:''' xxxTxBxF<br />
<br />
(available from TTDPatch 2.0.1 alpha 58)<br />
<br />
This returns the amount of curvature between the adjacent wagon pairs. It is useful for train vehicles that normally tilt in curves. The curvature is the difference in direction between the surrounding vehicles:<br />
<br />
F = for the front pair (previous wagon to current wagon, 0 if vehicle is first)<br />
<br />
B = for the back pair (current wagon to next wagon, 0 if wagon is last)<br />
<br />
T = for the triplet (previous wagon to next wagon; is zero in an S-bend)<br />
<br />
Possible values:<br />
<br />
{| |-<br />
!Decimal!!Hex!!Meaning<br />
|-<br />
|-4||C||180° curve left (T only)<br />
|-<br />
|-3||D||135° curve left (T only)<br />
|-<br />
|-2||E||90° curve left<br />
|-<br />
|-1||F||45° curve left<br />
|-<br />
|0||0||no curve<br />
|-<br />
|1||1||45° curve right<br />
|-<br />
|2||2||90° curve right<br />
|-<br />
|3||3||135° curve right (T only)<br />
|-<br />
|4||4||180° curve right (T only)<br />
|}<br />
<br />
=== Motion counter (46) ===<br />
<br />
'''Format:''' 32-bit value<br />
<br />
(available from TTDPatch 2.0.1 alpha 59)<br />
<br />
This variable counts the amount of motion that a vehicle has done. &nbsp;It is only valid for the first vehicle in a consist (i.e. use VarAction2 type 82!). &nbsp;Its value is in units of 1/4096 of a tile. &nbsp;A vehicle actually moves visibly every time the motion counter increases by 256, and since a tile consists of 16 such subunits, 16*256=4096 motion units mean motion across one tile.<br />
<br />
The most useful way to access it is probably with &lt;shiftnum&gt;=08 and an appropriate &lt;andmask&gt;. &nbsp;For example, to achieve an animation with one frame per vehicle motion and 16 frames in total for motion across an entire tile, you would use &lt;shiftnum&gt;=08 and &lt;andmask&gt;=0F. &nbsp;For an animation with one frame every two vehicle motions and 4 frames total, use &lt;shiftnum&gt;=09 and &lt;andmask&gt;=03.<br />
<br />
If the vehicle is going very fast (&gt;160 mph for trains), it may move by several 1/16ths of a tile at once, and thus some frames may be skipped, but the animation will still remain in sync with the motion.<br />
<br />
Note that vehicle graphics are only updated every time the vehicle actually moves, so checking the lower byte is probably pointless, and only needed internally to achieve sufficient precision.<br />
<br />
=== Vehicle cargo info (47) ===<br />
<br />
'''Format:''' ccccwwtt<br />
<br />
{| |-<br />
!Variable!!Value<br />
|-<br />
|tt||the [[CargoTypes|cargo type]] transported by the vehicle (from the column for type A); translated if a translation table has been installed<br />
|-<br />
|ww||cargo unit weight in 1/16 tons, same as [[Action0Cargos#Weight of one unit of the cargo 0F|cargo prop. 0F]]<br />
|-<br />
|cccc||the [[Action0Cargos#Cargo classes 16|cargo class]] value of the cargo transported by the vehicle<br />
|}<br />
|-<br />
|Note that if the grf has installed a [[Action0GeneralVariables#Cargo translation table 09|cargo translation table]], the value in "tt" is the slot number in that table, irrespective of which actual slot or bit the cargo is using in the game. If a table has been installed, but the current cargo is not listed there, "tt" will be set to FF.<br />
<br />
Unlike variable 42, this variable returns the info of the current vehicle only, not the consist.<br />
<br />
=== Vehicle type information (48) ===<br />
<br />
'''Format:''' xxxxxxff<br />
<br />
The bits of ff are:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||Vehicle type is available on the market<br />
|-<br />
|1||2||Vehicle type is in the testing phase<br />
|-<br />
|2||4||Exclusive testing offer for a human player active<br />
|}<br />
<br />
All other bits in ff are undefined and must be masked out.<br />
<br />
This variable is available in the purchase list as well (since TTDPatch 2.5 beta 2).<br />
<br />
=== Information about current rail type for trains (4A) ===<br />
<br />
'''Format:''' xxxxFFrr<br />
<br />
(available from OpenTTD r20165)<br />
<br />
The lower byte (rr) contains the (translated) rail type the train vehicle is currently driving on. If the rail type has no entry in the rail type translation table of the GRF, this value will be 0xFF. If no translation table is present, the raw value will be returned.<br />
<br />
The next byte (FF) contains the following flags:<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||The vehicle is/would be powered on the current rail type (this is independent from powered/non-powered wagon or anything)<br />
|}<br />
<br />
All other bits are undefined.<br />
<br />
All other bytes and the result for non-rail vehicles are undefined.<br />
<br />
=== Count Veh.ID occurence (60) ===<br />
<br />
'''Format:''' xxxxxxnn<br />
<br />
(available from TTDPatch 2.0.1 alpha 57)<br />
<br />
The 60+x parameter is the vehicle ID to look for, and the returned nn is the number of vehicles in the consist that have this ID. If used with VarAction2 type 81, only the current vehicle and onwards will be check, with VarAction2 type 82, all vehicles in the consist will be counted.<br />
<br />
=== Modflags (FE and FF) ===<br />
<br />
The bits in FE mostly relate to gradualloading. &nbsp;A few useful bits for grf authors are;<br />
<br />
{| |-<br />
!Bit!!Value of the bit<br />
|-<br />
|5||Vehicle is powered (engine or powered wagon, mainly useful for the latter)<br />
|-<br />
|6||Vehicle would be powered (engine or powered wagon) if there were suitable track. (E.g. electric train in mixed train on normal track)<br />
|-<br />
|8 *||This bit is flipped every time the train reverses direction<br />
|-<br />
|10||Vehicle was built during the exclusive preview (since TTDPatch 2.5 r1334)<br />
|}<br />
<br />
<nowiki>*</nowiki> This bit is only accurate for the first vehicle in the consist.<br />
<br />
variable FF is actually the high byte of variable FE, so FE bit 8 is the same as FF bit 0.<br />
<br />
==Examples==</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VariationalAction2&diff=1792VariationalAction22011-06-19T16:31:20Z<p>Pm-bot: Bot: Automated text replacement (-var.action 2 +VarAction2)</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 "related" 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 "related" 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 OpenTTD 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, TTDPatch 2.6 r2049<br />
|-<br />
|24||D||current year; long format, year zero based since OpenTTD r13376, TTDPatch 2.6 r2049<br />
|-<br />
|25||D||GRFID of the grf that contains the corresponding Action3. Useful when accessing the "related" 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, TTDPatch 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 TTDPatch 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 TTDPatch 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 VarAction2]]<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 TTDPatch 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>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=VarAction2Advanced&diff=1791VarAction2Advanced2011-06-19T16:31:12Z<p>Pm-bot: Bot: Automated text replacement (-var.action 2 +VarAction2)</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 TTDPatch 2.6 r1246. See [[Storages#Temporary storage|Temporary storage]].<br />
|-<br />
|0F||\2r or \2rst (a)||result = val2||Available since TTDPatch 2.6 r1246<br />
|-<br />
|10||\2psto (c)||var7C[val2] = val1, result = val1||Store result into persistent storage, available since TTDPatch 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 TTDPatch 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 TTDPatch 2.6 r1698 (*)<br />
|-<br />
|13||\2ucmp (c)||see notes||The same as 12, but operands are considered unsigned. Available since TTDPatch 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 TTDPatch 2.0.1 alpha 59, it is possible to access variables using both VarAction2 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 VarAction2 and makes it available to the next VarAction2 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 VarAction2, 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 TTDPatch 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 VarAction2, 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 VarAction2 in both the <set-id> and <default> positions.<br />
<br />
=== Using procedures ===<br />
<br />
When the variable in a VarAction2 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 VarAction2 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, VarAction2s 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 VarAction2. It is however valid to use any type of VarAction2, 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 "normal" chains.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=DebuggingGRFCode&diff=1790DebuggingGRFCode2011-06-19T16:31:08Z<p>Pm-bot: Bot: Automated text replacement (-var.action 2 +VarAction2)</p>
<hr />
<div>== Introduction ==<br />
<br />
For the most part, writing NFO code, especially VarAction2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.<br />
<br />
OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: [http://wiki.openttd.org/NewGRF_Debugging| OpenTTD NewGRF debugging]<br />
<br />
TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.<br />
<br />
To activate the debugger, use the sign cheat "Cht: grfdebug 1 [<feature> [<id> [<callback>]]]".<br />
<br />
The "1" is there to activate the debugger. This creates a file "grfdebug.log" (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to "invalid parameter", it means the file "grfdebug.log" could not be created, possibly because a file of the same name exists but is not writable. If it fails with "unknown cheat", the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).<br />
<br />
For instance, "Cht: grfdebug 1 1 255 18" logs [[Callbacks#Load amount callback 12|callback 12]] (load amount, decimal 18) for all road vehicles.<br />
<br />
Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.<br />
<br />
When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250|tool] to parse the "grfdebug.log" file into a more descriptive text file.<br />
<br />
GET cccciiff <GRFID><br />
<br />
Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given GRFID is the one owning the action 3 in question.<br />
<br />
ACT2 <sprite> 00000000<br />
<br />
When processing a regular, random or variational action 2. The sprite number is the sprite number in the .NFO file minus one, given in hex.<br />
<br />
RND <value> <rndbits><br />
<br />
In a random action 2, the random value is <value> with <rndbits> being the bits used to choose the next action 2.<br />
<br />
VAR <value> <adjusted><br />
<br />
In a variational action 2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the VarAction2 type.<br />
<br />
RSLT <result> 00000000<br />
<br />
A callback result has been computed. When not in a callback, this causes the sprite determination to fail and default sprites to be used.<br />
<br />
SPRT <sprite> 00000000<br />
<br />
A sprite number has been computed. When in a callback, this causes the callback to fail if it isn't following a RSLT line indicating a valid callback result.<br />
<br />
Since the value is mapped into TTD's sprite number space, it is not directly related to sprite numbers in the NFO file. To translate the returned sprite number to an action 1 block sprite, it is necessary to have this grf file be loaded first in newgrf(w).cfg. Then the sprite numbers of action 1 blocks will be allocated consecutively starting from the base number (see below) for each feature.<br />
<br />
{|<br />
!Feature!!Base number<br />
<br />
|-<br />
|other||1324 (4900) Note: this includes all features not listed below as well as GRM sprite allocations<br />
<br />
|-<br />
|Trains||4000 (16384)<br />
<br />
|-<br />
|Road vehicles||6CDC (27868)<br />
<br />
|-<br />
|Aircraft||99B8 (39352)<br />
<br />
|-<br />
|Ships||BBCD (48077)<br />
<br />
|-<br />
|Houses||DDE2 (56802)<br />
|}<br />
<br />
The feature-specific base numbers are only valid if the extended sprite limit is active, otherwise all features use the "other" base number.<br />
<br />
For instance, the first sprite block of 32 (20 hex) sprites for a road vehicle would start at sprite 6CDC, then the following sprite block would start at 6CDC+20=6CFC.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action2/Vehicles&diff=1762Action2/Vehicles2011-06-18T09:07:24Z<p>Pm-bot: Bot: Automated text replacement (--= +==)</p>
<hr />
<div>== Introduction ==<br />
<br />
= Action 2 =<br />
<br />
Defining set-IDs for vehicles.<br />
<br />
<br />
For features 0, 1, 2 and 3 (vehicles), action2 is mainly used to define sets of sprites that show one vehicle in various states of load for one particular type of cargo.<br />
<br />
==Syntax==<br />
<br />
For vehicles, the data looks as follows:<br />
<br />
<Sprite-number> * <Length> 02 <veh-type> <set-id> <num-loadtypes> <num-loadingtypes> <loadtypes...><br />
<br />
{|<br />
!Element!![[GRFActionsDetailed|Size]]!!Description<br />
<br />
|-<br />
|<Sprite-number>||dec||A sequential sprite number<br />
<br />
|-<br />
|<length>||dec||The total number of bytes used in this action<br />
<br />
|-<br />
|02||B||Defines an action2<br />
<br />
|-<br />
|<veh-type>||B||For what type of vehicle should the following sprites be used?<br />
<br />
|-<br />
|<set-id>||B||Set-ID of this action2<br />
<br />
|-<br />
|<num-loadtypes>||B||Number of different states while moving<br />
<br />
|-<br />
|<num-loadingtypes>||B||Number of different states while loading/unloading<br />
<br />
|-<br />
|<loadtypes>||W||Sets from the most recent action1 to use for various states of loading.<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 />
=== veh-type ===<br />
<br />
This sets the type of vehicle 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 />
=== Set-id ===<br />
<br />
This is the number that you give this set of sprites. You can choose any value between 00 and FF, and you can reuse them within a grf file at a later point (if being equal to an existing set-ID, the existing one is overwritten and the new one is used).<br />
<br />
=== num-loadtypes ===<br />
<br />
This is the number of different graphics that the vehicle has while it's not loading or unloading, depending on the amount of cargo it carries. For example, if it has two states, full or empty, this would be 02. If it has three states, full, half full or empty, this would be 03.<br />
<br />
=== num-loadingtypes ===<br />
<br />
Same as num-loadtypes, except this is used while the vehicle is loading or unloading. For example if the vehicle is closed, it might only have one state when moving (i.e. num-loadtypes is 01), but show several load states when it is being loaded or unloaded and thus open.<br />
<br />
Neither num-loadtypes nor num-loadingtypes may be zero, there must be at least one state for each.<br />
<br />
=== loadtypes ===<br />
<br />
The sprite sets to use for the states of load. Each entry is a '''WORD''' value in little endian format, and refers to the most recent action1 sets. For example, action1 sets 4, 5 and 7 would be encoded as -+04 00+-, -+05 00+- and -+07 00+-, respectively. Note the additional 00 which is needed because it must be a word value here.<br />
<br />
The first entries of these are used when not loading. There have to be num-loadtypes of these. After this follow the sets to use while loading/unloading, and there must be num-loadingtype of those.<br />
<br />
Note that you can share action1 sets between several action2 entries. For example, you might have a wagon that can hold coal or iron ore, and it would look the same if it's empty. Then the empty sprite set could be shared by the action2 entries for iron ore and coal.<br />
<br />
== Notes ==<br />
<br />
Do not skip an action2 using action9 (unless it skips the whole file). Action2 must not be skipped by action9 or the patch will most likely crash. Skip or modify action3 instead. Skipping an action2 with an action7 has no effect.<br />
<br />
If there is only one load type, it is shown for all loads.<br />
<br />
If there are two load types, the first is shown below 50%, the other above 50%. If there are three load types, they are shown above/below 33% and 66%. If there are four load types, they are shown above/below 25%, 50% and 75%, etc.<br />
<br />
= Example =<br />
<br />
<span style='color:#808080'>Something to go here</span></div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Stations&diff=1618Action0/Stations2011-06-16T19:28:02Z<p>Pm-bot: Bot: Automated text replacement (-Callbacks#Animation control 1B 25 140 +Callbacks#Animation control (1B/25/140/152/159), -Callbacks#Next animation frame 1A 26 141 +Callbacks#Next animation frame (1A/26/141/153/158))</p>
<hr />
<div>==Introduction==<br />
<br />
Defining properties of new stations.<br />
<br />
<br />
Unlike vehicles, the new stations have no equivalent in TTD. The IDs are therefore free to be chosen and will in fact be allocated automatically by the patch. In action 0, you only specify IDs relative to the set, i.e. the ID of the first station type is 00, the second station type is 01 and so on. In total, each game can only have 255 station IDs for all active grf files.<br />
The only property you '''must''' set for each station ID is 08 (in addition to defining an [[Action3|action 3]] for it), anything else can be left at the default. It must be the first property you set for each station ID, because the station ID is actually undefined until it has been assigned a class through property 08. Also, all station IDs must get their classes in the right order, starting from ID 00 onwards.<br />
<br />
== Properties ==<br />
<br />
{| |-<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08||a||D||Class ID, see below<br />
|-<br />
|09||b||V||Sprite layout, see below<br />
|-<br />
|0A||b||B||Copy sprite layout<br />
|-<br />
|0B||c||B||Callback flags<br />
|-<br />
|0C||c||B||Bit mask of disabled numbers of platforms<br />
|-<br />
|0D||c||B||Bit mask of disabled platform lengths<br />
|-<br />
|0E||c||V||Define custom layout, see below<br />
|-<br />
|0F||c||B||Copy custom layout from stationid given by argument<br />
|-<br />
|10||d||W||Little/lots threshold<br />
|-<br />
|11||e||B||Pylon placement<br />
|-<br />
|12||f||D||Bit mask of cargo type triggers for random sprites<br />
|-<br />
|13||f||B||General flags<br />
|-<br />
|14||g||B||Overhead wire placement<br />
|-<br />
|15||h||B||Can train enter tile<br />
|-<br />
|16||i||W||Animation information<br />
|-<br />
|17||i||B||Animation speed<br />
|-<br />
|18||i||W||Animation triggers||<br />
|-<br />
|19||-||V||Road routing (reserved for future use)<br />
|-<br />
|20||j||V||Advanced sprite layout with register modifiers (to be documented)<br />
|}<br />
<br />
Version codes:<br />
<br />
{| |-<br />
!Code!!Version<br />
|-<br />
|a||TTDPatch 2.0.1 alpha 19<br />
|-<br />
|b||TTDPatch 2.0.1 alpha 20<br />
|-<br />
|c||TTDPatch 2.0.1 alpha 22<br />
|-<br />
|d||TTDPatch 2.0.1 alpha 25<br />
|-<br />
|e||TTDPatch 2.0.1 alpha 27<br />
|-<br />
|f||TTDPatch 2.0.1 alpha 30<br />
|-<br />
|g||TTDPatch 2.0.1 alpha 47<br />
|-<br />
|h||TTDPatch 2.0.1 alpha 51<br />
|-<br />
|i||TTDPatch 2.5 beta 5<br />
|-<br />
|j||OpenTTD r22518<br />
|}<br />
<br />
== Descriptions ==<br />
<br />
=== Station class (08) ===<br />
TTDPatch groups sets of new station graphics into various classes. &nbsp;The classes can be selected by the top dropdown list in the construction window, and the individual stations within the class from the bottom dropdown list. &nbsp;In addition, each station can alter its appearance using [[VariationalAction2|variational]] and/or [[RandomAction2|random]] action 2 entries.<br />
<br />
Only two classes are pre-defined:<br />
<br />
{| |-<br />
!Name!!Class ID!!Intended use for station<br />
|-<br />
|DFLT||44 46 4C 54||Default, no special station type<br />
|-<br />
|WAYP||57 41 59 50||Non-cargo stations, waypoints, signal boxes etc.<br />
|}<br />
<br />
You may simply use other classes than the above, as long as no more than (at the moment) 16 classes are used among all active .grf files at any time.<br />
<br />
When a WAYP station is built, it will not accept cargo nor will any cargo appear from nearby industries or towns. &nbsp;Trains will not stop at WAYP stations, regardless of the non-stop order and/or the nonstop switch.<br />
<br />
=== Sprite layout (09) ===<br />
This controls what sprites are displayed, where they are displayed, and in what order. &nbsp;The property is variable sized, and contains the data for all 8 possible station tile types. &nbsp;If this property is set, the num-ent in the corresponding [[Action1|action 1]] need not be equal to 12 (hex), it can in fact be any number, and any number of sprites can be displayed in any order.<br />
<br />
The data is specified as data for all eight tiles in this way:<br />
<br />
<pre>-+&lt;num&gt; &lt;data1&gt; &lt;data2&gt; ... &lt;datan&gt;+-</pre><br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B*||num||Number of different tiles supported (see below)<br />
|-<br />
|V||data1...||The variable size data for each of the &lt;num&gt; tiles, as specified below<br />
|}<br />
<br />
===== Number of tiles supported =====<br />
* Normally this is 8, but you can specify fewer as well<br />
* Using callback flags bit 1, specifying more makes sense too<br />
* This value must be the same for all stations set by this action 0, even though it must be repeated for the prop. 09 definition of each station ID as well<br />
<br />
(Note that num is an extended byte, see [[GRFActionsDetailed]].)<br />
<br />
The content of each of the (usually eight) data sets is either a new sprite layout:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|D||groundsprite||the sprite to draw for the rails; this is by default a TTD sprite, but with bit 31 set an [[Action1|action 1]] sprite (42D+X) may be specified<br />
|-<br />
|V||spritedata||the data for station sprites, see below; each has a size of 10 bytes, and there may be several<br />
|-<br />
|B||80||a literal 80 ends the list of sprites for this tile<br />
|}<br />
or, alternatively, the instruction to use TTD's layout by using four zero bytes 00 00 00 00 instead of the groundsprite bytes. You can use [http://www.bytetransfer.de/projects/ttdpatch/docs/spriteidmapping.php the online sprite ID converter] to look up the sprite IDs you can use for all the climates. However, using presumed-to-be "unused" sprites is likely to cause incompatibilities with other sets using them and can cause crashes, so the preferred way of obtaining new sprites for ground sprites is to reserve them via [[ActionDSpecialVariables#GRF Resource Management|GRF Resource Management]] and apply them to your action 0 with an [[Action6|action 6]] (see the example there).<br />
<br />
One can draw two types of sprites. &nbsp;One type is one that establishes a new 3D bounding box for use by the sprite sorter. &nbsp;The other type shares the 3D bounding box of the previous sprite(s). &nbsp;It must not be larger than the sprite which established the bounding box, nor must any part of it be outside this box. &nbsp;For simplicity, it should have the exact same dimensions as the sprite it shares the bounding box with. &nbsp;The latter type is supported in the station construction window display only since TTDPatch 2.6 r1684.<br />
<br />
The spritedata of sprites with their own bounding box has this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||xofs||x-offset from northern tile corner<br />
|-<br />
|B||yofs||y-offset from northern tile corner<br />
|-<br />
|B||zofs||z-offset from northern tile corner<br />
|-<br />
|B||xextent||size of sprite in x direction<br />
|-<br />
|B||yextent||size of sprite in y direction<br />
|-<br />
|B||zextent||size of sprite in z direction<br />
|-<br />
|D||sprite||sprite number to draw<br />
|}<br />
<br />
The spritedata of sprites sharing the bounding box has this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||xofs||x-offset relative to previous sprite<br />
|-<br />
|B||yofs||y-offset relative to previous sprite<br />
|-<br />
|B||80||a literal 80<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|B||00||(ignored)<br />
|-<br />
|D||sprite||sprite number to draw<br />
|}<br />
<br />
Since OpenTTD r18959 you can draw multiple ground sprites for a tile, which is useful if you want to use the usual rail/grass/concrete groundtile, but still need to add features to it without using a new bounding box. To do so use the syntax of sprites sharing the previous bounding box, but use it before the first bounding box definition. xpixeloffset and ypixeloffset refer to the usual spot of groundtiles. The same feature is also partially supported in TTDPatch since TTDPatch 2.6 r2312: TTDPatch ignores the xofs and yofs fields and always uses (0,0) for the offset. If you are developing a GRF that needs to be compatible with both OpenTTD and TTDPatch, you should always keep xofs and yofs zero to get the same effect in both games.<br />
Note however that both implementations do not consider the [[Action0Stations#General Flags 13|setting of prop13 bit 0]], hence these "multiple ground sprites" have to be always part of the building sprites set and cannot be part of the different sprite set for ground sprites.<br />
<br />
The sprite number can have the following values (remember to use little endian, i.e. reversed byte order):<br />
<br />
{| |-<br />
!Number!!Sprite<br />
|-<br />
|0000042D+X||use sprite X from the corresponding [[Action1|action 1]] block (i.e. 0000042D for the first, 0000042E for the second, etc.)<br />
|-<br />
|0000842D+X||same, but draw it using company colour translation<br />
|-<br />
|0322442D+X||same, but draw in transparent mode (actual colours of the sprite are disregarded entirely); supported in station construction window display since TTDPatch 2.6 r1683<br />
|-<br />
|RRRR842D+X||draw sprite with colour translation defined in sprite RRRR; available since TTDPatch 2.6 r1683<br />
|}<br />
<br />
With bit 31 set, this sprite will refer to a TTD sprite, not the action 1 sprite. For the first ground sprite the reverse meaning applies.<br />
<br />
Depending on the railtype the sprites may get additional offsets:<br />
<br />
{| |-<br />
! !! Normal/electrified rail !! Monorail !! Maglev<br />
|-<br />
|TTD sprites || 0 || 82 || 164<br />
|-<br />
|Action 1 sprite (first ground sprite) || 0 || 1 || 2<br />
|-<br />
|Action 1 sprite (other sprites in the layout) || 0 || 0 || 0<br />
|}<br />
<br />
So, TTD sprites and the first ground sprite are affected by the railtype, while other action 1 sprites in the layout are not. The offset "82" refers to the offset between the default TTD track sprites; if you are using non-track ground sprites which are not from an action 1, you need to supply fake spritenumbers which preemptively reverse the offsets (that is, you need different sprite layouts for every railtype your station is available for).<br />
<br />
Setting bit 30 forces this sprite to be displayed normally even in "transparent buildings" mode (supported only in TTDPatch 2.6 r1695 and later).<br />
<br />
See below for an example of linked sprites as well as transparent sprites (e.g. for a station roof).<br />
<br />
Note that the coordinates here are 3D coordinates with x running from top-right to bottom-left and y running from top-left to bottom-right, with the tile dimensions being 16x16 (and 8 for one height level). This means the x and y values should always be within 0-15 (decimal).<br />
<br />
This is different to and independent from the x/y offsets used in the actual .NFO file. &nbsp;The 3D bounding box is used by TTD's sprite sorter to figure out the order in which to draw the sprites, as well as telling it which sprites to draw, because those whose bounding box falls outside the currently updated screen rectangle will not be drawn. &nbsp;Make sure the 3D bounding box is large enough to contain the entire sprite, but not so large that the sprite sorter can't determine which sprites should be in front.<br />
<br />
This means that the order in which you specify sprites is irrelevant. &nbsp;Sprites will get drawn from back to front, in the order which the sprite sorter determines as correct, from their bounding boxes. &nbsp;There are two exceptions, however:<br />
* Sprites sharing the same bounding box will always be drawn in the given order.<br />
* The station construction window display doesn't use the sprite sorter. Tiles that may be displayed in that window need to be specified in the correct drawing order, back to front.<br />
<br />
=== Copy sprite layout (0A) ===<br />
<br />
This is not a property as such, but an action. &nbsp;It takes as argument a byte which is interpreted as station-ID to copy the custom sprite layout from.<br />
<br />
=== Callback flags (0B) ===<br />
For stations, the following [[callbacks]] can be defined by setting the corresponding bit in property 0B:<br />
<br />
{| |-<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||13||Whether to make station available in construction window (non-zero callback return) or not (callback returns zero)<br />
|-<br />
|1||2||14||Use callback to select sprite layout<br />
|-<br />
|2||4||141||Decide next animation frame<br />
|-<br />
|3||8||142||Decide animation speed<br />
|-<br />
|4||10||149||Custom slope check<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 [[VariationalAction2|variational action 2]] for callbacks.<br />
<br />
=== Selection of numbers of platforms and length (0C, 0D) ===<br />
<br />
By default all platform lengths and any number of platforms is available for the new stations. &nbsp;Using these properties, you can choose which ones should be unavailable by setting the corresponding bit in the property.<br />
<br />
The values are a byte, used as a bit mask. &nbsp;Bits 0 to 6 control the availability of number or length 1 to 7, and bit 7 controls the availability of the "+7" button. &nbsp;Each bit that is set disables the corresponding length or number of platforms.<br />
<br />
For compatibility with "largestations off", at least one length between 1 and 5 (bits 0 to 4) and one number of platforms between 1 and 4 (bits 0 to 3) must be available, i.e. at least one of these bits must be unset.<br />
<br />
=== Define custom layout (0E) ===<br />
<br />
This allows choosing which tile type is built at which tile of a newly built<br />
<br />
station. &nbsp;There are four different types, which TTD normally defines as<br />
<br />
{| |-<br />
!Tile type!!Appearance<br />
|-<br />
|00||plain platform<br />
|-<br />
|02||platform with building<br />
|-<br />
|04||platform with roof, left side<br />
|-<br />
|06||platform with roof, right side<br />
|}<br />
<br />
These numbers are used for stations in NE-SW direction, or these numbers plus one for stations in the NW-SE direction. &nbsp;To define a custom layout, use this format:<br />
<br />
{| |-<br />
!Size!!Name!!Meaning<br />
|-<br />
|B||length||length of platforms for this layout<br />
|-<br />
|B||number||number of platforms for this layout<br />
|-<br />
|V||tiles||length*number bytes of tile types, one platform after another, only 00, 02, 04 or 06 are allowed as values<br />
|}<br />
<br />
Repeat this as often as necessary to define the layouts for all supported combinations of length and number. &nbsp;End the definitions with a 00 00 (zero length and zero number). &nbsp;Any combinations that are not defined will be built using TTD's default layout.<br />
Note that it may be easier to draw different sprite sets using a [[VariationalAction2|variational action 2]] based on [[VarAction2Stations#Platform info 40 41 46 47 49|station variable 40]], rather than redefining the layout. &nbsp;In addition, [[Callbacks#Custom station layout 24|callback 24]] will be used to further customize the layout as defined by this property (or by TTD if no prop 0E layout is available). This may also be easier than defining a prop 0E layout for every combination of length and number of platforms.<br />
<br />
=== Copy custom layout (0F) ===<br />
<br />
Similar to property 0A, this copies the custom layout from the station-ID given by the argument.<br />
<br />
=== Little/lots threshold (10) ===<br />
Amount of cargo for switching from "little" to "lots" of cargo. &nbsp;TTDPatch separates the full range of cargo amounts (0 to 4095) into two separate subranges, "little" and "lots" of cargo. &nbsp;This allows better control of cargo amount based graphics (if needed). &nbsp;Property 10 specifies at what amount of cargo the patch is to switch from one to the other subrange. &nbsp;See [[Action2Stations|Action 2 for stations]] for more information.<br />
<br />
=== Pylon placement (11) and wire placement (14) ===<br />
Prop. 11 sets which tile types should have pylons when used with electrified tracks. By default, tiles 4-7 have pylons, and tiles 0-3 don't. This is a bit mask of tile types, with a bit set meaning that a pylon should be drawn. The tile types here do not consider [[Callbacks#Station sprite layout 14|callback 14]], but rather the type as it was built, i.e. from prop. 0E.<br />
<br />
Prop. 14 works in a similar way, except that it sets the tile types on which there should be ''no'' wires displayed. With the default value of "00", wires are displayed everywhere, and for each bit set, the wire is omitted on that tile type.<br />
<br />
This property should only be used when the wires cause problems with the sprite sorter, because even when the wire is obscured by a station hall or similar, it should still show up in transparent mode so that each tile can easily be verified as being electrified.<br />
<br />
=== Cargo types for random triggers (12) ===<br />
<br />
This sets which cargo types should trigger re-randomizing. The cargo types are given as a bitmask of the bits from column 3 (type B) in CargoTypes. &nbsp;If nothing is set (the default), the no random triggers will happen, to conserve CPU time.<br />
<br />
=== General Flags (13) ===<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning<br />
|-<br />
|0||1||use different sprite set for ground sprites (var. 10 is 1 for ground sprites, 0 otherwise)<br />
|-<br />
|1||2||when calculating the cargo amount to display, divide the amount by the station size (to simulate cargo distributed over the area of the station)<br />
|-<br />
|2||4||[[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] needs random bits in var. 10<br />
|-<br />
|3||8||Use custom foundations on sloped tiles (the lowest byte of var. 10 is 2 for foundation sprites)<br />
|-<br />
|4||10||When bit 3 is set, use extended foundation block instead of the simple one<br />
|}<br />
<br />
Bit 3 works somewhat similarly to bit 0: your sprite selection will be called again, with 2 in the lowest byte of variable 10. If the chain ends on a callback result, the programme will assume the foundation selection has failed and will use the default foundaton sprites. The low word of variable 18 will contain the tile type of the current tile; if you have [[Callbacks#Station sprite layout (14)|callback 14]] enabled, this will be the its return value - otherwise, the default TTD types (platform with building, platform with left roof etc.) are used. In either case, one is added for the NW-SE orientation, in case your station needs different foundations depending on its orientation. Bits 16 and 17 are set if the NW and and NE foundations are to merged with the corresponding neighbour tile, so you shouldn't draw the corresponding edge in the foundation sprite. Other bits of variable 10 and variable 18 are reserved for future use.<br />
<br />
Your sprite selection code should select a foundation sprite block. The contents of this block depends on whether bit 4 is set or not.<br />
* Bit 4 clear (simple foundations):<br />
[[File:simple_foundations.png]]<br />
<br />
The programme will combine the needed foundation from these 8 sprites depending on the current slope. You don't need to care about the merge data in bits 16..17 of variable 18; it will be taken care of that automatically by adding the 7th and 8th sprite only when necessary.<br />
* Bit 4 set (extended foundations):<br />
[[File:extended_foundations.png]]<br />
<br />
You need to have one sprite for every slope that's possible below a rail station. The correct one will be automatically selected depending on the current slope. It can't handle the merging itself, however, so you need four foundation blocks: one with no edges removed, one with the NW edge removed, one with the NE edge removed and one with both north edges removed. Your sprite selection code is responsible for selecting the correct of those blocks according to the merge info in variable 18.<br />
<br />
In both cases, you can put an additional value into register 100h, which will serve as an offset into the selected block. If you don't modify register 100h during the chain, it will default to 0. It is important that the dimensions of these sprites remain the same - thus bit 6 in the real sprites must be set to prevent trimming the empty blue areas. The offset of these foundations must be -31 to the X direction and -9 to the Y direction.<br />
<br />
=== Can train enter tile (15) ===<br />
<br />
Like props. 11 and 14, this value contains eight bits relating to the eight possible tile types. If a bit is set, trains are prevented from routing through or entering any tile of this type.<br />
<br />
=== Animation information (16) ===<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 station (this is the default value).<br />
Since you can't have properties for individual station tiles, this property applies for every tile of the station. If you don't want to animate some tiles, you should check the current position during [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]] and return FD if the current tile doesn't need to be animated. If you also need animations of different length per tile, you'll have to use [[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] for that.<br />
<br />
=== Animation speed (17) ===<br />
The meaning is the same as for [[Action0Houses#Animation Speed 1B|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 />
=== Animation triggers (18) ===<br />
This is a bit mask of events that should trigger [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]], allowing to change the animation state<br />
<br />
{| |-<br />
!Bit!!Value!!Meaning!!Happens on<br />
|-<br />
|0||1||Station part is built||the newly built tiles<br />
|-<br />
|1||2||New cargo arrives to station||whole station<br />
|-<br />
|2||4||A cargo type gets removed from station||whole station<br />
|-<br />
|3||8||Train enters station (starts loading/unloading)||platform where the train is<br />
|-<br />
|4||10||Train leaves station (done loading/unloading)||platform where the train is<br />
|-<br />
|5||20||Train loads/unloads cargo||platform where the train is<br />
|-<br />
|6||40||Every 250 ticks||whole station<br />
|}<br />
<br />
The remaining bits are reserved for future triggers, they must be zero for now.<br />
<br />
The "happens on" column tells which tiles will [[Callbacks#Animation control (1B/25/140/152/159) |callback 140]] be called on.<br />
<br />
Triggers 1 and 2 put extra information to bits 8..15 of variable 18: the cargo type in question. If your GRF has a cargo translation table, the cargo type will be an index in that table, or FFh if the cargo isn't in the table. If you don't have a cargo translation table, the cargo type will simply be the climate-dependent cargo type number.<br />
<br />
=== Road routing (19 - reserved for future use) ===<br />
<br />
Will allow to have routing informations for road vehicles on rail stations,<br />
<br />
generally you need to deny rail vehicle traveling via prop 15<br />
<br />
== Examples ==<br />
<br />
=== Using TTD's sprite layouts for certain tiles ===<br />
<br />
To use TTD's layout, you use <code>00 00 00 00</code> for the ground sprite number and leave off everything else.<br />
<br />
So instead of for example<br />
<br />
F4 03 00 00<br />
00 00 00 10 05 02 2E 84 00 00<br />
00 0B 00 10 05 02 30 84 00 00<br />
80<br />
<br />
you just put<br />
<br />
00 00 00 00<br />
<br />
=== Using transparent sprites ===<br />
<br />
You can use transparent sprites to make for example the roof translucent like in TTD's stations. The roof of TTD's stations is made like this:<br />
<br />
00 00 10 10 10 0A 37 84 00 00<br />
00 00 80 00 00 00 3B 44 22 03<br />
<br />
The first sprite here is the non-transparent frame of the roof, drawn in company colours (it has bit 15 set). The second part is a special "linked" sprite without its own bounding box, it shares that of the previous sprite. That's done by setting the z offset to 80.</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Action0/Objects&diff=1617Action0/Objects2011-06-16T19:27:57Z<p>Pm-bot: Bot: Automated text replacement (-Callbacks#Animation control 1B 25 140 +Callbacks#Animation control (1B/25/140/152/159), -Callbacks#Next animation frame 1A 26 141 +Callbacks#Next animation frame (1A/26/141/153/158))</p>
<hr />
<div>==Introduction==<br />
Defining properties of new objects.<br />
<br />
Unlike vehicles or new stations, most new objects have no real equivalent in TTD.<br />
<br />
The IDs are therefore free to be chosen and will in fact be allocated automatically by the patch. In action 0, you only specify IDs relative to the set, i.e. the ID of the first object type is 00, the second object type is 01 and so on. In total, each game can only have 255 object IDs for all active grf files.<br />
<br />
The property you '''must''' set for each object ID is 08 (in addition to defining an action 3 for it). Also, all object IDs must get their classes in the right order, starting from ID 00 onwards.<br />
<br />
== Properties ==<br />
<br />
{|<br />
!Number!!Version!![[GRFActionsDetailed|Size]]!!Description<br />
|-<br />
|08||a||D||Class label, see below<br />
|-<br />
|09||a||W||Text ID for class<br />
|-<br />
|0A||a||W||Text ID for this object<br />
|-<br />
|0B||a||B||[[Action0General#Climate availability|Climate availability]]<br />
|-<br />
|0C||a||B||Byte representing size, see below<br />
|-<br />
|0D||a||B||Object build cost factor (sets object removal cost factor as well)<br />
|-<br />
|0E||a||D||Introduction date, see below<br />
|-<br />
|0F||a||D||End of life date, see below<br />
|-<br />
|10||a||W||Object flags, see below<br />
|-<br />
|11||b||W||Animation information<br />
|-<br />
|12||b||B||Animation speed<br />
|-<br />
|13||b||W||Animation triggers<br />
|-<br />
|14||b||B||Object removal cost factor (set after object build cost factor)<br />
|-<br />
|15||b||W||Callback flags, see below<br />
|-<br />
|16||b||B||Height of the building<br />
|-<br />
|17||c||B||Number of object views<br />
|}<br />
<br />
Check [http://pics.lakie.net/newObject-ActionStructure.png Lakie's Graphical Representation of the newObject Specifications]<br />
<br />
The specifications of NewObjects are available since OpenTTD r20670 in TTDPatch since r2340<br />
<br />
== Descriptions ==<br />
<br />
=== Object class (08) ===<br />
<br />
Class labels are unique identifiers composed of the letters A-Z and/or the numbers 0-9, &nbsp;analoguous to [[Action0Stations#Station class (08)|station class labels]].<br />
<br />
Their main use is to combine objects into classes and make them available by the top dropdown list in the object construction window.<br />
<br />
Unlike for stations, there is no default class for objects. Set authors have to specify their [[ObjectLabels|own labels]], although it is strongly recommended to follow a general scheme to try to avoid confusion.<br />
<br />
Class IDs must be set before any other property.<br />
<br />
=== Object class text ID (09) ===<br />
<br />
The text ID for this class (word value). This textid should be either a TTD textid or a D4xx textid (set via D0xx in action4).<br />
<br />
When specifying an object, you don't need to set a class name again if you already did for another one with the same class.<br />
<br />
=== Object text ID (0A) ===<br />
<br />
The text ID for the object for query and selection (word value). Same requirements as for property09.<br />
<br />
=== Object size (0C) ===<br />
<br />
The object size up to 15x15 tiles.<br />
<br />
This byte value is divided into two nibbles. The first defines the size in y direction and the second defines the size in x (i.e., stored as YX).<br />
<br />
Note that any value lower than 0x11 will be rejected.<br />
<br />
=== Build Cost (0D) ===<br />
<br />
The build cost multiplier. This is multiplied by the number of tiles for evaluation of construction and removal costs of an object.<br />
<br />
=== Introduction date (0E) ===<br />
<br />
Introduction date of an object, in days since the year 0. This takes account of leap years; divisible by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). In TTDPatch anything before 1920 is considered to be always available, and it should allow for objects to work past 2044, the date is also the very first date you can build the object.<br />
<br />
=== End of life date (0F) ===<br />
<br />
Last year an object can be build, in days since the year 0. Same requirements as above. Also note that it must be a minimum of a year (365 days) after the introduction date or TTDPatch will ignore it.<br />
<br />
=== Object flags (10) ===<br />
<br />
The following flags control object behaviour and are cached for built objects, so changing these flags will have no effect on already constructed objects.<br />
<br />
{|<br />
!Bit!!Value!!Version!!Meaning<br />
|-<br />
|0||1||a||Only Available in the scenario editor <sup>1</sup><br />
|-<br />
|1||2||a||Irremovable <sup>2</sup><br />
|-<br />
|2||4||a||Anything Can Remove (owned land behaviour)<br />
|-<br />
|3||8||a||Allow construction of the object on water<br />
|-<br />
|4||16||a||Removal cost is actually income (owned land behaviour)<br />
|-<br />
|5||32||a||Do not display foundations if on a slope<br />
|-<br />
|6||64||a||Object has animation <sup>3</sup><br />
|-<br />
|7||128||a||Only available during game play <sup>1</sup><br />
|-<br />
|8||256||b||Allows 2cc mapping for objects instead of the default 1cc<br />
|-<br />
|9||512||c||Disallows construction on land (also has bit 3 behaviour)<br />
|-<br />
|10||1024||c||Draws the water under the object <sup>4</sup><br />
|-<br />
|11||2048||d||Allow bridge over the object taking the building height into account <sup>5</sup><br />
|-<br />
|12||4096||d||Random bits in the "next animation frame" callback<br />
|}<br />
<br />
c - TTDPatch r2331<br />
<br />
# Note that bits 0 and 7 are incompatible and setting both will make an object completely unavailable.<br />
# Object cannot be removed through normal dynamite, control must be held and the removal cost will be multiplied by 25 (this is the usual behaviour for most class A objects in TTDPatch).<br />
# Setting this flag will allow the object's animation counter to be increased, must be set if you plan to make use of animations. Like stations you must enable animation on a per tile basis by means of the "built tile" trigger and callback 159.<br />
# Only applies when built on top of a water tile, also replaces the ground tile of the object completely. (Does not work when object built on sloped water tiles).<br />
# Only applies to OpenTTD. TTDPatch does not support bridges over objects yet.<br />
<br />
=== Animation information (11) ===<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 object (this is the default value).<br />
<br />
Since you can't have properties for individual object tiles, this property applies for every tile of the object. If you don't want to animate some tiles, you should check the current position during [[Callbacks#Animation control (1B/25/140/152/159)|callback 159]] and return FD if the current tile doesn't need to be animated. If you also need animations of different length per tile, you'll have to use [[Callbacks#Next animation frame (1A/26/141/153/158)|callback 158]] for that.<br />
<br />
=== Animation speed (12) ===<br />
<br />
The meaning is the same as for [[Action0Houses#Animation Speed (1B)|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 0.<br />
<br />
=== Animation triggers (13) ===<br />
<br />
This is a bit mask of events that should trigger [[Callbacks#Animation control (1B/25/140/152/159)|callback 159]], allowing to change the animation state<br />
<br />
{|<br />
!Bit!!Value!!Meaning!!Happens on<br />
|-<br />
|0||1||Object is built||all tiles<br />
|-<br />
|1||2||Periodic tile loop||single tile<br />
|-<br />
|2||4||Synchronised periodic tile loop||all tiles<br />
|}<br />
<br />
The synchronised periodic tile loop is called directly after the (unsynchronised) periodic tile loop of the northern tile.<br />
<br />
=== Object removal cost factor (14) ===<br />
<br />
Cost factor for the removal of an object. This must be set after property 0D (object build cost factor) as that overwrites this value.<br />
<br />
=== Callback flags (15) ===<br />
<br />
For objects, the following [[callbacks]] can be defined by setting the corresponding bit in property 15:<br />
<br />
{|<br />
!Bit!!Value!!Variable 0C value!!Callback<br />
|-<br />
|0||1||157||Custom slope check<br />
|-<br />
|1||2||158||Decide next animation frame<br />
|-<br />
|2||4||15A||Decide animation speed<br />
|-<br />
|3||8||15B||Decide colour of building<br />
|-<br />
|4||16||15C||Show additional text in the build object window<br />
|-<br />
|5||32||15D||Allow/disallow autosloping<br />
|}<br />
<br />
=== Building height (16) ===<br />
<br />
Set the height of the building in heightlevels (8 pixels). For example if the structure is 16 pixels high you set this property to 2.<br />
<br />
In OpenTTD this property is used to determine the height of the build object window; the height for the object preview is set to 32 + "value of property 16" * 8. The property is also uses to determine how high a bridge must be if it is allowed by the bit in property 10.<br />
<br />
=== Number of views (17) ===<br />
<br />
Since TTDPatch nightly r2360 and OpenTTD r21455 objects may have "views", i.e. different graphical representations, e.g. used to show rotated views of an object. Number of views may be 1, 2, or 4. Default value is 1.<br />
<br />
For non-square objects, x and y sizes are swapped for odd views. I.e., giving an object size of &nbsp;1*2 (x = 1, y = 2), it will be displayed as 1*2 for num = <nowiki>[</nowiki>0,2] (x-direction) but as 2*1 for num = <nowiki>[</nowiki>1,3] (y-direction).<br />
<br />
Use object varaction2 var48 to access particular views of an object.<br />
==Examples==</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Station_sprite_layout&diff=1614Callback: Station sprite layout2011-06-16T19:10:55Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Callback: Station sprite layout (14) ==<br />
<br />
[[Callbacks#Station sprite layout (14)|Callback 14]] selects an entry from the sprite layout (set by [[Action0Stations#Sprite layout 09|prop. 09]] or the default if unset), and if its return value is invalid then the sprite layout given from the tile type will be used. &nbsp;You can use this to have more than 4 different sprite sets to choose from.<br />
<br />
Bit 0 (station orientation) of the return value is ignored, and instead set to bit 0 of the actual tile, so that you do not have to check the orientation explicitly and return the two corresponding values, instead just organize the layouts such that even numbers correspond to X orientation (NE-SW) and odd numbers corresponding to Y orientation (NW-SE).<br />
<br />
The effect is like having additional tile types that are however not actually built, but only show different graphics depending on this callback.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Show_additional_text_in_fund/building_window&diff=1612Callback: Show additional text in fund/building window2011-06-16T19:07:20Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Show additional text in fund/building window (38/15C) ==<br />
<br />
This callback allows you to display extra information in the industry fund and object building windows. The return value should be the number of a D0xx text to be displayed. The text must begin with a colouring special character and should not be longer than three lines (automatic line breaks are provided, but you can use char 0D for a manual line break). Since the industry isn't built yet, you can't access any industry variables during this callback. Same holds for objects.<br />
<br />
Since OpenTTD r20086 and TTDPatch r2354, the contents of registers 100h..105h are copied onto the text reference stack.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Wagon_length&diff=1611Callback: Wagon length2011-06-16T19:07:19Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Wagon length ==<br />
<br />
This callback is used instead of [[Action0Trains#Shorter train vehicles 21|property 21]] whenever the train leaves a depot or is displayed inside a depot. If the callback fails, the value of property 21 is used instead.<br />
<br />
Road vehicles do not have a property for this purpose. If the callback fails, a length of 8/8 is used.<br />
<br />
The callback result may change only when whole vehicle chain is inside a depot.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Decide_object_colour&diff=1610Callback: Decide object colour2011-06-16T18:58:29Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Decide object colour (15B) ==<br />
<br />
This callback allows you to set/modify the colour of an object upon construction. Variable 10 contains the current company colour or a random colour for when there is no company, i.e. in the scenario editor. If the object wants a 2CC colour mapping two nibbles, i.e. two colours, are passed in variable 10, otherwise one nibble (colour).<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Layout_name&diff=1609Callback: Layout name2011-06-16T18:58:28Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Airport layout name (156) ==<br />
<br />
This callback allows you to show a name for an airport layout. It should return a D0xx StringID. This callback is always called when available, you do not need to set a bit in any action0 property to enable it. Available for OpenTTD since r20273.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Extra_information_about_layout_in_the_build_gui&diff=1608Callback: Extra information about layout in the build gui2011-06-16T18:58:27Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Extra information about airport layout in the build gui (155) ==<br />
<br />
This callback allows you to display some extra text in the build airport gui. It should return a D0xx StringID. This callback is always called when available, you do not need to set a bit in any action0 property to enable it. Available for OpenTTD since r20272<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Customized_building_name&diff=1607Callback: Customized building name2011-06-16T18:58:26Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== House customized building name (14D) ==<br />
<br />
This callback is activated from the Tile Description Query tool, when enquiring a house. &nbsp;Variable 10 will be set to 1 if the house is complete, otherwise it will be 0. &nbsp;The return value is the "xx" of a D0xx text ID. &nbsp;If the callback fails, the Query tool will use the house name set in property 12 (Building name ID).<br />
<br />
Since this callback is not performed frequently, you do not need to specify a mask. &nbsp;It will always be performed, and the name will only change when successful.<br />
<br />
Available for OpenTTD since r15172, and for TTDPatch since TTDPatch 2.6r2249<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Decide_input_and_output_cargo_types&diff=1606Callback: Decide input and output cargo types2011-06-16T18:58:26Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Decide input and output cargo types (14B,14C) ==<br />
<br />
These callbacks are called when the industry is built, and allow customizing the input and output cargo types dynamically. Both callbacks are called repeatedly, with the lowest byte of variable 10 starting from zero and increasing after every call; you should return a cargo type each time, or FFh to terminate the list. (A failed callback terminates the list, too.) The same limitations apply as for callback 14A: industry tiles aren't yet placed, and some industry variables contain junk. You can use random action2s, however. The interpretation of the returned value depends on two factors: the current GRF version number and the presence of a cargo translation table:<br />
<br />
{| |-<br />
!GRF version!!Has cargo translation table!!Interpretation<br />
|-<br />
|6 or below|| ||Climate-dependent cargo slot number<br />
|-<br />
|7 or above||No||Cargo bit<br />
|-<br />
|7 or above||Yes||Index in the translation table<br />
|}<br />
<br />
Although currently [[Callbacks#Decide input and output cargo types (14B,14C) |callback 14B]] is called no more than three times, and [[Callbacks#Decide input and output cargo types (14B,14C) |callback 14C]] no more than twice, this may change between versions/implementations, to allow more input/output types. To be safe, you should return FFh as the last element even when you use all three input types or both output types.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Decide_industry_colour&diff=1605Callback: Decide industry colour2011-06-16T18:58:25Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Decide industry colour (14A) ==<br />
<br />
This callback is called when the industry is being constructed, to override the selected colour of the industry (variable A8). This colour will be used for tile sprites that request recolouring, but don't supply a recolour sprite number. The following industry variables aren't yet filled and contain random junk: 86..87, 93, 9E..A1, A9. (You probably wouldn't need to read anything but 86..87 anyway, since these fields contain information about the past, and the industry doesn't yet have a past.) Industry tiles aren't placed yet, either.<br />
<br />
Variables A7 and A8 are filled, however, and provide useful information. Variable A7 contains the number of the funder company, or 10h if the industry wasn't funded. Variable A8 contains the number of the colour scheme randomly picked by TTD, it's between 0 and 15. If you don't want to change the colour picked by default, you can either make the callback fail or just return variable A8 unchanged.<br />
<br />
Only the lowest four bits of the returned value are used, the other bits are reserved for future use. Those four bits are copied into variable A8 after the callback returns. You can either use industry variable 45 to get the company colour of the funder (if there's any), use a random action2 to select a random colour scheme from a given list, or of course decide on global variables like position or game year.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Station_slope_check&diff=1604Callback: Station slope check2011-06-16T18:58:24Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Land slope check (149/157) ==<br />
<br />
This callback is called for each tile where the new station part will be built. It can return zero to accept the current tile or one to make the station building fail with the "Land sloped in wrong direction" error message. Other return values are reserved for future use, don't use them for now.<br />
<br />
Since the station isn't built yet, no 8x variables can be accessed. Only variables 43 and 67 will work from the 4x and 6x variables. You get the following information, though:<br />
* variable 18:<br />
{| |-<br />
!bit numbers!!Meaning<br />
|-<br />
|0..7||offset of current tile on the platform, 0 is the northmost tile<br />
|-<br />
|8..15||bits 8..15: current platform number, 0 is the northmost platform<br />
|-<br />
|16..23||total length of station being built<br />
|-<br />
|24..31||total number of platforms being built<br />
|}<br />
* variable 10:<br />
{| |-<br />
!bit numbers!!Meaning<br />
|-<br />
|4..7||Slope info of the current tile:<br />
* bit 7 - N corner is elevated<br />
* bit 6 - E corner is elevated<br />
* bit 5 - S corner is elevated<br />
* bit 4 - W corner is elevated<br />
|-<br />
|0..3||the same information, but "mirrored" (bit 0 and 2 swapped) if the station is built in the NW-SE orientation. This allows you to check slopes without checking the orientation explicitly.<br />
|-<br />
|other bits||reserved for future use<br />
|}<br />
<br />
The callback is called only after the normal checks TTD does for slopes, so it's not possible<br />
<br />
to allow a slope that isn't allowed by default; you can only narrow the set of allowed slopes. If the callback fails, the tile will be accepted. It is, however, called for flat tiles, so you can force your station to sloped land. You can't access the station info even if the platform is added to an existing rail station or is overbuilding station tiles. That's because TTD will decide this later in the code, after the slope is already accepted.<br />
<br />
This is called if available just before object construction, it does not require that any flags be set in the action0.<br />
<br />
Please note that for Objects only the low byte of variable 18 is valid (Offset from north tile (origin), stored as YX) and that variable 10 does not have the reversed version, and bits 0 - 3 contain the actual raised corners (same order as bits 4 - 7).<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Watched_cargo_accepted&diff=1603Callback: Watched cargo accepted2011-06-16T18:58:23Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Watched cargo accepted (148) ==<br />
<br />
Called when a cargo type specified in property 20 is accepted by a house tile, or to be more specific, in a station that has the house tile in its acceptance area. It will be called for each tile of a multi-tile building whenever a tile with property 20 accepts cargo. This means if more than one tile has cargoes specified in property 20, the callback can be called multiple times on the same tile in the same tick. The low word of variable 18 contains the offset of the trigger tile relative to the current tile; the low byte contains the X offset, the high byte the Y offset. (0 means it's the same tile, negative coordinates mean it's northward, positive southward.) With this, you can tell apart the callings within the same tick. The high word of variable 18 contains random bits, the bits are the same for each tile of multi-tile buildings. <br />
<br />
The return values can be the same as for callback 1B. Like all animation callbacks, if the high byte of the result is nonzero, it will be interpreted as a sound effect number, and the corresponding sound effect will be played at the tile.<br />
<br />
Due to implementation details, up to 250 game ticks can pass between the actual acceptance and triggering this callback.<br />
<br />
This callback isn't available if the station2 structure isn't present - see the property 20 entry for more information.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Add_sprite_offset_callback&diff=1602Callback: Add sprite offset callback2011-06-16T18:58:21Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Add sprite offset callback (147) ==<br />
<br />
Add an offset to the default sprite number to be drawn.<br />
<br />
{| |-<br />
!Feature!!Accessible Variables<br />
|-<br />
|Canals||80+x variables are accessible by Canals. See [[VarAction2Canals]]<br />
|}<br />
<br />
The default number is accessible in variable 10 (extra callback info 1) to decide if the sprite number needs an offset.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_New_signals_sprite_drawing_callback&diff=1601Callback: New signals sprite drawing callback2011-06-16T18:58:20Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== New signals sprite drawing callback (146) ==<br />
<br />
This is a generic callback, and thus a generic action 3 must be used. It must be processed by a variational action 2 feature 0E, as indicated in the following link: [[VarAction2NewSignals]].<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Custom_station_rating_calculation&diff=1600Callback: Custom station rating calculation2011-06-16T18:58:20Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Custom station rating calculation (145) ==<br />
<br />
This callback allows you to modify part of the station cargo rating calculation for your cargo. To understand how to use it, you must first understand how the default rating calculation works:<br />
<br />
Internally, the station rating is stored in a byte, 0 meaning 0% and 255 meaning 100%. The rating is calculated as the sum of the following components:<br />
<br />
==== Time since the cargo was last picked up =====<br />
<br />
{| |-<br />
!Time units (days)!!Score (%, rounded)<br />
|-<br />
|&gt;21 (&gt;52.5 days)||0 (0%)<br />
|-<br />
|13..21 (32.5 days..52.5 days)||25 (10%)<br />
|-<br />
|7..12 (17.5 days..32.5 days)||50 (20%)<br />
|-<br />
|4..6 (10 days..17.5 days)||95 (37%)<br />
|-<br />
|0..3 (0 days..10 days)||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 />
{| |-<br />
!Amount of cargo!!Score (%, rounded)<br />
|-<br />
|&gt;1500||-90 (-35%)<br />
|-<br />
|1001..1500||-35 (-14%)<br />
|-<br />
|601..1000||0 (0%)<br />
|-<br />
|301..600||10 (4%)<br />
|-<br />
|101..300||30 (12%)<br />
|-<br />
|0..100||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 />
The original calculation goes like this:<br />
<br />
{| |-<br />
!Age of vehicle (years)!!Score (%, rounded)<br />
|-<br />
|2||10 (4%)<br />
|-<br />
|1||20 (8%)<br />
|-<br />
|0||33 (13%)<br />
|}<br />
<br />
If the newagerating switch is turned on, the calculation changes. You get 33 points for vehicles younger than 5 years, and get 0 points for vehicles older than 21 years. Between these two ages, score drops slowly, by 2 points per year.<br />
<br />
==== Bonus for AI companies =====<br />
<br />
{| |-<br />
!AI intelligence setting!!Score (%, rounded)<br />
|-<br />
|Low||0 (0%)<br />
|-<br />
|Medium||31 (12%)<br />
|-<br />
|High||63 (25%)<br />
|}<br />
<br />
That is, AI players cheat to get good ratings for their brain-dead routes.<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 />
==== Clamping =====<br />
If a human player does everything perfectly, the maximum rating she can get is 271 points, while the worst possible transport service gets -90 points; for "highly intelligent" AI players, the corresponding values are 334 and -27, respectively. The resulting value gets clamped to the 0..255 range. TTD makes sure the ratings change slowly, but steadily: every 2.5 days, the actual rating moves towards the value calculated above, by no more than 2 points. For example, you 'd need at least 320 days to go from 0% to 100%, even if your service is perfect. When a cargo type first appears at a station, its rating is set to 175 points (69%), so it takes some time until it gets adjusted to the actual parameters of the service.<br />
<br />
==== Callback effect =====<br />
The callback allows you to replace the first three components (days since last pickup, amount waiting and max. speed of last vehicle) in the calculation above. If your callback succeeds, the first three components are skipped and the returned value is used instead their results. Bit 14 is considered the sign bit, so you can return negative numbers (and need not to worry about calculated callback results yielding a negative result, as long as you stay in the range -16384..16383). During the callback, variable 18 has the value ssaaaatt, where<br />
* tt is the time since the cargo was last picked up, in the time units described above (1 unit = 2.5 days independent of vehicle type)<br />
* aaaa is the amount of cargo waiting<br />
* ss is the speed of the last vehicle picking the cargo up, in the speed units described above (if no vehicle entered the station yet, the value is FFh)<br />
<br />
The lowest byte of variable 10 contains one of the following values:<br />
<br />
{| |-<br />
!value!!meaning<br />
|-<br />
|10h||the last vehicle entering the station was a train<br />
|-<br />
|11h||the last vehicle entering the station was a road vehicle<br />
|-<br />
|12h||the last vehicle entering the station was a ship<br />
|-<br />
|13h||the last vehicle entering the station was an aircraft<br />
|-<br />
|00h||no vehicle entered the station yet, or the last one entering was sold<br />
|}<br />
<br />
Please note that there's only one "last vehicle" field per station, so the vehicle this refers to may not have picked up any of your cargo. The original TTD calculation doesn't care about this and just uses the field to get the vehicle type used in the first component.<br />
<br />
Currently, you can only use variables 10 and 18 for your decision, since neither vehicle nor station variables are available for a cargo callback. As soon as the architecture of TTDPatch allows this, the callback will be given access to the station and the last vehicle that entered.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Ambient_sound_effects&diff=1599Callback: Ambient sound effects2011-06-16T18:58:18Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Ambient sound effects (144) ==<br />
<br />
This callback is a generic callback for feature 0C (new sounds) used for playing ambient sound effects.<br />
<br />
The 15-bit return value is the sound effect number. Values from 0 to 72 (dec) are TTD's built-in sound effects, values beyond that refer to the sounds from [[Action11|Action 11]].<br />
<br />
To decide whether to play a sound, and what sound to play, Var.Action 2 variable 10 holds the following information: THRRxxxt<br />
<br />
{| |-<br />
!Field!!Meaning<br />
|-<br />
|T||Tile class, 0=bare land, 4=trees, 6=water<br />
|-<br />
|H||Height of north corner of tile<br />
|-<br />
|RR||8 random bits<br />
|-<br />
|xxx||Reserved<br />
|-<br />
|t||Terrain type; &nbsp;0 normal (grass), 1 desert, 2 rainforest, 4 on or above snowline<br />
|}<br />
<br />
This callback must be enabled by bit 4 in [[ActionD#Misc GRF Features 9E|action D var 9E]].<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Protect_building_conditionally&diff=1598Callback: Protect building conditionally2011-06-16T18:58:18Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Protect building conditionally (143) ==<br />
<br />
This callback is called when someone tries to remove the building from the map. You can use this callback to prevent the town or AI players from removing the building if certain conditions are met. You can return 0 to allow the destruction, or 1 to disallow it, except for human players, who can always remove any building.<br />
<br />
If you always return 1 from this callback, you achieve the same effect as turning on bit 1 of property 19. When this callback is enabled, bit 1 of property 19 is ignored. If the callback fails, the destruction is allowed.<br />
<br />
For multi-tile buildings, the callback will be called for the type of the tile the player wants to destroy. Therefore, to get consistent behaviour, you must enable this callback for every tile and respond it the same way no matter which tile it is called for.<br />
<br />
Since TTDPatch 2.6 r1705, you can use this callback to prevent building "town" industries (banks, water towers, etc.) over your house. The lowest byte of variable 10 is zero for "normal" demolition and one when TTD wants to remove the house for the sake of a new industry. Other values of variable 10 are reserved for future use.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Opt_out_of_accepting_cargo&diff=1597Callback: Opt out of accepting cargo2011-06-16T18:58:17Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Opt out of accepting cargo (3D) ==<br />
<br />
With this callback, the industry can refuse accepting a cargo even if it's one of the input cargo types. If there's another industry nearby that accepts this cargo, that one will get it.<br />
<br />
The lowest byte of var. 18 contains the ID of the cargo delivered. If your GRF has a cargo translation table installed, you will get the index from that table; otherwise, you will get the cargo bit associated with the cargo type. You must return zero if you don't want to accept the cargo, or 1 to accept it. Other return values are reserved for future use.<br />
<br />
This callback should be used in conjunction with [[Callbacks#Decide cargo acceptance (2B) |callback 2B]], since the acceptance of the tiles and the acceptance of the industry itself should always agree. If you disable accepting a cargo via [[Callbacks#Opt out of accepting cargo (3D) |callback 3D]], but forget to remove the acceptance from the tiles, the station will keep accepting the cargo and the player will keep getting the money, but the industry won't receive the cargo. On the other hand, if you remove acceptance from the tiles, but forget using [[Callbacks#Opt out of accepting cargo (3D) |callback 3D]], your industry may still get the cargo. (For example, there may be another industry nearby whose tiles accept the cargo. This makes the station accept the cargo, and send it to the nearest industry, which happens to be yours, even though its tiles don't accept the cargo.)<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Disable_autosloping&diff=1596Callback: Disable autosloping2011-06-16T18:58:15Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Disable autosloping (3C/14F/15D) ==<br />
<br />
With this callback, you can prevent the autoslope feature from altering the ground below a house/industry/object tile. To allow altering the ground, return zero. Returning anything other than zero will disallow land modifications.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Control_special_industry_effects&diff=1595Callback: Control special industry effects2011-06-16T18:58:15Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Control special industry effects (3B) ==<br />
<br />
This callback allows you to control some aspects of the special effects enabled in property 1A. The lowest byte of variable 18 always contains the number of the special effect, which equals to the bit number being set in property 1A. Currently only effect 0 (plant fields periodically) and effect 1 (cut nearby trees periodically) are supported.<br />
* For effect 0 you should return zero to avoid planting fields and any other value to plant a field. The callback is called every 256 ticks for a given industry. Variable 10 contains 32 random bits that can be used to randomize the behaviour. Industry variable AAh (word) can be used to make the plantings rarer, but please note that the low byte is always zero at this point. The default behaviour is giving 1/8 chance to plant a new field every 256 ticks.<br />
* For effect 1 you should return zero to avoid cutting a tree and any other value to try cutting one. The callback is called every 256 ticks for a given industry. You don't get random values this case, but you can still use variable AAh; the low byte is always zero here as well. The default behaviour is trying to cut a tree every 512 ticks.<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Show_additional_text_in_industry_window&diff=1594Callback: Show additional text in industry window2011-06-16T18:58:14Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Show additional text in industry window (3A) ==<br />
<br />
This callback allows you to display extra information in the industry window about the state of your industry. The return value should be the number of a D0xx text to be displayed. The text must begin with a colouring special character and should not be longer than one line. For example, you can use this callback to display the current production limit of a secondary industry.<br />
<br />
Note that since r11987, OpenTTD allows resizing the window when this callback is enabled. &nbsp;It allows to specify a text containing more than one line.<br />
<br />
Since TTDPatch 2.6 r1370, the contents of registers 100h..105h are copied onto the text reference stack. This allows you to display dynamically calculated values in the text by using the according StringCodes. Please note, though, that the text handler will see it as an array of bytes, not as an array of DWORDs, so you will have to pack two words into a register when you use codes that read words from the stack. In the case of \7D (which gets a byte), you may have to pack more into a register, but it's probably easier to use \7C instead. Please also note that you can use \80 to display textIDs calculated on the fly, but DCxx textIDs won't work correctly. When you need to choose from your own texts dynamically, you must use D0xx IDs, and add 400h to them. (That is, use D400 to refer to D000, D401 for D001 etc.)<br />
[[Category:Callbacks]]</div>Pm-bothttps://newgrf-specs.tt-wiki.net/index.php?title=Callback:_Custom_profit_calculation_for_cargoes&diff=1593Callback: Custom profit calculation for cargoes2011-06-16T18:58:12Z<p>Pm-bot: Create a separate page for each callback</p>
<hr />
<div>== Custom profit calculation for cargoes (39) ==<br />
<br />
This callback is called every time cargo is delivered to a station, to get how much income the player should get. The low word of var. 18 contains the distance of the transfer, byte 3 contains the amount of cargo moved and the highest byte contains the time spent en-route (a unit of time is +185 ticks, or ca. 2.5 days). The result should be a signed multiplier that gets multiplied by the amount of cargo moved and the price factor, then gets divided by 8192. Since the highest bit must always be set for a callback result, TTDPatch checks for the second highest bit (bit 14) for the sign. Returning a negative value means that the player has to pay for the transfer instead of getting money from it. For example, the maximum returnable value of 16383 means that the player gets twice the price factor for every unit.<br />
[[Category:Callbacks]]</div>Pm-bot