Difference between revisions of "NML:Block Example"
Planetmaker (talk | contribs) (add title line) |
Planetmaker (talk | contribs) m (Planetmaker moved page NML:Blocks to NML:Block Example) |
(No difference)
|
Revision as of 14:00, 27 May 2013
Blocks
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.