EventWML/es

From The Battle for Wesnoth Wiki

[edit]WML Tags

A:

abilities, about, achievement, achievement_group, add_ai_behavior, advanced_preference, advancefrom, advancement, advances, affect_adjacent, ai, allied_with, allow_end_turn, allow_extra_recruit, allow_recruit, allow_undo, and, animate_unit, animation, aspect, attack (replay, weapon), attack_anim, attacks (special, stats), avoid;

B:

base_unit, background_layer, berserk, binary_path, break, brush;

C:

campaign, cancel_action, candidate_action, capture_village, case, chance_to_hit, change_theme, chat, checkbox, choice, choose, clear_global_variable, clear_menu_item, clear_variable, color_adjust, color_palette, color_range, command (action, replay), continue, core, credits_group, criteria;

D:

damage, damage_type, death, deaths, default, defend, defends, defense, delay, deprecated_message, destination, difficulty, disable, disallow_end_turn, disallow_extra_recruit, disallow_recruit, do, do_command, drains, draw_weapon_anim;

E:

editor_group, editor_music, editor_times, effect, else (action, animation), elseif, endlevel, end_turn (action, replay), enemy_of, engine, entry (credits, options), era, event, experimental_filter_ability, experimental_filter_ability_active, experimental_filter_specials, extra_anim;

F:

facet, facing, fake_unit, false, feedback, female, filter (concept, event), filter_adjacent, filter_adjacent_location, filter_attack, filter_attacker, filter_base_value, filter_condition, filter_defender, filter_enemy, filter_location, filter_opponent, filter_own, filter_owner, filter_radius, filter_recall, filter_second, filter_second_attack, filter_self, filter_side, filter_student, filter_vision, filter_weapon, filter_wml, find_path, fire_event, firststrike, floating_text, fonts, for, foreach, found_item, frame;

G:

game_config, get_global_variable, goal, gold, gold_carryover;

H:

harm_unit, has_ally, has_attack, has_unit, has_achievement, have_location, have_side, have_unit, heal_on_hit, heal_unit, healed_anim, healing_anim, heals, hide_help, hide_unit, hides;

I:

idle_anim, if (action, animation, intro), illuminates, image (intro, terrain), init_side, insert_tag, inspect, item, item_group;

J:

jamming_costs, join;

K:

kill, killed;

L:

label, language, leader, leader_goal, leadership, leading_anim, levelin_anim, levelout_anim, lift_fog, limit, literal, load_resource, locale, lock_view, lua;

M:

male, map_data, message, micro_ai, missile_frame, modification, modifications, modify_ai, modify_side, modify_turns, modify_unit, modify_unit_type, move, move_unit, move_unit_fake, move_units_fake, movement_anim, movement costs, movetype, multiplayer, multiplayer_side, music;

N:

not, note;

O:

object, objective, objectives, on_undo, open_help, option, options, or;

P:

part, petrifies, petrify, place_shroud, plague, poison, post_movement_anim, pre_movement_anim, primary_attack, primary_unit, print, progress_achievement, put_to_recall_list;

R:

race, random_placement, recall (action, replay), recalls, recruit, recruit_anim, recruiting_anim, recruits, redraw, regenerate, remove_event, remove_item, remove_object, remove_shroud, remove_sound_source, remove_time_area, remove_trait, remove_unit_overlay, repeat, replace_map, replace_schedule, replay, reset_fog, resistance (ability, unit), resistance_defaults, resolution, resource, return, role, rule;

S:

scenario, screen_fade, scroll, scroll_to, scroll_to_unit, secondary_attack, secondary_unit, section, select_unit, sequence, set_achievement, set_extra_recruit, set_global_variable, set_menu_item, set_recruit, set_specials, set_variable, set_variables, sheath_weapon_anim, show_if (message, objective, set_menu_item), show_objectives, side, skirmisher, slider, slow, sound, sound_source, source (replay, teleport), special_note, specials, split, stage, standing_anim, statistics, status, store_gold, store_items, store_locations, store_map_dimensions, store_reachable_locations, store_relative_direction, store_side, store_starting_location, store_time_of_day, store_turns, store_unit, store_unit_defense, store_unit_defense_on, store_unit_type, store_unit_type_ids, store_villages, story, swarm, sub_achievement, switch, sync_variable;

T:

target, team, teleport (ability, action), teleport_anim, terrain, terrain_defaults, terrain_graphics, terrain_mask, terrain_type, test, test_condition, test_do_attack_by_id, text_input, textdomain, theme, then, tile, time, time_area, topic, toplevel, trait, transform_unit, traveler, true, tunnel;

U:

unhide_unit, unit (action, scenario), unit_overlay, unit_type, unit_worth, units, unlock_view, unpetrify, unstore_unit, unsynced;

V:

value, variable, variables, variant, variation, victory_anim, village, vision_costs, volume;

W:

while, wml_message, wml_schema;

Z:

zoom;

Contents

La etiqueta [event]

Esta es una subetiqueta de las etiquetas [scenario], [unit_type] y [era] que se utiliza para describir un conjunto de acciones que se disparan en un momento determinado de un escenario. Cuando se usa en una etiqueta [scenario] (también incluye [multiplayer] y [test]), el evento solo ocurre en ese escenario. Cuando se usa en una etiqueta [unit_type], el evento ocurrirá en todos los escenarios en los que aparezca una unidad de ese tipo (solo después de que aparezca dicha unidad durante el escenario, sin embargo). Cuando se usa en una [era], el evento ocurrirá en cualquier escenario que se juegue usando esa era.

Esta etiqueta tiene claves y etiquetas hijas que controlan cuándo y si se dispararán las acciones del evento. La más importante de ellas es la clave name. Sin ella no se producirá un error, pero el evento nunca se disparará. Por lo tanto, desde un punto de vista práctico, se puede considerar obligatoria. Todas las demás pueden usarse o no y las acciones del evento se dispararán de cualquier manera.

Nota léxica: La palabra "event" en la propia etiqueta [event] puede considerarse una abreviatura del término "event handler" porque técnicamente no es un "evento" del juego sino un manejador de eventos para los eventos del juego disparados con el 'name' dado. Sin embargo, esta distinción suele ser poco importante en la mayoría de las discusiones y por eso los manejadores de eventos se denominan simplemente "eventos" en esta documentación.

La clave 'name' (Obligatoria)

Uso: 

name=<valor>

Esta clave define qué evento del juego o disparador manejará tu etiqueta [event]. Esta clave 'name' no debe confundirse con un comentario descriptivo; es más bien un valor preciso que debe coincidir con el nombre del evento predefinido del juego para ser válido.

La clave name puede aceptar una lista de valores separados por comas que describen cuándo se disparará el evento.* Estos valores pueden ser tipos de eventos predefinidos o nombres de eventos personalizados que no coincidan con ningún tipo predefinido.

Por ejemplo: 

name=attacker misses,defender misses

* Nota que a menos que uses first_time_only=no, el evento se disparará solo una vez, no una vez por cada tipo listado.

Todos los tipos de eventos predefinidos se enumeran más abajo, junto con una descripción de cuándo este valor hará que el evento se dispare, en las secciones Eventos predefinidos sin filtros y Eventos predefinidos con filtros. Cualquier valor no listado allí es un nombre de evento personalizado que solo puede dispararse mediante una etiqueta [fire_event] en algún otro lugar.

Los espacios en los nombres de eventos pueden intercambiarse con guiones bajos (por ejemplo, name=new turn y name=new_turn son equivalentes).

Variables en el name

Si el name contiene variables, estas se sustituirán cada vez que se dispare el evento. Por ejemplo, name=turn $disaster_turn solo se disparará si el número de turno es actualmente igual al número almacenado en la variable $disaster_turn; actualizar la variable ajustará el turno en el que se dispara el evento. Sin embargo, si el contenido de la variable contiene una coma, no se analizará después de la sustitución. Dado que un nombre de evento no puede contener una coma, esto significa que el evento nunca se disparará.

(Version 1.17.6 and later only)

Las comas resultantes de la sustitución de variables ahora se analizan. Si escribes name=$important_event y la variable $important_event contiene el texto "capture,die", el evento se disparará ya sea en una muerte o en una captura de aldea.

Eventos personalizados

Un evento con un nombre personalizado puede invocarse usando la etiqueta [fire_event]. Normalmente usarás estos eventos personalizados como subrutinas con nombre para ser llamadas por eventos con tipos predefinidos. Un caso común de esto, por ejemplo, es que más de un evento sighted pueda disparar el mismo evento personalizado que cambia los objetivos del escenario. Además, los eventos personalizados son muy útiles en Wml_optimisation.

Ejemplo: 

# Lo siguiente es la definición de un evento personalizado "unit recruited"
[event]
    name=unit_recruited
    first_time_only=no
    [message]
        speaker=unit
        message=_ "¡Presentándome para el servicio!"
    [/message]
[/event]

# Este es un evento recruit estándar que se dispara cada vez que una unidad es reclutada por el bando 1
[event]
    name=recruit
    first_time_only=no
    [filter]
    [/filter]
    [filter_second]
        side=1
    [/filter_second]

    # Y ahora se usa una etiqueta fire_event para disparar el evento definido anteriormente. Para usar
    # "speaker=unit" en el evento disparado, también es necesario especificar [primary_unit].
    [fire_event]
        name=unit_recruited
        [primary_unit]
            id=$unit.id
        [/primary_unit]
    [/fire_event]
 
    # Como resultado, cada vez que el bando 1 recluta una unidad, esta unidad dice "¡Presentándome para el servicio!"
[/event]

Puedes tener más código después del [fire_event], que se ejecutará después de que haya ocurrido el evento disparado. Ejemplo: 

# Este es un evento recall estándar que se dispara cada vez que una unidad es llamada por el bando 1
[event]
    name=recall
    first_time_only=no
    [filter]
    [/filter]
    [filter_second]
        side=1
    [/filter_second]

    # Dispara el evento personalizado, exactamente como en el evento recruit
    [fire_event]
        name=unit_recruited
        [primary_unit]
            id=$unit.id
        [/primary_unit]
    [/fire_event]
 
    # Después de que ocurra ese evento, se ejecuta el código restante en este evento
    [message]
        speaker=second_unit
        message=_ "Me alegra tenerte de vuelta"
    [/message]
    # Como resultado, cada vez que el bando 1 llama a una unidad, la unidad llamada dice
    # "¡Presentándome para el servicio!", y el líder responde "Me alegra tenerte de vuelta"
[/event]

Claves y etiquetas opcionales

Estas claves y etiquetas son formas más complejas de filtrar cuándo debe dispararse un evento:

first_time_only

Si el evento debe eliminarse del escenario después de dispararse. Esta clave toma un booleano; por ejemplo:
first_time_only=yes
Comportamiento predeterminado si se omite la clave. El evento se disparará la primera vez que pueda y nunca más.
first_time_only=no
El evento se disparará cada vez que se cumplan los criterios en lugar de solo la primera vez.

id

Si se especifica un id, el evento no se añadirá si ya existe otro evento con el mismo id. Un id también permitirá eliminar el evento, ver más abajo. Proporcionar un id= no vacío suele ser deseable para evitar duplicados en caso de que la misma [event] se use en múltiples [unit_type] o especiales de habilidad/arma.

remove

Elimina un evento en lugar de añadir uno nuevo. Esta clave toma un booleano; si es yes, hace lo mismo que una [remove_event] con el mismo valor id=, y se ignoran los demás atributos de esta etiqueta de evento.

(Version 1.13.0 and later only) Puede ser una lista separada por comas.

(Version 1.15.7 and later only) Imprime una advertencia de deprecación recomendando usar [remove_event] en su lugar.

priority

(Version 1.17.20 and later only) Si varias etiquetas '[event]' tienen el mismo name, entonces las que tengan un valor de prioridad alto se dispararán antes que los eventos con un valor de prioridad más bajo. También se admiten números negativos, para ejecutarse después de eventos sin prioridad (ya que el atributo por defecto es cero). Para eventos con igual prioridad, el orden se determina por el orden en que se añadieron los eventos.

[filter]

El evento solo se disparará si la primary unit coincide con este filtro.

[filter_second]

Como [filter], pero para la secondary unit.

[filter_attack]

Puede usarse para establecer criterios de filtrado adicionales basados en el arma usada por la primary unit. Es utilizable en los eventos attack, attacker hits, attacker misses, defender hits, defender misses, attack end, last breath y die. Para más información y claves de filtro, ver Filtrado de armas. Las claves más comúnmente usadas son las siguientes.
  • name: el nombre del arma usada.
  • range: el rango del arma usada.
  • special_id: filtro por el id del especial del arma del ataque.
  • special_type: filtro por el tipo del especial del arma del ataque.
  • (Version 1.17.15 and later only) special_id_active: filtro por el id del especial del arma del ataque activo (codificado en etiquetas [specials] o [abilities]).
  • (Version 1.17.15 and later only) special_type_active: filtro por el tipo del especial del arma del ataque activo (codificado en etiquetas [specials] o [abilities]).

[filter_second_attack]

Como [filter_attack], pero para el arma usada por la secondary unit.

[filter_condition]

Esta etiqueta tiene sentido dentro de cualquier tipo de evento, incluso aquellos que no tienen unidades o eventos personalizados. El evento solo se disparará si esta condición se evalúa como verdadera.
nota: Esta etiqueta está pensada para usarse cuando el disparo de un evento debe basarse en variables/condiciones que no pueden obtenerse de las unidades filtradas.

[filter_side]

El bando actual (normalmente el bando $side_number) debe coincidir con el StandardSideFilter pasado para que se dispare el evento.
nota: Esta etiqueta tiene más sentido en eventos side turn y turn refresh. Sin embargo, todos los eventos WML tienen un bando actual, por lo que también se podría impedir, por ejemplo, que se dispare un evento moveto si se pone una etiqueta [filter_side] allí y el bando de la unidad en movimiento no coincide.

[insert_tag]

Un [insert_tag] que se expande a cualquiera de las etiquetas de filtro anteriores hará que el filtro se cargue desde la variable cada vez que el juego compruebe si debe dispararse el evento. Esto puede hacer que el filtro del evento varíe de turno a turno.

filter_formula

(Version 1.17.6 and later only)
Similar a [filter_condition], pero la condición se expresa en Wesnoth Formula Language. La fórmula tiene acceso a las siguientes claves:
  • Información del evento:
    • event - el nombre del evento
    • event_id - el ID único del evento
    • event_data - información adicional específica del evento, como owner_side o damage_inflicted, o cualquier cosa pasada en [fire_event][data].
    • loc, unit - ubicación y unidad primaria del evento
    • second_loc, second_unit - ubicación y unidad secundaria del evento
    • weapon, second_weapon - arma primaria y secundaria
  • Información del estado del juego:
    • turn_number
    • time_of_day - el ID de la hora del día
    • side_number - bando actualmente activo
    • sides - una lista de todos los bandos
    • units - una lista de todas las unidades en el mapa
    • map - el mapa completo del juego como un arreglo bidimensional

delayed_variable_substitution

Esta clave solo es relevante dentro de un evento anidado y controla cuándo ocurrirá la sustitución de variables en esos casos especiales de acciones.

Acciones disparadas por [event]

Después de que se hayan cumplido las condiciones disparadoras, todas las etiquetas de acción dentro de la etiqueta [event] se ejecutan en el orden en que están escritas.

Hay 3 tipos principales de acciones:

Más detalles en ActionWML. Las acciones también pueden insertarse dinámicamente mediante [insert_tag].

Varias acciones utilizan **filtros estándar** para determinar sobre qué unidades ejecutar el comando. Estos se indican con las frases "standard unit filter" y "standard location filter".

Eventos anidados

Existe un tipo especial de acción: la creación de eventos. Al colocar una etiqueta [event] dentro de otra etiqueta [event], el evento anidado se genera (crea) cuando se encuentra el evento padre (el externo) (al ejecutar el contenido del evento padre). Una vez creado, no existe relación entre el evento anidado y el evento padre (por ejemplo, eliminar el evento padre no eliminaría el evento anidado).

(Ver ejemplos)

Sustitución retardada de variables

La sustitución de variables para un evento anidado puede ocurrir ya sea cuando es generado por el evento padre o cuando el propio evento anidado se dispara. Esto se controla con la clave delayed_variable_substitution que se utiliza en el evento anidado.

Si esta clave está establecida en yes, las variables en el evento anidado contendrán valores del turno en el que se disparó el evento anidado. Este es el comportamiento predeterminado si la clave se omite. Si se establece en no, las variables en el evento anidado se establecen en el momento en que se dispara el evento padre.

Este comportamiento puede ajustarse con precisión mediante una sintaxis especial al referenciar variables. En lugar de la sintaxis normal $variable, utiliza $|variable para que una variable contenga valores relevantes al turno en el que se disparó el evento anidado, incluso cuando delayed_variable_substitution está establecido en no. De esta forma puedes tener una mezcla de variables relevantes a los tiempos de disparo del evento padre y del evento anidado.

(Ver ejemplos)

Seguridad en multijugador

En multijugador solo es seguro utilizar WML que pueda requerir sincronización con otros jugadores debido a entrada de usuario o números aleatorios (como [message] con input u options o [unstore_unit] donde una unidad podría ascender) en los siguientes eventos. Esto se debe a que en estos casos el WML necesita datos de otros jugadores para funcionar correctamente y/o realizar lo mismo para todos los jugadores. Estos datos solo están disponibles después de una sincronización de red.

Lista de eventos sincronizados:

  • moveto
  • enter hex
  • exit hex
  • sighted
  • last breath
  • menu item X
  • die
  • capture
  • recruit
  • prerecruit
  • recall
  • prerecall
  • advance
  • pre advance
  • post advance
  • attack
  • attack end
  • attacker hits
  • attacker misses
  • defender hits
  • defender misses
  • unit hits
  • unit misses
  • start
  • prestart (prestart está sincronizado pero [message][option] y las elecciones de ascenso de [unstore_unit] tomarán una decisión aleatoria porque las cosas de interfaz no funcionan durante los eventos prestart.)
  • new turn
  • side turn
  • turn X
  • side X turn
  • side X turn Y
  • turn refresh
  • side turn end
  • side X turn end
  • side turn X end
  • side X turn Y end
  • turn end
  • turn X end
  • (Version 1.13.0 and later only) enemies defeated
  • (Version 1.13.0 and later only) time over
  • (Version 1.13.10 and later only) victory
  • (Version 1.13.10 and later only) defeat
  • (Version 1.13.0 and later only) scenario_end

Los siguientes no están sincronizados:

Si un evento no está listado aquí, consulta con alguien para estar seguro.

También existe la posibilidad de eventos que normalmente están sincronizados cuando los dispara el motor pero pueden no estar sincronizados cuando los dispara una etiqueta WML desde un evento no sincronizado. Por lo tanto, cuando los uses debes ser especialmente cuidadoso. Por ejemplo [unstore_unit] puede disparar un ascenso de unidad que a su vez disparará los eventos advance y post advance.

Una trampa para los incautos

Debes tener cuidado al usar macros para generar eventos. Si incluyes una macro que se expande a una definición de evento dos veces, el evento se ejecutará dos veces (no una) cada vez que se cumpla la condición disparadora. Considera este código: 

#define DOUBLE
    [event]
        name=multiply_by_2
        {VARIABLE_OP 2_becomes_4 multiply 2}
    [/event]
#enddef

{DOUBLE}
{DOUBLE}

{VARIABLE 2_becomes_4 2}
		
[fire_event]
    name=multiply_by_2
[/fire_event]
 
{DEBUG_MSG "$2_becomes_4 should be 4"}

Después de ejecutarse, el mensaje de depuración revelará que la variable se estableció en 8, no en 4.

IDs de eventos

Este problema puede evitarse estableciendo un id en el evento, es decir: 

#define DOUBLE
    [event]
        name=multiply_by_2
        id=doubler_event
        {VARIABLE_OP 2_becomes_4 multiply 2}
    [/event]
#enddef

Los eventos con el mismo ID solo serán aceptados una vez por el motor sin importar cuántas veces se incluyan, y solo se guardarán una vez en el archivo de guardado del escenario. Los eventos con un ID también pueden eliminarse usando la clave remove, es decir: 

[event]
    id=doubler_event
    remove=yes
[/event]

Después de que se encuentre ese WML (en el nivel superior o después de ser creado desde otro evento), el evento con ese ID se elimina del WML del escenario, por lo que dispararlo no tiene efecto. Después de que un evento es eliminado, aún puede volver a añadirse más tarde.

Eventos predefinidos sin filtros

Estos eventos no aceptan parámetros de filtro (excepto [filter_condition] que funciona para todos los eventos).

preload

Se dispara antes de que un escenario 'prestart' y al cargar una partida guardada — antes de que se muestre nada en pantalla. Puede usarse para configurar el entorno Lua: cargar bibliotecas, definir funciones auxiliares, etc.

Nota: Si una partida se inicia, se guarda y luego se recarga, el evento preload se disparará dos veces mientras se juega. Sin embargo, solo se disparará una vez al ver la repetición. Si el evento preload altera el estado del juego la segunda vez que se dispara mientras se juega (al cargar la partida guardada), puede resultar en errores Out Of Sync.

Nota: A diferencia de prestart y start, el evento preload ¡debe poder dispararse más de una vez! Esto se debe a que se dispara cada vez que se carga una partida guardada además de la vez inicial cuando carga antes del 'prestart' del escenario. Esto significa que es efectivamente obligatorio tener la clave first_time_only=no en un evento preload.

prestart

Se dispara antes de que un escenario 'comience' — antes de que se muestre nada en pantalla. Puede usarse para configurar cosas como la propiedad de aldeas. Para cosas que se muestran en pantalla como diálogos de personajes, usa start en su lugar.

Nota: Este valor hace que la clave first_time_only sea irrelevante ya que, por definición, solo puede dispararse una vez.

start

Se dispara después de que se muestra el mapa pero antes de que comience el escenario — antes de que los jugadores puedan «hacer» nada.

Nota: Este valor hace que la clave first_time_only sea irrelevante ya que, por definición, solo puede dispararse una vez.

new turn

Se dispara al inicio de cada turno (no turno de bando). Ver también first_time_only=no. Antes de que se disparen eventos de este tipo, el valor de la variable WML turn_number se establece al número del turno que está comenzando.

turn end

Se dispara al final de cada turno (no turno de bando). Ver también first_time_only=no. La variable WML side_number contendrá el bando que terminó su turno.

turn X end

Se dispara al final del turno X.

side turn

Se dispara cuando un bando está a punto de comenzar su turno. Antes de que se disparen eventos de este tipo, el valor de la variable WML side_number se establece al número del bando del jugador que está a punto de jugar su turno. Esto ocurre antes de cualquier curación para ese bando, antes de calcular ingresos y antes de restaurar el movimiento y estado de las unidades.

ai turn

Se dispara justo antes de que se invoque la IA para un bando. Se llama después de side turn, por lo que la variable WML side_number aún contiene el número de este bando. Ten en cuenta que este evento podría llamarse varias veces por turno en caso de que haya retrocesos a humano o droiding involucrados. Es decir, ocurre en medio del turno del bando humano 1 si el jugador humano pone en droid su bando. Ocurre después de la selección de IA para jugar el turno pero antes de que se le indique a la IA que ha llegado un nuevo turno.

Nota: Este evento puede romper las repeticiones si se usa de forma incorrecta. El evento ai turn no se dispara durante las repeticiones. La intención es solo guiar a la IA para que tome decisiones (movimientos, ataques) que luego se guardan en la repetición.

turn refresh

Similar a side turn, se dispara justo antes de que un bando tome el control pero después de la curación, cálculo de ingresos y restauración del movimiento y estado de las unidades. La variable WML side_number contiene el número de este bando.

Ten en cuenta que el evento turn refresh ocurre en el turno 1, aunque la curación (para el bando 1), ingresos y refresco de unidades no ocurran.

turn X

Se dispara al inicio del turno X. Es el primer evento de inicialización de bando.

Los eventos de inicialización de bando ocurren en el siguiente orden:

  1. turn X
  2. new turn
  3. side turn
  4. side X turn
  5. side turn X
  6. side X turn Y
  7. turn refresh
  8. side X turn refresh
  9. turn X refresh
  10. side X turn Y refresh

side X turn Y

Este evento se dispara al inicio del turno Y del bando X

side X turn

Este evento se dispara al inicio de cualquier turno del bando X

Nota: Por supuesto, se necesita first_time_only=no para que este evento se dispare más de una vez.

side turn X

Este evento se dispara al inicio de cualquier bando en el turno X

Nota: Por supuesto, se necesita first_time_only=no para que este evento se dispare más de una vez.

side X turn Y refresh

Este evento se dispara en el refresco de turno para el bando X en el turno Y

side X turn refresh

Este evento se dispara en el refresco de turno para el bando X

Nota: Por supuesto, se necesita first_time_only=no para que este evento se dispare más de una vez.

turn X refresh

Este evento se dispara para cualquier bando en el refresco del turno X.

Nota: Por supuesto, se necesita first_time_only=no para que este evento se dispare más de una vez.

side turn end

Se dispara después de que un bando termina su turno. Al igual que side turn, también hay variaciones para combinaciones específicas de número de bando y número de turno. Este es el orden en que se disparan los eventos de fin de turno:

  1. side turn end
  2. side X turn end
  3. side turn X end
  4. side X turn Y end
  5. turn end
  6. turn X end

time over

Se dispara en el turno turns. (turns se especifica en [scenario])

enemies defeated

Se dispara cuando todos los bandos que no están derrotados son aliados y hay al menos un bando humano (o humano en red) entre ellos. Especialmente este evento se dispara en una situación que normalmente causaría una victoria por enemigos derrotados (independientemente de si se desactivó con victory_when_enemies_defeated=no).

local_victory

En Wesnoth 1.12 y anteriores, el evento descrito aquí es victory, (Version 1.13.10 and later only) en 1.14 el evento descrito aquí es local_victory.

Este evento se disparará al final de un escenario, si el bando del jugador ganó. Si se dispara como resultado de una etiqueta [endlevel], el evento se procesa antes de la línea posterior a la etiqueta [endlevel]. El evento no está sincronizado, ya que en multijugador en red es posible tener resultados diferentes para diferentes jugadores.

local_defeat

En Wesnoth 1.12 y anteriores, el evento descrito aquí es defeat, (Version 1.13.10 and later only) en 1.14 el evento descrito aquí es local_defeat.

Funciona idénticamente a local_victory, excepto que el bando del jugador perdió.

victory

Esta sección describe un evento nuevo de Wesnoth 1.14. En 1.12 y anteriores, el evento victory es equivalente al local_victory de 1.14.

Este evento se disparará al final de un escenario, si el juego procede al siguiente escenario. En multijugador, esto significa que se disparará en los clientes de todos los jugadores, incluso para jugadores que recibieron un local_defeat, siempre que el juego continúe al siguiente escenario. Este evento está sincronizado.

Ayuda en la depuración si el evento victory permite avanzar de forma segura a cualquiera de los posibles siguientes mapas después de usar el comando ":next_level". Los escenarios donde se recogen unidades clave antes de la victoria, o donde alguna acción elegida antes determina a qué mapa avanzar, dificultan probar rápidamente escenarios en una campaña.

defeat

Esta sección describe un evento nuevo de Wesnoth 1.14. En 1.12 y anteriores, el evento defeat es equivalente al local_defeat de 1.14.

Este evento se disparará al final de un escenario, si el juego resulta en un fin de partida que no sea alcanzar victoriosamente el final de una campaña (incluyendo campañas de un solo escenario). La sincronización (incluyendo el bug #4667) es la misma que en victory.

scenario_end

(Version 1.13.10 and later only) Este evento se dispara inmediatamente después de victory o defeat; está sincronizado, pero también se ve afectado por el bug #4667.

Nota: en las versiones 1.13.0 - 1.13.9 este evento se añadió como alternativa sincronizada a los eventos que, desde la 1.13.10, se llaman local_victory o local_defeat.

Eventos predefinidos con filtros

Los filtros (excepto [filter_condition] que sirve para todo tipo de eventos) pueden aplicarse a los siguientes disparadores de eventos (ver FilterWML; ver también más abajo). Las acciones especificadas en la etiqueta del evento solo se ejecutarán si el filtro devuelve verdadero. Estos disparadores de eventos son todos acciones de unidades (moveto, attack) o cosas que les ocurren a las unidades (recruit, advance). Cuando uno de estos eventos se dispara, la posición de la unidad activa (denominada primary unit) se almacena en las variables x1 y y1, y la posición de cualquier unidad sobre la que actúa la primary unit se almacena en las variables x2 y y2 (esta unidad se denomina secondary unit más adelante). Estas unidades también se almacenan automáticamente en las variables unit y second_unit como si hubieran sido almacenadas mediante la etiqueta [store_unit]. Ver SingleUnitWML. Las variables weapon y second_weapon están disponibles dentro de los eventos attack, attacker_hits, defender_hits, unit_hits, die y last_breath. Ver variables almacenadas automáticamente para más información.

moveto

Se dispara después de que la primary unit se mueve. Normalmente se usa cuando la primary unit llega a una ubicación concreta y se incluye un filtro para la ubicación de la primary unit; recuerda que esta es la ubicación en la que la primary unit termina, no la ubicación desde la que partió ni ninguna por la que haya pasado. Si la unidad se mueve a una aldea, el evento capture se disparará antes que este evento.
Una etiqueta [allow_undo] en cualquier lugar dentro de un evento moveto cancelará cualquier pérdida de funcionalidad de deshacer que el evento habría causado. Ten en cuenta que la funcionalidad de deshacer solo devolverá la unidad a su ubicación anterior; no deshacerá otros cambios en el juego causados por el evento. Por lo tanto, depende del diseñador del escenario usar esta etiqueta correctamente. $x2 y $y2 se refieren al hex desde el que vino la unidad.

sighted

Un evento sighted se dispara cuando una unidad se vuelve visible para un bando (distinto del bando propio de la unidad). Esto es especialmente útil cuando el bando que ve la unidad usa fog of war o shroud, pero se disparan incluso cuando no se usa niebla/velo, y sí tienen en cuenta la habilidad [hides] (para una unidad en movimiento y para emboscadores). La primary unit es la unidad que se volvió visible, y la secondary unit pertenece al bando que ahora ve a la primary unit. En algunos casos, los eventos sighted pueden retrasarse respecto al momento en que "deberían" ocurrir. Si eso sucede, la secondary unit se filtrará como si estuviera en la ubicación donde el evento "debería" haber ocurrido, y x2,y2 almacenarán esa ubicación (no la posición actual de la secondary unit). Para entender cuándo se disparan los eventos sighted, es útil distinguir los momentos en que la unidad actuante ve a otras unidades de los momentos en que la unidad actuante es vista.

Una unidad actuante puede ver a otras unidades cuando es reclutada, llamada, sube de nivel o se mueve, y cuando se despeja niebla o velo de hexes ocupados como resultado. En estos casos, la unidad actuante es siempre la secondary unit. Para las primeras tres acciones hay dos eventos asociados a la acción; el despeje ocurre entre estos eventos, pero cualquier evento sighted se dispara después del segundo evento. (Por ejemplo, cuando se recluta una unidad, se dispara el evento prerecruit, luego se despeja la niebla, luego se dispara el evento recruit, y después se disparan los eventos sighted.) Para el movimiento, los eventos sighted se disparan entre los eventos enter_hex y exit_hex, pero a veces se posponen hasta que la unidad en movimiento llega a un buen lugar para detenerse (por ejemplo, no en un hex ocupado). Como excepción importante, los jugadores tienen la opción de retrasar las actualizaciones de velo (y niebla). Si el jugador retrasa las actualizaciones de velo, los eventos sighted también se retrasan hasta que se actualice el velo.

Una unidad actuante puede ser vista por otros bandos cuando es reclutada, llamada, sube de nivel (en casos raros) o se mueve. En estos casos, la unidad actuante es siempre la primary unit. Estos eventos se disparan después de las detecciones realizadas por la unidad actuante (a menos que el jugador haya retrasado las actualizaciones de velo). Para las primeras dos, el evento sighted se dispara para todos los bandos que pueden ver la unidad, excepto el bando propio de la unidad (incluso si esos bandos no usan ni niebla ni velo). Para unidades que suben de nivel, se excluyen los bandos que podían ver la unidad antes de subir de nivel. (Por eso estos eventos son raros — la unidad que sube de nivel debe haber perdido una habilidad [hides] como resultado de subir de nivel para ser vista después, pero no antes.) Para el movimiento, se dispara un evento sighted por cada bando que podía ver la unidad después del movimiento, pero no antes. En particular, solo se consideran el hex inicial y el final; una unidad que pasa por hexes vistos pero termina el movimiento en un hex con niebla no dispara un evento sighted para sí misma. En todos los casos en que la unidad actuante es vista, se elige una (única) secondary unit del equipo que la detecta. Esta elección debe considerarse arbitraria, pero se prefieren las unidades dentro de su rango de visión de la unidad actuante a las que están más lejos. Puedes querer usar [filter_second] para restringir un evento sighted en un escenario de un solo jugador a que solo sea disparado por el jugador y no por otros bandos no aliados.

Los eventos sighted no se disparan por una habilidad hides que deja de estar activa, a menos que deje de estar activa debido al movimiento de esa unidad o a que esa unidad embosque a otra. (Para detectar una habilidad nightstalk que deja de estar activa por la hora del día, usa un evento new_turn. Las habilidades hides personalizadas podrían necesitar un manejo similar.)

Los eventos sighted tienen algunas advertencias especiales para autores de WML. En primer lugar, [allow_undo] debería evitarse generalmente en eventos sighted. Puede usarse si las posiciones actuales de las unidades no tienen relación con el evento, pero de lo contrario podría causar que una repetición se desincronice si un jugador retrasa las actualizaciones de velo y deshace un movimiento. Esto no debería ser una restricción muy gravosa, ya que despejar la niebla bloqueará la capacidad de deshacer, independientemente de lo que ocurra dentro de un evento. En segundo lugar, actualmente es posible que el WML elimine una unidad involucrada en un evento sighted antes de que ese evento se dispare. Si eso ocurre, los filtros sobre la unidad eliminada no coincidirán con nada y el evento puede parecer que no se disparó.

enter_hex

Se dispara por cada hex que se entra durante el movimiento, con $x1,$y1 identificando el hex entrado y $x2,$y2 identificando el hex anterior (recién salido). En Wesnoth 1.12, el movimiento se interrumpirá, deteniendo la unidad donde está; este comportamiento puede evitarse usando la etiqueta [allow_undo] o la macro `NO_INTERRUPT_NO_UNDO`. (Version 1.13.11 and later only) el movimiento no se interrumpe a menos que se use la etiqueta [cancel_action].

Nota: Este evento se comporta de forma algo inusual si el hex está ocupado (y la unidad en movimiento solo está pasando por él). Cuando esto ocurre, $x1,$y1 sigue siendo el hex donde se disparó el evento, pero la unidad en movimiento (almacenada en $unit) estará ubicada en algún punto anterior de la ruta (el hex desocupado más reciente). Es decir, $x1,$y1 no será igual a $unit.x,$unit.y (una condición que puede usarse para detectar cuando el hex entrado está ocupado). La unidad en movimiento ya habrá gastado sus puntos de movimiento para entrar en el hex del evento aunque no se haya movido realmente desde el hex desocupado más reciente.

Nota: En el momento de escribir (7ca5a0df, justo antes de 1.13.11), si el hex está ocupado entonces $unit contiene la unidad ocupante, no la unidad en movimiento.

Nota: En el momento de escribir (1.16.2), si el hex está ocupado entonces $unit sí contiene la unidad en movimiento.

exit_hex

Se dispara por cada hex que se sale durante el movimiento, con $x1,$y1 identificando el hex salido y $x2,$y2 identificando el siguiente hex (a entrar). Si este evento se maneja sin usar [allow_undo], entonces el movimiento se interrumpe, deteniendo la unidad donde está. (Version 1.13.11 and later only) el movimiento no se interrumpe a menos que se use la etiqueta [cancel_action].

Nota: Este evento se comporta de forma algo inusual si el hex está ocupado (y la unidad en movimiento solo está pasando por él). Cuando esto ocurre, $x1,$y1 sigue siendo el hex donde se disparó el evento, pero la unidad en movimiento (almacenada en $unit) estará ubicada en algún punto anterior de la ruta (el hex desocupado más reciente). Es decir, $x1,$y1 no será igual a $unit.x,$unit.y (una condición que puede usarse para detectar cuando el hex salido está ocupado). La unidad en movimiento ya habrá gastado sus puntos de movimiento para entrar en el hex del evento aunque no se haya movido realmente desde el hex desocupado más reciente.

pre attack (Version 1.17.7 and later only)

Similar a attack, pero se dispara antes de calcular el número de ataques y el movimiento de la unidad. Puede usarse para modificaciones que afecten estos valores.

attack

Se dispara cuando la primary unit ataca a la secondary unit. Las variables $weapon y $second_weapon contienen las armas usadas en este ataque por las unidades primary y secondary respectivamente para todos los eventos relacionados con ataques (attack_end, attacker_hits, attacker_misses, defender_hits, defender_misses, die y last_breath).

attack end

Similar a attack, pero se dispara después del combate en lugar de antes. Ten en cuenta que si alguna de las unidades muere durante el combate, este evento se dispara antes que cualquier evento die.

attacker hits

Se dispara cuando la primary unit (el atacante) golpea a la secondary unit (el defensor). El valor de la variable WML damage_inflicted se establece en el número de puntos de vida infligidos por el atacante.

attacker misses

Igual que attacker hits, pero se dispara cuando el atacante falla.

defender hits

Se dispara cuando la primary unit (el atacante) es golpeada en represalia por la secondary unit (el defensor). El valor de la variable WML damage_inflicted se establece en el número de puntos de vida infligidos por el defensor.

defender misses

Igual que defender hits, pero se dispara cuando el defensor falla.

unit hits (Version 1.19.2 and later only)

Se dispara cuando la primary unit (ya sea atacante o defensor) golpea a la secondary unit (la otra). El valor de la variable WML damage_inflicted se establece en el número de puntos de vida infligidos por la primary unit.

En comparación con defender hits, las unidades primary y secondary están intercambiadas.

unit misses (Version 1.19.2 and later only)

Igual que unit hits, pero se dispara cuando la unidad falla.

petrified

Se dispara cuando la primary unit es golpeada por un ataque con la habilidad 'petrifies' (ver petrifies, AbilitiesWML) por la secondary unit (la unidad con la habilidad 'petrifies').

last breath

Se dispara cuando la primary unit es asesinada por la secondary unit, pero antes de que se active la animación de muerte. Úsalo en lugar de name=die cuando quieras que la primary unit pronuncie un [message] final.

die

Se dispara cuando la primary unit es asesinada por la secondary unit. Nota: La primary unit no se elimina del juego hasta el final de este evento. La primary unit aún puede ser manipulada, bloqueará a otras unidades para que tomen su hex y seguirá siendo encontrada por filtros estándar de unidades (excepto [have_unit]). Para evitar este comportamiento, puedes usar [kill] para eliminar la unidad inmediatamente. Sin embargo, esto detendrá cualquier otro evento (aún no disparado) que también coincida con la unidad para que no se dispare después, así que úsalo con precaución. Si quieres que la primary unit pronuncie un [message] final, usa name=last_breath, ver arriba.

capture

Se dispara cuando la primary unit captura una aldea. La aldea puede haber sido previamente neutral o pertenecido a otro bando; simplemente moverse a tus propias aldeas no constituye una captura. Este evento se disparará antes del evento moveto. Las aldeas que se vuelven neutrales (mediante [capture_village]) no disparan eventos capture. La variable $owner_side contiene el bando anterior propietario de la aldea. 0 significa neutral.

recruit

Se dispara cuando la primary unit es reclutada (por la secondary unit). (Es decir, cuando se recluta una unidad, disparará este evento y el filtro de este evento filtrará esa unidad).

prerecruit

Se dispara cuando la primary unit es reclutada (por la secondary unit) pero antes de que se muestre.

recall

Se dispara después de que la primary unit es llamada (por la secondary unit).

prerecall

Se dispara cuando la primary unit es llamada (por la secondary unit) pero antes de que se muestre.

advance

Se dispara justo antes de que la primary unit vaya a ascender a otra unidad o ascender por AMLA. (Esto es después de que el jugador seleccione qué avance, si hay elección). Si este evento elimina la unidad, cambia el tipo de la unidad o reduce la experiencia de la unidad por debajo de lo necesario para ascender, entonces el ascenso se cancela. Esto también aplica al ascenso por AMLA.

pre advance

(Version 1.13.0 and later only) Se dispara antes de que se muestre el diálogo de ascenso de unidad. Si este evento elimina la unidad o reduce la experiencia de la unidad por debajo de lo necesario para ascender, entonces el ascenso se cancela.

Hay que tener cuidado cuando se usan etiquetas que pueden disparar ascensos por sí mismas en este evento. Por ejemplo [transform_unit], [unstore_unit], [modify_unit], etc.

post advance

Se dispara justo después de que la primary unit ha ascendido a otra unidad o ascendido por AMLA.

select

Se dispara cuando la primary unit es seleccionada. Antes de la versión 1.11, también se disparaba cuando se interrumpía un movimiento, ya que el juego mantiene la unidad en movimiento seleccionada al seleccionarla de nuevo al final del movimiento. Nota: en multijugador en red, estos eventos solo se ejecutan en el cliente en el que se dispara el evento, lo que lleva a errores de desincronización si modificas el estado del juego en el evento.

menu item X

Se dispara cuando se selecciona un elemento de menú WML con id=X. Nota: si el elemento de menú tiene un [command], este evento puede ejecutarse antes o después del comando; no hay garantía.

unit placed (Version 1.13.3 and later only)

Se dispara cuando la primary unit es colocada en el mapa, independientemente del método. Esto incluye, pero no se limita a:

  • Líderes y unidades colocadas en definiciones de bando (se dispara una vez por cada unidad justo antes de los eventos prestart)
  • Unidades reclutadas y llamadas
  • Unidades colocadas en el mapa con la etiqueta [unit] (no unidades creadas directamente en una lista de llamada o variable)
  • Unidades colocadas por la función Lua wesnoth.put_unit()
  • Unidades colocadas por :to_map en Lua (que es un atajo para lo anterior)
  • Unidades creadas mediante el modo depuración
  • Unidades creadas por plagua
  • Cada uso de [unstore_unit], cuando fire_event está establecido en yes (el valor predeterminado es no)
  • Unidades movidas en el mapa con [move_unit] antes de (Version 1.15.8 and later only)
  • Unidades que coinciden con el filtro de [petrify], [unpetrify] o [harm_unit] antes de (Version 1.15.8 and later only)
  • Unidades que reciben un bono de la habilidad feeding cada vez excepto la primera, antes de (Version 1.15.8 and later only)

Este evento está destinado únicamente a casos especiales donde ningún otro tipo de evento es suficiente, por ejemplo si debes aplicar inmediatamente una modificación a cada unidad que aparezca. El evento no lleva registro de para qué unidades ya se ha disparado anteriormente, pero puede dispararse un número ilimitado de veces para la misma unidad siempre que la unidad sea "colocada" varias veces y el filtro del evento no lo impida.

Notas y ejemplos varios

Ejemplo de hablante de unidad primary/secondary

En los eventos, la primary unit puede referenciarse como unit y la secondary unit como second_unit en etiquetas [message] usando la clave speaker. Por ejemplo: 

[event]
    name=last breath
    [message]
        speaker=second_unit
        message= _ "¡Jajaja! ¡Por fin te maté!"
    [/message]

    [message]
        speaker=unit
        message= _ "¡Todavía no ha terminado! ¡Volveré a atormentarte!"
    [/message]
[/event]

Ejemplo de evento anidado

Se crea un evento para un portal que se abre en el turno 10. El evento padre (o «externo») se ejecuta en el turno 10, momento en el que se crea el evento moveto anidado. Este evento anidado se ejecuta cuando un jugador pisa un punto concreto. 

[event]
    name=turn 10
 
    [event]
        name=moveto
        [filter]
            x,y=5,8
        [/filter]
 
        # moverse a 5,8 disparará este evento solo en el turno 10 y posteriores
    [/event]
[/event]

Una forma equivalente de hacer esto sería crear un único evento moveto con una declaración [filter_condition] para comprobar el número de turno, pero usar etiquetas [event] anidadas es un atajo conveniente para lograr esta tarea sin recurrir a declaraciones [filter_condition]. Usar etiquetas [if] también es una opción, especialmente si tu evento tiene first_time_only=yes.

Ejemplo de sustitución retardada de variables

Este código mostrará un mensaje indicando el número de turno en el que ocurre el evento moveto anidado. 

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=yes
        [filter]
            x,y=5,8
        [/filter]

        {DEBUG_MSG "Turno $turn_number"} 
    [/event]
[/event]

Dado que este es el comportamiento predeterminado de la clave delayed_variable_substitution, el siguiente ejemplo es idéntico. 

[event]
    name=turn 10

    [event]
        name=moveto
        [filter]
            x,y=5,8
        [/filter]

        {DEBUG_MSG "Turno $turn_number"} 
    [/event]
[/event]

El siguiente código siempre mostrará "Turno 10" cuando ocurra el evento moveto anidado. Esto se debe a que la sustitución de variables se realiza cuando se dispara el evento padre y genera el evento anidado, no cuando se dispara el evento anidado. 

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=no
        [filter]
            x,y=5,8
        [/filter]

        {DEBUG_MSG "Turno $turn_number"} 
    [/event]
[/event]

Finalmente, el siguiente ejemplo es idéntico a los dos primeros en que mostrará un mensaje indicando el número de turno en el que ocurre el evento moveto anidado, a pesar de que la clave delayed_variable_substitution está establecida en no. Esto se debe a que se usa la sintaxis especial $|variable. 

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=no
        [filter]
            x,y=5,8
        [/filter]

        {DEBUG_MSG "Turno $|turn_number"} 
    [/event]
[/event]

Múltiples eventos anidados

Cada delayed_variable_substitution=no provoca una ejecución de sustitución de variables en el subevento donde ocurre en el momento de generación de este evento y en todos los subeventos siguientes. Para cualquier evento específico, la sustitución de variables ocurre al menos una vez cuando el evento se ejecuta. Por cada clave delayed=no que aparezca en sí mismo o en un evento de una "generación" más antigua (que no sea el evento de nivel superior), se realiza una ejecución adicional de sustitución de variables. 

[event] # padre
    name=turn 2
    # delayed_variable_substitution=no # En el evento padre, delayed= no tiene efecto.
 
    [event] # hijo
        name=turn 3
        delayed_variable_substitution=no # Provoca sustitución de variables en el hijo, nieto y bisnieto
        # en el momento de ejecución del evento padre = momento de generación del evento hijo.

        [event]# nieto
            name=turn 4
            delayed_variable_substitution=yes # sin sustitución de variables en el nieto y bisnieto
            # en el momento de ejecución del evento hijo = momento de generación del evento nieto

            [event] # bisnieto
                name=turn 5
                {DEBUG_MSG $turn_number} # salida: 2 - valor de la sustitución en el momento de ejecución del padre,
                # causada por delayed=no en el evento hijo

                {DEBUG_MSG $||turn_number}# salida: "$turn_number"
                # Cada sustitución transforma un "$|" en "$" (excepto cuando no queda |).

                {DEBUG_MSG $|turn_number}# salida: 5 - de la sustitución en el momento de ejecución
                # del evento bisnieto
            [/event]
        [/event]
    [/event]
[/event]

Véase también

Retrieved from "https://wiki.wesnoth.org/index.php?title=EventWML/es&oldid=74830"
This page was last edited on 15 February 2026, at 15:25.