Difference between revisions of "NML:Block Example"

From GRFSpecs
Jump to navigationJump to search
(content of nml r1625)
 
m (adjust heading)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  +
== An example 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.
 
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 8: Line 10:
 
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(&lt;stringname&gt;)</code> where <code style="color:darkgreen">&lt;stringname&gt;</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(&lt;stringname&gt;)</code> where <code style="color:darkgreen">&lt;stringname&gt;</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 grf 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).
+
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.

Latest revision as of 14:22, 27 May 2013

An example 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 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.