DECORATE state syntax - Revision history

Printz: /* Labels */

2025-08-23T17:13:48Z

Labels

← Older revision		Revision as of 13:13, 23 August 2025
Line 80:		Line 80:
	*'''Pickup.Respawn''': state to jump to when the gettable item thing has the '''RAVENRESPAWN''' flag and is picked up, after which it waits to respawn;		*'''Pickup.Respawn''': state to jump to when the gettable item thing has the '''RAVENRESPAWN''' flag and is picked up, after which it waits to respawn;
	*'''Pickup.Remove''': state to jump to when the gettable item thing has the '''RAVENRESPAWN''' flag and is picked up, after which it is removed permanently without respawning. This applies for items which for any reasons must not respawn, such as individual dropped items. It's a property of the particular item, not of the entire thingtype class, so be sure to also include a '''Pickup.Respawn''' state.		*'''Pickup.Remove''': state to jump to when the gettable item thing has the '''RAVENRESPAWN''' flag and is picked up, after which it is removed permanently without respawning. This applies for items which for any reasons must not respawn, such as individual dropped items. It's a property of the particular item, not of the entire thingtype class, so be sure to also include a '''Pickup.Respawn''' state.
			*'''Crunch''' or '''Crush''': equivalent of '''crunchstate''': optional state to go into when crushed as a dead body by a door or any other sector type. Default depends on game mode. It may be nothing if game mode doesn't specify anything, in which case there's no transition.
	====Damage type pain and death states====		====Damage type pain and death states====
	You can also add labels for means-of-death (damage type) specific pain and death states. They're equivalent to the '''dmg_painstates''' and '''dmg_deathstates''' thingype fields. You formulate them as such:		You can also add labels for means-of-death (damage type) specific pain and death states. They're equivalent to the '''dmg_painstates''' and '''dmg_deathstates''' thingype fields. You formulate them as such:

Printz: /* Syntax */

2020-05-03T15:13:17Z

Syntax

← Older revision		Revision as of 11:13, 3 May 2020
Line 19:		Line 19:
	<tics> := [0-9]+		<tics> := [0-9]+
	<flagslist> := <flag><flagslist>		<flagslist> := <flag><flagslist>
	<flag> := "bright" \| "fast" \| "offset" '(' <x> ',' <y> ')' \| nil		<flag> := "bright" \| "fast" \| "offset" '(' <x> ',' <y> [',' "interpolate"] ')' \| nil
	<action> := <name>		<action> := <name>
	\| <name> '(' <arglist> ')'		\| <name> '(' <arglist> ')'
Line 95:		Line 95:
	**'''bright''': causes the sprite to be full bright in any place;		**'''bright''': causes the sprite to be full bright in any place;
	**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);		**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);
	**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect — otherwise the offset will be preserved from the previous frame. You can override the 0 condition choice (Doom/non-Doom) in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier. In the classic games original designs, only Hexen has used '''offset''', in order to animate its melee weapons.		**'''offset'''(''x'', ''y''[, '''interpolate''']): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect — otherwise the offset will be preserved from the previous frame. You can override the 0 condition choice (Doom/non-Doom) in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier. In the classic games original designs, only Hexen has used '''offset''', in order to animate its melee weapons.
			::If '''interpolate''' is added, it causes the movement between offsets to be smooth. By default interpolation is disabled when '''offset''' is specified.
	*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.		*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.

Printz: /* Frames */

2020-04-08T05:53:57Z

Frames

← Older revision		Revision as of 01:53, 8 April 2020
Line 95:		Line 95:
	**'''bright''': causes the sprite to be full bright in any place;		**'''bright''': causes the sprite to be full bright in any place;
	**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);		**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);
	**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the ~~setting~~ in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier. In the classic games original designs, only Hexen has used '''offset''', in order to animate its melee weapons.		**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect — otherwise the offset will be preserved from the previous frame. You can override the 0 condition choice (Doom/non-Doom) in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier. In the classic games original designs, only Hexen has used '''offset''', in order to animate its melee weapons.
	*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.		*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.

Printz: /* Frames */

2020-04-08T05:52:29Z

Frames

← Older revision		Revision as of 01:52, 8 April 2020
Line 95:		Line 95:
	**'''bright''': causes the sprite to be full bright in any place;		**'''bright''': causes the sprite to be full bright in any place;
	**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);		**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);
	**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the setting in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier.		**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the setting in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier. In the classic games original designs, only Hexen has used '''offset''', in order to animate its melee weapons.
	*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.		*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.

Printz: /* Frames */

2020-04-08T05:50:55Z

Frames

← Older revision		Revision as of 01:50, 8 April 2020
Line 95:		Line 95:
	**'''bright''': causes the sprite to be full bright in any place;		**'''bright''': causes the sprite to be full bright in any place;
	**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);		**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);
	**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the setting in [[gameproperties]].		**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the setting in [[gameproperties]]. Beware that ''y'' has the origin at 32. An offset of (0, 32) keeps the weapon at the origin, but because of Doom's rules, you may need to have (1, 32) or (-1, 32) instead. Do note that this '''offset''' vector has been available in vanilla Doom as well, modifiable under [[DeHackEd]], and it is the same thing as the '''misc1''' and '''misc2''' [[frame]] fields, which means these work as parameters for several [[MBF]] [[codepointers]]. However, currently you cannot use strings or other expressions in ''x'' and ''y'', unlike when using the full '''frame''' section or the '''cmp''' specifier.
	*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.		*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.

Line 101:		Line 101:
	Some codepointers, such as [[CounterJump]], [[Jump]] and so on let the calling thing jump to specific frames. For the frame name parameter, just use the label name.		Some codepointers, such as [[CounterJump]], [[Jump]] and so on let the calling thing jump to specific frames. For the frame name parameter, just use the label name.

	The MBF-based [[RandomJump]] uses the '''misc1''' and '''misc2''' frame fields as parameters. Since the DECORATE style syntax currently ~~doesn't support~~ '''misc1''' and '''misc2''', you ~~have to use~~ [[Jump]], which uses args, is based on ZDoom's implementation and only works for DECORATE state syntax. Other codepointers, such as [[CounterJump]], work both for non-DECORATE and DECORATE syntax. Certain codepointers such as [[CounterSwitch]] aren't designed for DECORATE state syntax however.		The MBF-based [[RandomJump]] uses the '''misc1''' and '''misc2''' frame fields as parameters. Since the DECORATE style syntax currently only supports '''misc1''' and '''misc2''' through the '''offset''' specifier, you are better off using [[Jump]], which uses args, is based on ZDoom's implementation and only works for DECORATE state syntax. Other codepointers, such as [[CounterJump]], work well both for non-DECORATE and DECORATE syntax. Certain codepointers such as [[CounterSwitch]] aren't designed for DECORATE state syntax however.

	===Keywords===		===Keywords===

Printz: /* Frames */

2020-04-08T05:44:07Z

Frames

← Older revision		Revision as of 01:44, 8 April 2020
Line 92:		Line 92:
	*''frame_letters'': this is one or more letters corresponding to the sprite frame index. Include more than one letter if you want a sequence of frames with the same properties (duration, flags and action).		*''frame_letters'': this is one or more letters corresponding to the sprite frame index. Include more than one letter if you want a sequence of frames with the same properties (duration, flags and action).
	*''tics'': the duration, in tics (1/35 seconds), of each frame. Do not use value 0 in loops. Setting value -1 will cause the thing to stop at that frame, without going forward.		*''tics'': the duration, in tics (1/35 seconds), of each frame. Do not use value 0 in loops. Setting value -1 will cause the thing to stop at that frame, without going forward.
	*''flags_list'': zero or more flags, separated by spaces. ~~Currently the~~ flags ~~are~~ '''bright'''~~, which~~ causes the sprite to be full bright in any place~~, and~~ '''fast'''~~, which~~ makes the frame take half as long on fast skill levels (used in Doom by the demons).		*''flags_list'': zero or more flags, separated by spaces. The flags can be:
			**'''bright''': causes the sprite to be full bright in any place;
			**'''fast''': makes the frame take half as long on fast skill levels (used in Doom by the demons);
			**'''offset'''(''x'', ''y''): useful for weapon HUD sprites, causes the image to be offset by the exact amount of ''x'' and ''y'' from the center-bottom, overriding the current bob amount. Under Doom, ''x'' must be nonzero for both offsets to have effect; under other games, each of them needs to be nonzero for each of them to have effect. You can override the setting in [[gameproperties]].
	*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.		*''action'': this can be a [[List of codepointers\|codepointer]], optionally followed by a list of arguments enclosed by parentheses. Make sure to include strings in double quotes (""). Conventionally, from ZDoom, and based on the Doom source code in general, codepointers are prefixed with '''A_''', but it is not required here.

Printz: /* Syntax */

2020-04-08T05:41:03Z

Syntax

← Older revision		Revision as of 01:41, 8 April 2020
Line 19:		Line 19:
	<tics> := [0-9]+		<tics> := [0-9]+
	<flagslist> := <flag><flagslist>		<flagslist> := <flag><flagslist>
	<flag> := "bright" \| "fast" \| nil		<flag> := "bright" \| "fast" \| "offset" '(' <x> ',' <y> ')' \| nil
	<action> := <name>		<action> := <name>
	\| <name> '(' <arglist> ')'		\| <name> '(' <arglist> ')'

Printz: /* Labels */ heal

2016-02-21T19:13:07Z

Labels: heal

← Older revision		Revision as of 15:13, 21 February 2016
Line 74:		Line 74:
	*'''XDeath''': equivalent of '''xdeathstate''': optional state the thing goes into when killed with very high damage;		*'''XDeath''': equivalent of '''xdeathstate''': optional state the thing goes into when killed with very high damage;
	*'''Raise''': equivalent of '''raisestate''': optional state the corpse goes into when raised by an archvile;		*'''Raise''': equivalent of '''raisestate''': optional state the corpse goes into when raised by an archvile;
			*'''Heal''' (since Feb 21 2016): equivalent of '''healstate''': state to jump to if during [[VileChase]] it encounters a corpse. If not set, it will just go into S_VILE_HEAL1.
	*'''Crash''': equivalent of '''crashstate''': optional state for a corpse to go into when falling and hitting the floor;		*'''Crash''': equivalent of '''crashstate''': optional state for a corpse to go into when falling and hitting the floor;
	*'''Active''': equivalent of '''activestate''': optional state to go into when triggered by [[Detailed parameterized linedef specification#Things\|Thing_Activate]];		*'''Active''': equivalent of '''activestate''': optional state to go into when triggered by [[Detailed parameterized linedef specification#Things\|Thing_Activate]];

Printz: Elaborated the document

2016-02-21T10:04:32Z

Elaborated the document

@@ Line 1: / Line 1: @@
-EDF allows using a concise ZDoom DECORATE-style state syntax for [[thingtype|thing types]], by using the '''states''' field, followed by a heredoc (multiline string). The syntax is described in detail [http://zdoom.org/wiki/Actor_states here], in the ZDoom wiki.
+EDF allows using a concise ZDoom DECORATE-style state syntax for [[thingtype|thing types]], by using the '''states''' field, followed by a heredoc (multiline string). The syntax is based on the one from ZDoom, described [http://zdoom.org/wiki/Actor_states here], in the ZDoom wiki.
 Note that DECORATE errors in Eternity will trigger warnings at startup which can only be observed with -edfout or -edf-show-warnings during the text-mode part of the program initialization. You can press the ''Pause'' key during that sequence to read the warning messages. Usually in these cases, the DECORATE state definition is fully disabled.
 {{Backto|EDF state reference}}
 ==Differences from ZDoom's DECORATE==
 * The frame after a '''goto''' line must be labelled in Eternity. Of course, labels can be native (spawn, see, pain etc.)  or user-defined.
 [[category:EDF]]

Printz at 19:21, 3 March 2012

2012-03-03T19:21:57Z

← Older revision		Revision as of 15:21, 3 March 2012
Line 1:		Line 1:
	EDF allows using a concise ZDoom DECORATE-style state syntax for [[thingtype\|thing types]], by using the '''states''' field, followed by a heredoc (multiline string). The syntax is described in detail [http://zdoom.org/wiki/Actor_states here], in the ZDoom wiki.		EDF allows using a concise ZDoom DECORATE-style state syntax for [[thingtype\|thing types]], by using the '''states''' field, followed by a heredoc (multiline string). The syntax is described in detail [http://zdoom.org/wiki/Actor_states here], in the ZDoom wiki.

	----		Note that DECORATE errors in Eternity will trigger warnings at startup which can only be observed with -edfout or -edf-show-warnings during the text-mode part of the program initialization. You can press the ''Pause'' key during that sequence to read the warning messages. Usually in these cases, the DECORATE state definition is fully disabled.
	~~Back to~~ [[~~Editing reference~~]].		{{Backto\|EDF state reference}}
			==Differences from ZDoom's DECORATE==
			* The frame after a '''goto''' line must be labelled in Eternity. Of course, labels can be native (spawn, see, pain etc.) or user-defined.

			[[category:EDF]]