NML:Switch - Revision history

Frosch: update parent scopes

2025-04-14T14:55:14Z

update parent scopes

← Older revision		Revision as of 14:55, 14 April 2025
Line 86:		Line 86:
	\| FEAT_AIRPORTS		\| FEAT_AIRPORTS
	\| Airport		\| Airport
	\| ~~N/A~~		\| Town
	\| yes		\| yes
	\|-		\|-
Line 106:		Line 106:
	\| FEAT_AIRPORTTILES		\| FEAT_AIRPORTTILES
	\| Airport tile		\| Airport tile
	\| ~~N/A~~		\| Airport
	\| no		\| no
	\|-		\|-
Line 117:		Line 117:
	\| Tramtype on tile		\| Tramtype on tile
	\| N/A		\| N/A
			\| no
			\|-
			\| FEAT_ROADSTOPS
			\| Road stop
			\| Town
	\| no		\| no
	\|}		\|}

Heresy: Changed from table to sortable.

2022-08-30T21:31:40Z

Changed from table to sortable.

← Older revision		Revision as of 21:31, 30 August 2022
Line 13:		Line 13:
	* <code style="color:darkgreen"><expression></code>: The expression that will be evaluated to make a decision. This expression may contain variables. Instead of a single expression this may also be an array of expressions. In that case all of the array elements are evaluated in order and the last one is used to make a decision.		* <code style="color:darkgreen"><expression></code>: The expression that will be evaluated to make a decision. This expression may contain variables. Instead of a single expression this may also be an array of expressions. In that case all of the array elements are evaluated in order and the last one is used to make a decision.

	{\| class="t"		{\| class="wikitable sortable"
	! Feature		! Feature
	! SELF		! SELF

Andythenorth: Add FEAT_ROADTYPES and FEAT_TRAMTYPES to table

2021-07-07T18:29:19Z

Add FEAT_ROADTYPES and FEAT_TRAMTYPES to table

@@ Line 106: / Line 106: @@
 | FEAT_AIRPORTTILES
 | Airport tile
 | N/A
 | no

Supercheese: Airport Tiles do not have access to a PARENT scope

2015-07-05T00:17:01Z

Airport Tiles do not have access to a PARENT scope

← Older revision		Revision as of 00:17, 5 July 2015
Line 106:		Line 106:
	\| FEAT_AIRPORTTILES		\| FEAT_AIRPORTTILES
	\| Airport tile		\| Airport tile
	\| ~~Airport~~		\| N/A
	\| no		\| no
	\|}		\|}

Planetmaker: missing spaces

2014-02-22T08:52:30Z

missing spaces

← Older revision		Revision as of 08:52, 22 February 2014
Line 9:		Line 9:

	* <code style="color:darkgreen"><feature></code>: The feature for which this switch is used (see [[NML:Features\|Features]]).		* <code style="color:darkgreen"><feature></code>: The feature for which this switch is used (see [[NML:Features\|Features]]).
	* <code style="color:darkgreen">(SELF\|PARENT)</code>Which variables to use. SELF uses the variables of the item itself, while PARENT uses the variables of a related object. This related object differs per feature, refer to the table below.		* <code style="color:darkgreen">(SELF\|PARENT)</code>: Which variables to use. SELF uses the variables of the item itself, while PARENT uses the variables of a related object. This related object differs per feature, refer to the table below.
	* <code style="color:darkgreen"><ID></code>Name of this switch block. This (unique) name can be used to refer to the block from other switch- or graphics-blocks.		* <code style="color:darkgreen"><ID></code>: Name of this switch block. This (unique) name can be used to refer to the block from other switch- or graphics-blocks.
	* <code style="color:darkgreen"><expression></code>The expression that will be evaluated to make a decision. This expression may contain variables. Instead of a single expression this may also be an array of expressions. In that case all of the array elements are evaluated in order and the last one is used to make a decision.		* <code style="color:darkgreen"><expression></code>: The expression that will be evaluated to make a decision. This expression may contain variables. Instead of a single expression this may also be an array of expressions. In that case all of the array elements are evaluated in order and the last one is used to make a decision.

	{\| class="t"		{\| class="t"

Alberth: let's call the feature a feature instead of an expression

2014-02-19T21:41:00Z

let's call the feature a feature instead of an expression

← Older revision		Revision as of 21:41, 19 February 2014
Line 1:		Line 1:
	{{NMLNavBlocksyntax}}		{{NMLNavBlocksyntax}}

	switch (<~~expression~~>, (SELF\|PARENT), <ID>, <expression>) {		switch (<feature>, (SELF\|PARENT), <ID>, <expression>) {
	(<range>: <return_value>;)*		(<range>: <return_value>;)*
	<return_value>;		<return_value>;
Line 8:		Line 8:
	The four parameters have the following meaning:		The four parameters have the following meaning:

	* <code style="color:darkgreen"><~~expression~~></code>: The feature for which this switch is used (see [[NML:Features\|Features]]).		* <code style="color:darkgreen"><feature></code>: The feature for which this switch is used (see [[NML:Features\|Features]]).
	* <code style="color:darkgreen">(SELF\|PARENT)</code>Which variables to use. SELF uses the variables of the item itself, while PARENT uses the variables of a related object. This related object differs per feature, refer to the table below.		* <code style="color:darkgreen">(SELF\|PARENT)</code>Which variables to use. SELF uses the variables of the item itself, while PARENT uses the variables of a related object. This related object differs per feature, refer to the table below.
	* <code style="color:darkgreen"><ID></code>Name of this switch block. This (unique) name can be used to refer to the block from other switch- or graphics-blocks.		* <code style="color:darkgreen"><ID></code>Name of this switch block. This (unique) name can be used to refer to the block from other switch- or graphics-blocks.

Hirundo: Add note about new possibilities for defaults

2012-09-11T22:01:46Z

Add note about new possibilities for defaults

← Older revision		Revision as of 22:01, 11 September 2012
Line 135:		Line 135:

	You can also use temporary variables and with some features also pemanent variables to store and retrieve some values by means of <code style="color:darkgreen">STORE_TEMP(value, register)</code>, <code style="color:darkgreen">LOAD_TEMP(register)</code> and <code style="color:darkgreen">STORE_PERM(value, register)</code> and <code style="color:darkgreen">LOAD_PERM(register[, grfid])</code> respectively. Using temporary storage is useful when you want to use the result of an expensive calculation in various decisions (switches) within the chain (like for example the number of a certain wagon type within a train). Permanent storage might be useful to control the long-term behaviour of an object. Note that it is only available for industries, airports and towns. For towns, you can optionally specify a grfid to load registers belonging to a different grf. Note that accessing (both reading and writing) permanent town registers thrashes the contents of temporary register 0x100.		You can also use temporary variables and with some features also pemanent variables to store and retrieve some values by means of <code style="color:darkgreen">STORE_TEMP(value, register)</code>, <code style="color:darkgreen">LOAD_TEMP(register)</code> and <code style="color:darkgreen">STORE_PERM(value, register)</code> and <code style="color:darkgreen">LOAD_PERM(register[, grfid])</code> respectively. Using temporary storage is useful when you want to use the result of an expensive calculation in various decisions (switches) within the chain (like for example the number of a certain wagon type within a train). Permanent storage might be useful to control the long-term behaviour of an object. Note that it is only available for industries, airports and towns. For towns, you can optionally specify a grfid to load registers belonging to a different grf. Note that accessing (both reading and writing) permanent town registers thrashes the contents of temporary register 0x100.

			{{nml\|0.3}} As of NML 0.3 it is possible to specify the default value using <code>default: <value>;</code> as one of the 'ranges'. Specifying multiple default values (either this way or by the classical method) is of course not possible, but omitting a default value is allowed. In that case, if none of the ranges matches, the callback fails.

FooBar: add nav template

2011-08-21T16:32:43Z

add nav template

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

	switch (<expression>, (SELF\|PARENT), <ID>, <expression>) {		switch (<expression>, (SELF\|PARENT), <ID>, <expression>) {
	(<range>: <return_value>;)*		(<range>: <return_value>;)*

FooBar: content of nml r1625

2011-08-21T11:29:33Z

content of nml r1625

New page

switch (<expression>, (SELF|PARENT), <ID>, <expression>) {
(<range>: <return_value>;)*
<return_value>;
}

The four parameters have the following meaning:

* <code style="color:darkgreen"><expression></code>: The feature for which this switch is used (see [[NML:Features|Features]]).
* <code style="color:darkgreen">(SELF|PARENT)</code>Which variables to use. SELF uses the variables of the item itself, while PARENT uses the variables of a related object. This related object differs per feature, refer to the table below.
* <code style="color:darkgreen"><ID></code>Name of this switch block. This (unique) name can be used to refer to the block from other switch- or graphics-blocks.
* <code style="color:darkgreen"><expression></code>The expression that will be evaluated to make a decision. This expression may contain variables. Instead of a single expression this may also be an array of expressions. In that case all of the array elements are evaluated in order and the last one is used to make a decision.

{| class="t"
! Feature
! SELF
! PARENT
! permanent<br />storage
|-
| FEAT_TRAINS
| Engine / wagon / articulated part itself
| Front engine
| no
|-
| FEAT_ROADVEHS
| Road vehicle part
| First road vehicle part
| no
|-
| FEAT_SHIPS
| Ship
| Ship
| no
|-
| FEAT_AIRCRAFT
| Aircraft (a)
| Aircraft
| no
|-
| FEAT_STATIONS
| Station tile
| Town
| no
|-
| FEAT_CANALS
| Canal tile
| N/A
| no
|-
| FEAT_BRIDGES
| Bridge
| Town
| no
|-
| FEAT_HOUSES
| House tile
| Town
| no
|-
| FEAT_GLOBALVARS
| N/A
| N/A
| no
|-
| FEAT_INDUSTRYTILES
| Industry tile
| Industry to which the tile belongs
| no
|-
| FEAT_INDUSTRIES
| Industry
| Town
| yes
|-
| FEAT_CARGOS
| Cargo type
| N/A
| no
|-
| FEAT_SOUNDEFFECTS
| N/A
| N/A
| no
|-
| FEAT_AIRPORTS
| Airport
| N/A
| yes
|-
| FEAT_SIGNALS
| N/A
| N/A
| no
|-
| FEAT_OBJECTS
| Object tile
| Town
| no
|-
| FEAT_RAILTYPES
| Rail tile
| N/A
| no
|-
| FEAT_AIRPORTTILES
| Airport tile
| Airport
| no
|}

(a) Except for mail capacity callbacks, where it refers to the mail compartment. To refer to the aircraft itself, use PARENT scope there.

<code style="color:darkgreen"><range></code> can either be a single number or two numbers separated by two dots. In the first case, the range matches if the result of the computation is equal to the supplied value. If a range (<code style="color:darkgreen">a .. b</code>) is supplied, it matches if the computed result is within that range. If several lines of the switch block match the expression being tested the first applicable result will be returned.

Possible values for <code style="color:darkgreen"><return_value></code> are the following:

* <code style="color:darkgreen"><ID>;</code> chains to the (random-)switch or spritegroup with the given ID.
* <code style="color:darkgreen">return (<expression>|<string>);</code> returns the given expression or string as a result of the callback. A returned expression may contain variables (with the same scope as the switch block itself), parameter accesses and everything else that a normal switch-expression may contain.
* <code style="color:darkgreen">return;</code> returns the computed value directly as a callback result. Note that the maximum value for callback results is 32511 (0x7EFF).
* <code style="color:darkgreen">CB_FAILED;</code> stops processing and returns an explicit failure code.

Some example code is given below. Note that the code does not have an actual meaning, it is merely meant to demonstrate all the various options available.

<pre style="color:blue">
switch (FEAT_TRAINS, PARENT, some_vehicle_switch, (position_in_consist + param[1]) % 4) {
0..2: return string(STRING_FOO_BAR); //return a text message
3: return; //return the computed value
5..300: return 42; //42 is always a good answer
400: other_switch; //chain to some other switch block
401: return num_vehs_in_consist + 1; //return a value with a variable access
CB_FAILED; //return a failure result as default
}
</pre>

You can also use temporary variables and with some features also pemanent variables to store and retrieve some values by means of <code style="color:darkgreen">STORE_TEMP(value, register)</code>, <code style="color:darkgreen">LOAD_TEMP(register)</code> and <code style="color:darkgreen">STORE_PERM(value, register)</code> and <code style="color:darkgreen">LOAD_PERM(register[, grfid])</code> respectively. Using temporary storage is useful when you want to use the result of an expensive calculation in various decisions (switches) within the chain (like for example the number of a certain wagon type within a train). Permanent storage might be useful to control the long-term behaviour of an object. Note that it is only available for industries, airports and towns. For towns, you can optionally specify a grfid to load registers belonging to a different grf. Note that accessing (both reading and writing) permanent town registers thrashes the contents of temporary register 0x100.