NML:Error - Revision history

Juzza1 at 13:02, 18 September 2013

2013-09-18T13:02:33Z

@@ Line 7: / Line 7: @@
 where
 * <code>level</code> is the severity of the message and one of <code style="color:darkgreen">NOTICE, WARNING, ERROR, FATAL</code>.
 * <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".

Hirundo: General documentation fixup

2011-09-04T11:20:20Z

General documentation fixup

← Older revision		Revision as of 11:20, 4 September 2011
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>.
			* <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 23:
	\| 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 26:		Line 31:
	\| INVALID_PARAMETER		\| INVALID_PARAMETER
	\| "Invalid parameter for {STRING}: parameter {STRING} ({COMMA})"		\| "Invalid parameter for {STRING}: parameter {STRING} ({COMMA})"
	\| extra_text should be the parameter number written out as string. {COMMA} 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 47:
	\| 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 {COMMA}-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 56:
	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}

Planetmaker: {PARAM} is deprecated. Use {COMMA} instead

2011-09-03T12:46:49Z

{PARAM} is deprecated. Use {COMMA} instead

← Older revision		Revision as of 12:46, 3 September 2011
Line 25:		Line 25:
	\|-		\|-
	\| 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.		\| extra_text should be the parameter number written out as string. {COMMA} is replaced by parameter1. filled in.
	\|-		\|-
	\| MUST_LOAD_BEFORE		\| MUST_LOAD_BEFORE
Line 42:		Line 42:
	\| 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 '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.
	\|}		\|}

FooBar: add nav template

2011-08-21T16:34:15Z

add nav template

← Older revision		Revision as of 16:34, 21 August 2011
Line 1:		Line 1:
			{{NMLNavBlocksyntax}}

	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]]])

FooBar: content of nml r1625

2011-08-21T11:34:19Z

content of nml r1625

New page

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 <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"
! 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} ({PARAM})"
| extra_text should be the parameter number written out as string. {PARAM} is replaced by parameter1. filled in.
|-
| MUST_LOAD_BEFORE
| "{STRING} must be loaded before {STRING}."
| NewGRF name
|-
| MUST_LOAD_AFTER
| "{STRING} must be loaded after {STRING}."
| NewGRF name
|-
| 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 {PARAM}-codes that will be replaced by the contents of parameter1 and parameter2.
|}

For example:

<pre style="color:blue">
error(NOTICE, USED_WITH, string(STR_REGRESSION_CARE));
error(FATAL, string(STR_REGRESSION_ERROR), string(STR_ANSWER), 14, param[1] + 12 * param[2]);
</pre>