Difference between revisions of "NML:Error"

From GRFSpecs
Jump to navigationJump to search
(add nav template)
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
The general form of an error statement is:
 
The general form of an error statement is:
   
error(level, message[, extra_text[, parameter1[, parameter2]]])
+
error(level, message[, extra_text[, parameter1[, parameter2]]]);
  +
  +
where
  +
* <code>level</code> is the severity of the message and one of <code style="color:darkgreen">NOTICE, WARNING, ERROR, FATAL</code>.
  +
  +
  +
{|
  +
!Severity!!Meaning!!Prefix!!Action taken
  +
|-
  +
|NOTICE||Notice||(none)||continue loading grf file
  +
|-
  +
|WARNING||Warning||"Warning: "||continue loading grf file
  +
|-
  +
|ERROR||Error||"Error: "||continue loading grf file
  +
|-
  +
|FATAL||Fatal error||"Error: "||abort loading of grf file
  +
|}
  +
  +
  +
* <code>message</code> can be either a user-defined string or it can be one of the pre-defined strings which already have translations. The first {STRING}-code will always be replaced by the NewGRF name. The second {STRING}-code (if present) will be replaced by the value of <code>extra_text</code>.
 
* <code>extra_text</code> can be a string defined in the language files or it can be a literal string, in which case it cannot be translated. You should only use a literal string in those cases where you are sure it doesn't have to be translated, for example to provide a version string like "0.7.0".
  +
* <code>parameter1</code>, <code>parameter2</code> are numeric parameters than can have any value, these can be used in the string using {COMMA}-codes.
   
where level is the severity of the message and one of <code style="color:darkgreen">NOTICE, WARNING, ERROR, FATAL</code>. The message can be either a custom defined string which can contain up to two parameters or it can be one of the pre-defined strings which already have translations. The first {STRING}-code will always be replaced by the NewGRF name. The second {STRING}-code will be replaced by the value of 'extra_text'. Extra_text can be a string defined in the language files or it can be a literal string, in which case it cannot be translated. You should only use a literal string in those cases where you are sure it doesn't have to be translated, for example to provide a version string like "0.7.0".
 
   
 
{| class="t"
 
{| class="t"
Line 18: Line 38:
 
| REQUIRES_DOS_WINDOWS
 
| REQUIRES_DOS_WINDOWS
 
| "{STRING} is for the {STRING} version of TTD."
 
| "{STRING} is for the {STRING} version of TTD."
| [DOS | Windows] Palette type
+
| [DOS <nowiki>|</nowiki> Windows] Palette type
 
|-
 
|-
 
| USED_WITH
 
| USED_WITH
Line 25: Line 45:
 
|-
 
|-
 
| INVALID_PARAMETER
 
| INVALID_PARAMETER
| "Invalid parameter for {STRING}: parameter {STRING} ({PARAM})"
+
| "Invalid parameter for {STRING}: parameter {STRING} ({COMMA})"
| extra_text should be the parameter number written out as string. {PARAM} is replaced by parameter1. filled in.
+
| <code>extra_text</code> should be the parameter number written out as string. {COMMA} is replaced by the value of <code>parameter1</code>
 
|-
 
|-
 
| MUST_LOAD_BEFORE
 
| MUST_LOAD_BEFORE
 
| "{STRING} must be loaded before {STRING}."
 
| "{STRING} must be loaded before {STRING}."
| NewGRF name
+
| NewGRF name of the other grf
 
|-
 
|-
 
| MUST_LOAD_AFTER
 
| MUST_LOAD_AFTER
 
| "{STRING} must be loaded after {STRING}."
 
| "{STRING} must be loaded after {STRING}."
| NewGRF name
+
| NewGRF name of the other grf
 
|-
 
|-
 
| REQUIRES_OPENTTD
 
| REQUIRES_OPENTTD
Line 42: Line 62:
 
| string(STR_MY_ERROR_MESSAGE)
 
| string(STR_MY_ERROR_MESSAGE)
 
| (user-defined string)
 
| (user-defined string)
| The message-string can use the code {STRING} up to 2 times, the first usage will be replaced by the NewGRF name and the second usage by 'extra_text'. After 2 {STRING}-codes you can include up to 2 {PARAM}-codes that will be replaced by the contents of parameter1 and parameter2.
+
| The message-string can use the code {STRING} up to 2 times, the first usage will be replaced by the NewGRF name and the second usage by <code>extra_text</code>. After 2 {STRING}-codes you can include up to 2 {COMMA}-codes that will be replaced by the contents of <code>parameter1</code> and <code>parameter2</code>. See also the note below.
 
|}
 
|}
   
Line 51: Line 71:
 
error(FATAL, string(STR_REGRESSION_ERROR), string(STR_ANSWER), 14, param[1] + 12 * param[2]);
 
error(FATAL, string(STR_REGRESSION_ERROR), string(STR_ANSWER), 14, param[1] + 12 * param[2]);
 
</pre>
 
</pre>
  +
  +
Note that only the following combinations of string codes are valid in custom strings:
  +
* {STRING}
  +
* {STRING}{STRING}
  +
* {STRING}{STRING}{COMMA}
  +
* {STRING}{STRING}{COMMA}{COMMA}

Latest revision as of 13:02, 18 September 2013

Block Syntax

The general form of an error statement is:

error(level, message[, extra_text[, parameter1[, parameter2]]]);

where

  • level is the severity of the message and one of NOTICE, WARNING, ERROR, FATAL.


Severity Meaning Prefix Action taken
NOTICE Notice (none) continue loading grf file
WARNING Warning "Warning: " continue loading grf file
ERROR Error "Error: " continue loading grf file
FATAL Fatal error "Error: " abort loading of grf file


  • message can be either a user-defined string or it can be one of the pre-defined strings which already have translations. The first {STRING}-code will always be replaced by the NewGRF name. The second {STRING}-code (if present) will be replaced by the value of extra_text.
  • extra_text can be a string defined in the language files or it can be a literal string, in which case it cannot be translated. You should only use a literal string in those cases where you are sure it doesn't have to be translated, for example to provide a version string like "0.7.0".
  • parameter1, parameter2 are numeric parameters than can have any value, these can be used in the string using {COMMA}-codes.


name actual text Contents of extra_text
REQUIRES_TTDPATCH "{STRING} requires at least TTDPatch version {STRING}" version string
REQUIRES_DOS_WINDOWS "{STRING} is for the {STRING} version of TTD." [DOS | Windows] Palette type
USED_WITH "{STRING} is designed to be used with {STRING}" switchname + value, e.g. "multihead 0". This is designed to be used for incompatible settings that you can check via ttdpatch_flags.
INVALID_PARAMETER "Invalid parameter for {STRING}: parameter {STRING} ({COMMA})" extra_text should be the parameter number written out as string. {COMMA} is replaced by the value of parameter1
MUST_LOAD_BEFORE "{STRING} must be loaded before {STRING}." NewGRF name of the other grf
MUST_LOAD_AFTER "{STRING} must be loaded after {STRING}." NewGRF name of the other grf
REQUIRES_OPENTTD "{STRING} requires OpenTTD version {STRING} or better." version string
string(STR_MY_ERROR_MESSAGE) (user-defined string) The message-string can use the code {STRING} up to 2 times, the first usage will be replaced by the NewGRF name and the second usage by extra_text. After 2 {STRING}-codes you can include up to 2 {COMMA}-codes that will be replaced by the contents of parameter1 and parameter2. See also the note below.

For example:

 error(NOTICE, USED_WITH, string(STR_REGRESSION_CARE));
 error(FATAL, string(STR_REGRESSION_ERROR), string(STR_ANSWER), 14, param[1] + 12 * param[2]);

Note that only the following combinations of string codes are valid in custom strings:

  • {STRING}
  • {STRING}{STRING}
  • {STRING}{STRING}{COMMA}
  • {STRING}{STRING}{COMMA}{COMMA}