NML:Error

NewGRF Meta Language

Preface

Getting started

Graphics files

Blocks

Units

Expressions

Elementary values

Builtin functions

Language files

Lists of props, vars and CBs

Warnings

Additional references

NewGRF compatibility

Deprecated syntax

Changes from NML 0.2 to 0.3

Changes from NML 0.3 to 0.4

Changes from NML 0.4 to 0.5

Vehicles, Stations, Canals, Bridges, Towns, Houses, Industries (Tiles), Cargos, Airports+Tiles, Objects, Railtypes, Roadtypes, Tramtypes, Terrain

NML Tutorial

Block Syntax

GRF

• GRF parameters

Item

• Property
• Graphics
• Livery override

Realsprites

Recolour sprites

Template

Spriteset

Spritegroup

Spritelayout

Tilelayout

Switch

Produce

Random switch

Cargotable

Railtypetable / Roadtypetable / Tramtypetable

If/else

While

Error

Disable items

Deactivate other NewGRFs

Testing for other NewGRFs

Overriding vehicles in other NewGRFs

Sprite replacement

• Replace TTD sprites
• Replace new sprites
• Add font glyphs

Alternative (32bpp) sprites

Town names

• Town names parts

Snow line

Parameter assignment

Setting base costs

Sorting vehicles in the purchase list

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}