EventWML - Revision history

Soliton: /* turn refresh */

2026-02-06T21:10:33Z

‎turn refresh

Celtic Minstrel: /* Nested Events */ Try to clarify that nested events aren't permanently linked to their parent.

2025-07-22T12:10:46Z

‎Nested Events: Try to clarify that nested events aren't permanently linked to their parent.

Bssarkar: /* [filter_attack] */ add space

2025-02-02T10:48:38Z

‎[filter_attack]: add space

Celtic Minstrel: /* [filter_condition] */ excess punctuation

2025-01-06T19:00:35Z

‎[filter_condition]: excess punctuation

Laela: /* id */ when event has no id, but is in one [unit_type], there is no duplication, but when same event is provided by ability to multiple types, id is useful

2025-01-06T17:37:45Z

‎id: when event has no id, but is in one [unit_type], there is no duplication, but when same event is provided by ability to multiple types, id is useful

Soliton: /* die */

2024-08-05T06:46:38Z

‎die

Laela: /* Multiplayer safety */

2024-07-07T09:05:36Z

‎Multiplayer safety

Laela: unit hits, unit misses

2024-06-28T22:20:35Z

unit hits, unit misses

White haired uncle: Removed comment re: fixed issue github #4667

2024-03-24T17:13:56Z

Removed comment re: fixed issue github #4667

Soliton: /* pre advance */

2024-01-24T16:55:52Z

‎pre advance

@@ Line 377: / Line 377: @@
 Like '''side turn''', triggers just before a side is taking control but '''after''' healing, calculating income, and restoring unit movement and status. WML variable '''side_number''' holds the number of this side.
-Note that the turn refresh event does occur on turn 1, even though healing, income and unit refreshing do not.
+Note that the turn refresh event does occur on turn 1, even though healing (for side 1), income and unit refreshing do not.
 === turn ''X'' ===

@@ Line 204: / Line 204: @@
 === Nested Events ===
-There is one special type of action: event creation.  By placing an '''[event]''' tag inside another '''[event]''' tag, the nested event is spawned (created) when the parent (outer) event is encountered (when executing the contents of the parent event).
+There is one special type of action: event creation.  By placing an '''[event]''' tag inside another '''[event]''' tag, the nested event is spawned (created) when the parent (outer) event is encountered (when executing the contents of the parent event). Once created, there is no relation between the nested event and the parent event (for example, removing the parent event would not remove the nested event).
 ([[#Nested Event Example|See Examples]])

@@ Line 147: / Line 147: @@
 :* '''special_id''': filter on the attack's weapon special id.
 :* '''special_type''': filter on the attack's weapon special type.
-:* {{DevFeature1.17|15}} '''special_id_active''': filter on the attack's weapon special id active(encoded in [specials] or [abilities] tags).
+:* {{DevFeature1.17|15}} '''special_id_active''': filter on the attack's weapon special id active (encoded in [specials] or [abilities] tags).
-:* {{DevFeature1.17|15}} '''special_type_active''': filter on the attack's weapon special type active(encoded in [specials] or [abilities] tags).
+:* {{DevFeature1.17|15}} '''special_type_active''': filter on the attack's weapon special type active (encoded in [specials] or [abilities] tags).
 ==== [filter_second_attack] ====

@@ Line 154: / Line 154: @@
 ==== [filter_condition] ====
-: This tag makes sense inside any sort of event - even those that don't have units, or custom events,... The event will only trigger if this condition evaluates to true.
+: This tag makes sense inside any sort of event - even those that don't have units, or custom events. The event will only trigger if this condition evaluates to true.
 :* [[ConditionalActionsWML#Condition_Tags|Condition Tags]]
 : note: This tag is meant to be used when the firing of an event shall be based on variables/conditions which cannot be retrieved from the filtered units.

@@ Line 121: / Line 121: @@
 ==== id ====
-: If an id is specified, then the event will not be added if another event with the same id already exists. An id will also allow the event to be removed, see below. Supplying a non-empty id= is mandatory in case of a [unit_type][event].
+: If an id is specified, then the event will not be added if another event with the same id already exists. An id will also allow the event to be removed, see below. Supplying a non-empty id= is usually desired to avoid duplicates in case same [event] is used in multiple [unit_type] or ability/weapon special.
 ==== remove ====

@@ Line 563: / Line 563: @@
 === die ===
-Triggers when the primary unit is killed by the secondary unit. ''Note: The primary unit is not removed from the game until the end of this event. The primary unit can still be manipulated, will block other units from taking its hex, and will still be found by standard unit filters (except [have_unit]). To prevent this behavior, you can use [kill] to remove the unit immediately. However, this will stop any (still unfired) other events that also match the unit from firing afterwards, so use with caution.'' If you want to the primary unit to make a final [message], use name=last_breath, see above.
+Triggers when the primary unit is killed by the secondary unit. ''Note: The primary unit is not removed from the game until the end of this event. The primary unit can still be manipulated, will block other units from taking its hex, and will still be found by standard unit filters (except [have_unit]). To prevent this behavior, you can use [kill] to remove the unit immediately. However, this will stop any (still unfired) other events that also match the unit from firing afterwards, so use with caution.'' If you want the primary unit to make a final [message], use name=last_breath, see above.
 === capture ===

@@ Line 244: / Line 244: @@
 * defender hits
 * defender misses
 * start
 * prestart (prestart are synced but [message][option] & [unstore_unit] advancement choices will do a random decision because UI things don't work during prestart events.)

@@ Line 480: / Line 480: @@
 Filters (except [filter_condition] which is for all sorts of events) can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
-These event triggers are all actions by units ('''moveto''', '''attack''') or things that happen to units ('''recruit''', '''advance'''). When one of these events is triggered, the position of the active unit (referred to as the '''primary unit''') is stored in the variables '''x1''' and '''y1''' and the position of any unit that primary unit does something to is stored in the variables '''x2''' and '''y2''' (this unit is referred to as the '''secondary unit''' below). '' These units are also automatically stored in the variables '''unit''' and '''second_unit''' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]. weapon and second_weapon variables are available inside attack, attacker_hits, defender_hits, die and last_breath events. See [[VariablesWML#Automatically_Stored_Variables|automatically stored variables]] for more information.
+These event triggers are all actions by units ('''moveto''', '''attack''') or things that happen to units ('''recruit''', '''advance'''). When one of these events is triggered, the position of the active unit (referred to as the '''primary unit''') is stored in the variables '''x1''' and '''y1''' and the position of any unit that primary unit does something to is stored in the variables '''x2''' and '''y2''' (this unit is referred to as the '''secondary unit''' below). '' These units are also automatically stored in the variables '''unit''' and '''second_unit''' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]. weapon and second_weapon variables are available inside attack, attacker_hits, defender_hits, unit_hits, die and last_breath events. See [[VariablesWML#Automatically_Stored_Variables|automatically stored variables]] for more information.
 === moveto ===
@@ Line 541: / Line 541: @@
 Same as ''defender hits'', but is triggered when the defender misses.
 === petrified ===

← Older revision		Revision as of 17:13, 24 March 2024
Line 464:		Line 464:

	It helps debugging if the victory event allows you to safely advance to any of the possible next maps after using the ":next_level" command. Scenarios where key units are picked up before the victory, or where some action chosen earlier determines which map to advance to, make it hard to quickly test scenarios in a campaign.		It helps debugging if the victory event allows you to safely advance to any of the possible next maps after using the ":next_level" command. Scenarios where key units are picked up before the victory, or where some action chosen earlier determines which map to advance to, make it hard to quickly test scenarios in a campaign.
−
−	~~Bug [https://github.com/wesnoth/wesnoth/issues/4667 #4667]: this event is treated as unsynchronized in replays, causing OOS reports when watching the replay.~~

	=== defeat ===		=== defeat ===

@@ Line 583: / Line 583: @@
 {{DevFeature1.13|0}} Triggers before the unit advancement dialog is shown. If this event removes the unit or reduces the unit's experience below what it needs to advance, then the advancement is aborted.
-Care needs to be taken when using tags that may trigger advancement themselves are used in this event. For example '''[transform_unit]''', '''[unstore_unit]''', '''[modify_unit]''' etc.
+Care needs to be taken when tags that may trigger advancement themselves are used in this event. For example '''[transform_unit]''', '''[unstore_unit]''', '''[modify_unit]''' etc.
 === post advance ===