Difference between revisions of "NML:Block Example"
(add nav template) |
(make example code blue) |
||
| Line 3: | Line 3: | ||
NML files are mainly composed from blocks. A block starts with the type of the block, optional arguments and then the contents enclosed by curly braces. Nearly all NML files will start with a [[NML:GRF|grf-block]]. The grf-block takes no parameters and is one of the simplest blocks there is. Following is an example grf-block. |
NML files are mainly composed from blocks. A block starts with the type of the block, optional arguments and then the contents enclosed by curly braces. Nearly all NML files will start with a [[NML:GRF|grf-block]]. The grf-block takes no parameters and is one of the simplest blocks there is. Following is an example grf-block. |
||
| + | <pre style="color:blue"> |
||
grf { |
grf { |
||
grfid : "AB\02\03"; |
grfid : "AB\02\03"; |
||
| Line 10: | Line 11: | ||
min_compatible_version: 5; |
min_compatible_version: 5; |
||
} |
} |
||
| + | </pre> |
||
Let's look at this code line for line. |
Let's look at this code line for line. |
||
| + | <pre style="color:blue"> |
||
grf { |
grf { |
||
| + | </pre> |
||
This block is a grf-block. A grf-block has no parameters. The '{' is the start of the block content. |
This block is a grf-block. A grf-block has no parameters. The '{' is the start of the block content. |
||
| + | <pre style="color:blue"> |
||
grfid : "AB\02\03"; |
grfid : "AB\02\03"; |
||
| + | </pre> |
||
This line sets the grfid of the resulting grf. The value is the letters AB followed by a byte with value 2 and then another one with value 3. The semicolon marks the end of the statement. |
This line sets the grfid of the resulting grf. The value is the letters AB followed by a byte with value 2 and then another one with value 3. The semicolon marks the end of the statement. |
||
| + | <pre style="color:blue"> |
||
name : string(STR_GRF_NAME); |
name : string(STR_GRF_NAME); |
||
| + | </pre> |
||
The name of the grf. In NML nearly all strings are put in [[NML:Language files|language files]]. The format of the language files is described in another section. For now just assume a string with the name <code style="color:darkgreen">STR_GRF_NAME</code> exists. To reference a string from the language file you use <code style="color:darkgreen">string(<stringname>)</code> where <code style="color:darkgreen"><stringname></code> should be replaced by the actual name of the string. |
The name of the grf. In NML nearly all strings are put in [[NML:Language files|language files]]. The format of the language files is described in another section. For now just assume a string with the name <code style="color:darkgreen">STR_GRF_NAME</code> exists. To reference a string from the language file you use <code style="color:darkgreen">string(<stringname>)</code> where <code style="color:darkgreen"><stringname></code> should be replaced by the actual name of the string. |
||
| + | <pre style="color:blue"> |
||
desc : string(STR_GRF_DESCRIPTION); |
desc : string(STR_GRF_DESCRIPTION); |
||
| + | </pre> |
||
This looks a lot like the previous line, only it sets the description instead of the name. |
This looks a lot like the previous line, only it sets the description instead of the name. |
||
| + | <pre style="color:blue"> |
||
version : 10; |
version : 10; |
||
| + | </pre> |
||
For a new grf you should set the version to 1. Every time you release a new version you should increase the version field by at least 1. |
For a new grf you should set the version to 1. Every time you release a new version you should increase the version field by at least 1. |
||
| + | <pre style="color:blue"> |
||
min_compatible_version : 5; |
min_compatible_version : 5; |
||
| + | </pre> |
||
| − | For a new |
+ | For a new NewGRF you should set the min_compatible_version to 1. Every time you change something in your newgrf which makes it incompatible to previous versions, you should set min_compatible_version to the current version. Changes which make a NewGRF incompatible to previous versions are most functional changes to existing behaviour, among others: changing vehicleIDs as well as some of their properties, changing industry layouts, railtype compatibility, changing (de-)activation conditions... Adding new, additional things and expanding existing behaviour (without changing the current one) is mostly considered safe). |
| + | <pre style="color:blue"> |
||
} |
} |
||
| + | </pre> |
||
This marks the end of the last-opened block, in this case the grf-block. |
This marks the end of the last-opened block, in this case the grf-block. |
||
Revision as of 17:35, 21 August 2011
Vehicles, Stations, Canals, Bridges, Towns, Houses, Industries (Tiles), Cargos, Airports+Tiles, Objects, Railtypes, Roadtypes, Tramtypes, Terrain
NML files are mainly composed from blocks. A block starts with the type of the block, optional arguments and then the contents enclosed by curly braces. Nearly all NML files will start with a grf-block. The grf-block takes no parameters and is one of the simplest blocks there is. Following is an example grf-block.
grf {
grfid : "AB\02\03";
name : string(STR_GRF_NAME);
desc : string(STR_GRF_DESCRIPTION);
version: 10;
min_compatible_version: 5;
}
Let's look at this code line for line.
grf {
This block is a grf-block. A grf-block has no parameters. The '{' is the start of the block content.
grfid : "AB\02\03";
This line sets the grfid of the resulting grf. The value is the letters AB followed by a byte with value 2 and then another one with value 3. The semicolon marks the end of the statement.
name : string(STR_GRF_NAME);
The name of the grf. In NML nearly all strings are put in language files. The format of the language files is described in another section. For now just assume a string with the name STR_GRF_NAME exists. To reference a string from the language file you use string(<stringname>) where <stringname> should be replaced by the actual name of the string.
desc : string(STR_GRF_DESCRIPTION);
This looks a lot like the previous line, only it sets the description instead of the name.
version : 10;
For a new grf you should set the version to 1. Every time you release a new version you should increase the version field by at least 1.
min_compatible_version : 5;
For a new NewGRF you should set the min_compatible_version to 1. Every time you change something in your newgrf which makes it incompatible to previous versions, you should set min_compatible_version to the current version. Changes which make a NewGRF incompatible to previous versions are most functional changes to existing behaviour, among others: changing vehicleIDs as well as some of their properties, changing industry layouts, railtype compatibility, changing (de-)activation conditions... Adding new, additional things and expanding existing behaviour (without changing the current one) is mostly considered safe).
}
This marks the end of the last-opened block, in this case the grf-block.
