Notas del parche 4.13.0 del RPP de StarCraft II

ACTUALIZACIÓN DEL EDITOR

¡Nos complace anunciar una gran actualización para el editor de mapas de StarCraft II!

Desde Wings of Liberty, hay algo que nos venís pidiendo con insistencia: el editor debería ser más fácil de usar. Con este parche queremos dar respuesta a esa petición, aunque sin perder profundidad de personalización. Por eso, hemos adoptado algunos elementos del editor de Warcraft III diseñados con este fin sin sacrificar las capacidades que ofrece ahora mismo el editor de StarCraft II; de hecho, las hemos ampliado aún más.

Queremos animar a todos los creadores de mapas y de mods a entrar en el nuevo editor, probarlo y contarnos qué les parece porque, como siempre, la idea es seguir añadiéndole más opciones interesantes en el futuro. Esta es la mayor actualización del editor que hayamos hecho nunca, y estamos deseando saber qué os parece. Más abajo podéis encontrar un resumen de algunas de sus características más interesantes.

Antes de nada: no os olvidéis de hacer copias de seguridad de vuestros mapas antes de probarlos en el RPP, dado que este es experimental.

Colecciones de datos

• Una colección de datos es un nuevo tipo de catálogo que permite al usuario declarar y agrupar una serie de elementos de datos. Se puede ver como cualquier otro elemento de datos individual, como una unidad, una habilidad o una mejora.
• Al copiar, cambiar de nombre o borrar una colección de datos, el editor aplicará la misma acción a todos los elementos que la forman. Por ejemplo, si copiamos una colección de datos, el editor nos pedirá que le pongamos nombre a la nueva colección, duplicará cualquier entrada de datos que contenga y le pondrá el nombre correspondiente. Además, organizará todos los campos vinculados de manera que las nuevas entradas de datos apunten a sus nuevos equivalentes.

  

• Ejemplo: copiamos la colección Blizzard y le ponemos a la nueva el nombre «Activision Blizzard».
• Al borrar una colección de datos, se eliminan todas las entradas de datos que incluye.
• Al cambiar la ID de una colección de datos, ocurre lo mismo: se cambia la ID todas las entradas de datos que incluye.
• Las entradas de datos que conforman una colección se pueden incluir de forma manual o automática.
• Las colecciones de datos utilizan un nuevo carácter clave («@») para nombrar las entradas de datos asociadas. El sistema de colecciones de datos puede buscar automáticamente en todo el catálogo cualquier entrada de datos cuya ID comience por la de la colección, seguida por el carácter «@». Hecho esto, las incluirá automáticamente en la colección.
• Debido a esta vinculación, cada vez que se cambia el árbol de efectos de una habilidad, se actualizan automáticamente tanto la colección de datos correspondiente como las entradas de datos que la forman.
• A continuación podéis ver una muestra de los datos de una colección que se ha poblado de forma automática:

  

  • Aunque los datos que no sigan esta convención en el nombre no se incluirán automáticamente en una colección, pueden añadirse a ella de forma manual.
• La opción Menu: Data Collection -> Auto Fill Data Collection (Menú: Colección de datos -> Rellenar colección de datos automáticamente) buscará automáticamente en todo el catálogo cualquier entrada de datos cuya ID comience por la de la colección, seguida por el carácter «@». Hecho esto, las incluirá automáticamente en la colección.
• La opción Menu: Data Collection -> Auto Name Data Collection (Menú: Colección de datos -> Nombrar colección de datos automáticamente) cambiará los nombres de las entradas de datos de la colección basándose en el nombre de la colección de datos.
• Las colecciones de datos también nos permiten añadir información extra sobre las relaciones entre las entradas de datos. Por ejemplo, con las colecciones de datos, ahora el juego puede comprender una pregunta como «¿Cuál es el principal actor de esta unidad?».
• La actualización incluye muchas otras funciones que dependen de estas colecciones de datos.
• Para aprovechar todo el potencial de las colecciones de datos, hay que utilizar ciertas convenciones o pautas de codificación:
  • Las colecciones de datos deben ser tan autosuficientes como sea posible.
  • Por ejemplo, una «colección de habilidades» debería funcionar siempre que se añada a una unidad, y las habilidades no deben estar programadas de tal modo que solo funcionen en unidades concretas o unidades con armas concretas. A modo de ejemplo de advertencia, en la antigua base de datos de SC2 había una pasiva para el rayo de vacío que aumentaba el daño tras atacar durante mucho tiempo. En realidad, se trataba de una pasiva falsa, y la funcionalidad estaba programada directamente en el arma del rayo de vacío. Ahora, con las colecciones de datos, es una práctica que desaconsejamos. De hecho, muchas de las nuevas funciones que se describen más abajo se han creado con este fin.

Editor de datos en «modo fácil»

• El editor de datos en «modo fácil» es una función ampliada de las colecciones de datos. Si se activa, el editor de datos mostrará solo las colecciones de datos y las agrupará como si fueran muestras únicas de «dato de habilidad», «dato de unidad», «dato de objeto», «dato de mejora», etc. Estos datos se pueden copiar, eliminar, borrar o renombrar como si fueran elementos de datos únicos.
• Este modo únicamente está disponible en una vista de tabla y combina los campos de datos más importantes, como los Unit HP (salud de unidad) o Ability Damage (daño de habilidad).
• Los campos que aparecen en el modo fácil se pueden personalizar por completo para cada tipo de colección de datos.
• Una de las principales quejas que tenía la mayoría de los creadores de mapas sobre el editor de SC2 era que resultaba demasiado complicado duplicar unidades o habilidades. De hecho, esta es la principal ventaja del editor de Warcraft III con respecto al de SC2.
  • Nuestra respuesta consiste en combinar el modo fácil y las colecciones de datos.
  • En el futuro, nuestra intención es crear más datos basados en las colecciones para que los jugadores puedan interactuar con ellos con más facilidad.
• Queremos animar a los jugadores a crear sus propios mods con colecciones de datos para sacarles todo el partido. Además, los invitamos a definir las vistas para el modo fácil de manera que a otros creadores les resulte más fácil modificar sus mods.

Acumuladores

• Los acumuladores son una nueva característica que permite crear fórmulas para mapas basadas en diferentes parámetros de entrada.
• Los acumuladores pueden utilizar valores personalizados de unidades y datos de usuario como parámetros.
• Los acumuladores no solo son compatibles con fórmulas, sino también con tablas definidas por el usuario. Si se combinan con validadores, también permiten utilizar funciones de cambio de caso.
• Por ejemplo, cuando se usa un acumulador en un comportamiento que tiene niveles variables y puede ser utilizado por varios jugadores, el acumulador calcula el resultado para cada jugador.
• Los acumuladores son muy versátiles y se pueden usar en muchos sitios. Ejemplos: daño, ritmo de sanación, regeneración de vida, reducción de daño, coste de habilidad, bonificación de armadura, número de lotes del actor, número de persistencia, número de comportamientos, duración del comportamiento, fracción de daño, velocidad de ataque, velocidad de movimiento, regeneración vital, probabilidad del comportamiento, modificación vital, etc.
• Nueva variable de análisis de cadenas: $AccumulatedValue:xxx$
  • Esta variable se puede usar para calcular AccumulatedValue en la IU. Por ejemplo:
    • Esta variable se puede usar para calcular AccumulatedValue en la IU. Por ejemplo:
      • Genera "d ref="$AccumulatedValue:Effect,JainaBlizzardPersistent,PeriodCount$"/>" oleadas de fragmentos de hielo. Cada oleada inflige daño a las unidades en un área.

Respuesta al nivel del jugador

• La respuesta del jugador es un nuevo catálogo de datos que permite definir patrones de respuesta cuando le sucede algo al jugador que los usa. Los diseñadores pueden usar activadores para asignar estos patrones de respuesta a jugadores determinados, cuyas unidades responderán a los eventos registrados como si todas tuvieran comportamientos de respuesta al daño.
• Los usuarios tienen la opción de establecer métodos de prioridad y fracaso para las respuestas del jugador.
• Con la respuesta al nivel del jugador ya no es necesario aplicar ciertos comportamientos para todo el mundo al crear comandantes, lo que mejora mucho el rendimiento del juego. Además, como solo tenéis que asignar las respuestas cuando responde el comandante correspondiente, el juego ya no tiene que repasar los datos de prevención de muerte para todos los comandantes cada vez.
• La respuesta del jugador ya no se limita a «la unidad está dañada» como en los comportamientos de respuesta al daño. También puede responder, por ejemplo, a la aparición de jugadores o unidades, la muerte de unidades del jugador, etc.

Barra de estado sin segmentar

• Ahora la acción de activador UI - Override Player Option (IU - Anular opción de jugador) permite que los creadores de mapas utilicen barras de estado más lineales y sin segmentar. Esto resulta útil para mods personalizados en los que hay que mostrar las fracciones vitales con mayor precisión.

Datos actualizados para el mod de elementos de Warcraft III

• En febrero de 2015 lanzamos un mod de elementos de Warcraft III. Aunque solo incluía elementos, muchos creadores de mods querían saber cómo crear habilidades al estilo RPG de Warcraft III con el editor de SC2. Entre los numerosos cambios al editor que incluye el parche, hemos incluido algunos ejemplos de estas nuevas características para los creadores de mods.
• Hemos colaborado con el creador del mod de la comunidad Renee's Warcraft III Mod para recrear su mod con las nuevas características del editor.
• Ahora el mod de elementos oficial de Warcraft III cuenta con una nueva base de datos que incluye razas, unidades, edificios y habilidades. Esperamos que estos ejemplos ayuden a los creadores de mods a familiarizarse con él.

Movimiento en formación

• Ahora StarCraft II incluye la opción de moverse en formación, que se puede activar y desactivar para cada jugador mediante activadores.
• Las unidades pueden moverse y atacar en formación cuadrada, con una separación predefinida entre cada una.
• De momento, y a diferencia de la versión de Warcraft III, el movimiento en formación no obligará a las unidades a mantener la misma velocidad.
• Los creadores de mods pueden modificar los datos para personalizar el comportamiento.

Trazado de rutas en el agua

• ¡StarCraft II ya permite trazar rutas en el agua!
• Nuevos tipos de trazado de ruta: Shallow Water (aguas poco profundas) y Deep Water (aguas profundas).
• Nuevos modos de trazado de ruta superficial: Float (flotante) y Amphibious (anfibio).
• Las unidades terrestres pueden trazar rutas en teselas de tipo Ground y Shallow Water.
• Las unidades flotantes pueden trazar rutas en teselas de tipo Shallow Water y Deep Water.
• Las unidades anfibias pueden trazar rutas en teselas de tipo Ground, Shallow Water y Deep Water.
• Las unidades aéreas pueden ir a cualquier parte donde no haya bloqueos de rutas aéreas.
• De momento, estos dos nuevos tipos de trazado de ruta solo se pueden pintar con el pincel de trazado de ruta del editor de terreno.

Múltiples capas de elevación

• Ahora en StarCraft II puede haber hasta 15 capas de elevación, en lugar de solo 3.

Rediseño del sistema de mejoras

• Esta es una parte muy importante del sistema de colecciones de datos y el nuevo sistema de comandantes.
• El antiguo sistema de mejoras no podía ser autosuficiente, una característica incompatible con la nueva filosofía de las colecciones de datos. Con él, las mejoras especificaban las habilidades o unidades a las que afectaban, junto con los efectos correspondientes.
• El nuevo sistema permite que las mejoras sean mucho más autosuficientes. Ahora las unidades deben declarar qué mejoras utilizan, en lugar de dejar que sean las mejoras las que dicten a que unidades afectan. A modo de ejemplo, ya no se implementarán mejoras diciendo cosas como «Aumenta en 10 la vida de los soldados», sino diciendo «Aumenta en 10 la vida de cualquier unidad que me utilice».
• Nuevo campo de CUpgrade: EffectArrayTemplate
  • Este campo es similar al antiguo EffectArray (selección de efecto), con las siguientes excepciones:
    • Puede incluir dos variables más:
      • ^ParamId^: ID de cualquier colección de datos que usa la mejora.
      • ^ParamLevel^: Nivel de mejora actual.
    • Permite usar referencias de datos y aritmética. Usad corchetes, «{» y «}», para crear fórmulas, como en el editor de texto.
    • Con las colecciones de datos ya es conveniente que los creadores de mods usen convenciones específicas para los nombres de los datos relacionados, así que es fácil usar ^ParamId^ para las entradas de datos relacionadas con la unidad que los usa.
    • Por ejemplo:
      • EffectArrayTemplate Reference="Effect,^ParamId^@Weapon,Amount" Value="{DataCollection,^ParamId^,UpgradeInfoWeapon.DamagePerLevel+3}"/
      • Esta mejora aumentará la cantidad de daño de la unidad que la usa una cantidad equivalente al campo UpgradeInfoWeapon.DamagePerLevel de la colección de datos de la unidad más tres.
      • También se puede poner un número fijo en la columna del valor. Así: «Value="4"».
• Los antiguos campos de CUpgrade siguen existiendo y mantienen la misma funcionalidad, así que todas las antiguas mejoras siguen funcionando. Podéis seguir creando mejoras a la antigua, pero no es recomendable.
• Compatibilidad con mejoras para todas las unidades
  • Como algunas mejoras están diseñadas para «todas las unidades» (de un tipo concreto), CUpgrade tiene ahora una bandera que enumera todas las unidades de la colección de datos.
  • Además, hemos añadido a CUpgrade dos campos de filtrado, EnumExcludedUserFlags y EnumRequiredUserFlags, que permiten a las mejoras filtrar por banderas todas las unidades de la colección de datos.
• Nuevas operaciones para mejoras: AddBaseMultiply y SubtractBaseMultiply
  • Estas operaciones modifican el campo de destino en función de su valor predeterminado, y no del actual, lo que, por lo general, es más útil que la operación Multiply. Por ejemplo, si tenemos 100 niveles de una mejora de tipo «Aumenta la vida de la unidad un 10%», seguramente prefiráis que la mejora aumente los puntos de vida una cantidad fija cada nivel en lugar de multiplicar los del último nivel cada vez. Además, Add/SubtractBaseMultiply permite usar degradaciones tecnológicas porque se puede deshacer en cualquier momento, a diferencia de Multiply.
• Ahora se pueden usar mejoras para habilitar o deshabilitar unidades para los jugadores.
• Nuevo campo de CWeapon: Rate Multiplier
  • Su valor por defecto es de 1.
  • Cuando el juego intente conseguir el periodo de un arma o un efecto CP, utilizará este multiplicador.
  • Este cambio permite mejorar las velocidades de las armas un valor porcentual en lugar de tener que cambiar directamente su periodo.

Sistema de orbes (más Disparo múltiple y Golpe crítico)

• Los orbes son modificadores de ataque que forman una parte importante del género MOBA.
• Se puede usar el sistema de respuesta al daño de StarCraft II para crear orbes, pero lo cierto es que los modificadores de ataque y la respuesta al daño son muy diferentes.
• La mayoría de las antiguas habilidades de «orbe» de SC2 no encajan en la definición tradicional del funcionamiento de los orbes, dado que están integradas en las propias armas y no se pueden añadir ni quitar de armas cualesquiera con facilidad. Así, si quisierais crear un objeto de tipo orbe en el juego, no sería razonable tener que introducir sus efectos en todas las armas de los héroes del juego.
• El sistema de orbes que hemos creado es una versión ampliada de los típicos sistemas de orbes de los MOBA, que incluye compatibilidad oficial con Disparo múltiple y Golpe crítico.
• Un sistema de orbes genuino debe tener las siguientes características:
  • Capacidad de aplicar sus efectos a los sistemas de las armas de ataque en ataque.
  • Capacidad de modificar los proyectiles.
  • Capacidad de añadir efectos especiales (como fuego, escarcha, un comportamiento, etc.) cuando el arma golpea al objetivo. También debe tener la capacidad de aplicar efectos antes y después del impacto.
    • Por poner un ejemplo, la habilidad Flecha oscura hace que el orbe aplique un efecto debilitador al objetivo que hace algo (resucitar un esqueleto) cuando este muere. Si el sistema de orbes solo pudiera aplicar efectos después del impacto, este podría matar a la unidad y no aparecería el esqueleto.
    • Otro ejemplo es la habilidad Fragmentos. Como causa daño de área adicional en función del daño del ataque principal, ese daño extra tiene que producirse después del efecto del impacto, dado que antes hay que generar el daño aleatorio del ataque principal.
  • Cuando un arma comienza la preparación del ataque, ya debe estar registrado el modificador del orbe incluso antes de que se produzca el propio ataque. Esto permite utilizar animaciones especiales para, por ejemplo, Golpe crítico.
  • Los orbes deben tener la capacidad de aplicar bonificaciones de daño de manera homogénea.
  • Los orbes deben tener la opción de validar sus efectos (para que, por poner un ejemplo, Porrazo o Golpe crítico no afecten a unidades amigas).
• Nueva bandera de efecto: MainImpact
  • Cuando está activada, marca un efecto de impacto como el principal de un árbol de efectos de armas, de modo que los modificadores de ataque puedan saber cuándo se activan sus efectos.
• Nuevo tipo de comportamiento: CBehaviorAttackModifier
  • Cuando se aplica, se activan los modificadores al iniciar un arma. Esto se aplica a todo el árbol de efectos de los ataques.
  • El campo Chance determina las probabilidades del modificador de ataque para cada ataque.
  • Múltiples modificadores añadidos a una unidad. El campo Unique Id permite determinar si pueden funcionar todos a la vez. En Warcraft III solo puede haber un efecto de orbe activo a la vez aunque el héroe se haya equipado con varios orbes. Sin embargo, lo normal es que los creadores de mods quieran tener la opción de activar varios a la vez.
  • El campo Stack Max determina la cantidad de veces que se pueden acumular las bonificaciones de daño.
  • Los campos Damage Bonus determinan si las bonificaciones son fijas o variables. Estos campos también son compatibles con acumuladores.
  • Los campos Validator determinan si los modificadores funcionan en objetivos concretos. Por ejemplo, seguramente no queréis que Golpe crítico funcione al atacar a vuestras propias unidades.
  • El campo PreImpactEffect activa un efecto antes de que se produzca el impacto.
  • El campo DamageInheritEffect activa un efecto después de que se produzca el impacto y traslada el daño del impacto al siguiente árbol de efectos. Estos efectos permiten crear efectos encadenados o causar daño de área en función del daño del impacto.
  • Puede determinar si el ataque puede fallar. Véase la sección del sistema de fallos, desvíos y bloqueos.
  • Con la bandera Hallucination Visual Only se puede determinar si el modificador de ataque aplicará el efecto del orbe en caso de que la unidad que lo ha lanzado sea una alucinación. Si el lanzador es una alucinación, seguramente no queráis que cause daño de área y resucite a los muertos en forma de esqueletos, pero puede haber creadores de mods que quieran tener la opción.
    • Con esta bandera se aplicará el modificador de ataque al árbol, así que la unidad podrá simular la animación de un ataque crítico y lanzar un proyectil modificado. Sin embargo, el ataque no aplicará un efecto de orbe real al impactar.
  • Los campos MultishotEffect y MultishotSearchPattern permiten lanzar un efecto de disparo múltiple a todos los objetivos del patrón de búsqueda si el valor de Chance es True y se cumplen todos los validadores. Si no se define el campo MultishotEffect, el efecto revertirá al original del ataque del arma.
  • También puede decidir si los objetivos de Disparo múltiple pueden recibir los efectos de impacto.
  • Puede habilitar armas según su índice, para que los héroes cuerpo a cuerpo con el objeto de orbe puedan usar sus armas ocultas para atacar a unidades aéreas.
  • Cuando se aplica a un ataque, el modificador puede poblar el término de actor de WeaponModifier en el evento WeaponStart, de manera que el sistema de actores pueda ejecutar distintas animaciones de ataque en función de los modificadores de ataque actuales.
  • Tiene la bandera IsCritical. Cuando está marcada, permite marcar el ataque como Critical, lo que activa el mensaje del actor correspondiente y puebla el mensaje de SetText y SetTextLocalized con la cantidad de daño para que los creadores de mods puedan utilizar texto flotante para Golpe crítico.
• Nuevo tipo de habilidad: CAbilAttackModifier
  • Con CBehaviorAttackModifier se pueden gestionar la mayoría de las habilidades de orbe, pero hay algunas, como Flechas abrasadoras de la sacerdotisa de la luna, donde el orbe sigue necesitando un «shell» que permita activar y desactivar el lanzamiento automático.
  • CBehaviorAttackModifier es un «shell» de CBehaviorAttackModifier, así que permite añadir un «shell» de lanzamiento manual o automático al orbe.
  • Puede asignar un coste al modificador, de manera que, cada vez que se lance la habilidad de orbe, cueste recursos o puntos de vida.
  • Tiene una propiedad de niveles, de manera que se puede ligar su crecimiento a las habilidades aprendidas por un héroe.
• Nuevo tipo de actor: CActorActionOverride
  • Se usa para anular el diseño del daño, del impacto y del misil de CActorAction.
  • Cuenta con los campos Damage Model, Impact Model y Missile Model para establecer los vínculos a los modelos que los sustituyen.
  • Cuando se inicie CActorAction, iniciará a su vez el evento ActionInitModifier.
  • CActorActionOverride puede capturar el evento y crearse a sí mismo dentro del ámbito de CActorAction. A continuación, puede usar ActionOverrideApplyTo para aplicarse a CActorActions.
  • CActorAction extraerá los datos de CActorActionOverride y anulará sus modelos de ataque.

Compatibilidad con habilidades dinámicas

• Ahora los creadores de mods pueden usar activadores para quitar o poner habilidades a las unidades.

Intercambio de habilidades

• Nueva función: UnitAbilityChangeLink()
  • Permite trasladar una habilidad de una unidad a otra conservando sus cargas, tiempo de reutilización y nivel.
  • Se diferencia de la sustitución de catálogo en que se basa en casos por cada habilidad.
  • También hemos añadido el nuevo campo Ability Replace al comportamiento de tipo de consumidor de energía, que proporciona una versión de datos de esta característica.
  • Las habilidades solo se pueden intercambiar por otras de la misma clase CAbil. Por ejemplo, una habilidad de objetivo solo se puede intercambiar por otra igual.
  • La versión de datos del intercambio de habilidades afectará también a las habilidades de los héroes que se pueden aprender.

Referencia de «struct» de paso en la interfaz de activadores

• Ahora las acciones y funciones de los activadores pueden definir tipos de registros como parámetros.
• Ahora se pueden pasar las variables de los registros a las acciones y funciones como parámetro por referencia.
• Los parámetros de los registros se pueden leer y modificar. Las modificaciones afectarán a la variable del registro fuera del ámbito de la función.

Nuevas API de activadores: estancia de tablas de datos

• Funciona como las tablas de datos, con la excepción de que se pueden tener varias estancias, contar sus valores y copiar valores entre las tablas de datos.
• La antigua tabla de datos es una sola. Al añadir una versión por estancias, los diseñadores podrán organizar mejor los datos del momento de ejecución.

Anulación de descripciones de habilidades y objetos por unidad u objeto

• Nuevas funciones nativas: UnitSetInfoButtonTooltip y UnitClearInfoButtonTooltip
• Permite anular descripciones en botones de comando.
• La acción del activador «set» espera tres parámetros: el objeto o unidad que se va a modificar, la clave de modificación y el nuevo texto de la descripción.
• La clave de modificación acepta tres formatos distintos, lo que significa que hay tres formas de personalizar las descripciones de los comandos:
  • Anular las descripciones de comandos a través de AbilCmd
    • La clave sería el AbilCmd. P. ej., «paquete de estimulantes,0».
  • Anular las descripciones de comandos a través del vínculo de botón
  • La clave sería la ID del botón. P. ej., «soldado».
  • Anular las descripciones de los objetos de la propia unidad
    • En casos como este se usa «@» como clave.
• Funciona aunque se haya anulado el panel de comandos para que muestre los paneles de otras unidades.

Compatibilidad con disparos de habilidad

• ¡Ya se pueden usar disparos de habilidad en StarCraft II!
• Nuevo campo de bandera para efectos de lanzamiento de misil: SearchFlags
  • Nueva bandera de búsqueda de efectos de lanzamiento de misil: DynamicSearchArea
    • Esto permite buscar disparos de habilidad. Sin ello, el efecto es un misil normal.
  • Nueva bandera de búsqueda de efectos de lanzamiento de misil: ArriveOnSearchHit
    • Determina si el misil es un disparo de habilidad detonante o perforador. Abajo se explica.
• Nuevos campos de efectos de lanzamiento de misil:
  • SearchHitArriveEffect
    • Solo funciona cuando está activado ArriveOnSearchHit. El efecto se ejecuta cuando el misil alcanza a un objetivo y estalla.
    • Nota: el efecto se ejecutará en el último punto de búsqueda antes de que muera el misil, no en el punto al que apunta. El funcionamiento es similar al de un efecto de final.
  • SearchEffect
    • El misil ejecutará este efecto cada bucle de partida y anulará el parámetro de altura de la zona de búsqueda en función de su propia velocidad actual. En esencia, no dejará huecos entre búsqueda y búsqueda.
    • Nota: el truco TVE mostrará una altura predeterminada incorrecta, en lugar de la altura correcta del efecto de búsqueda y anulación.
  • SearchMaxCount
    • Determina la cantidad máxima de búsquedas durante la trayectoria completa del misil, no el número máximo de cada búsqueda individual. El misil dejará de buscar después de encontrar el número de objetivos fijado por SearchMaxCount.
    • Una vez alcanzado el valor de SearchMaxCount, si no está definido ArriveOnSearchHit, el misil continuará hacia su destino, pero sin realizar más búsquedas de disparo de habilidad.
    • Una vez alcanzado el valor de SearchMaxCount, si está definido ArriveOnSearchHit, el misil estallará y ejecutará SearchHitArriveEffect en su último punto de búsqueda. Tened en cuenta que este no es el objetivo del misil, pues este no habrá llegado allí para entonces.
    • Si el valor de SearchMaxCount es 0 y está definido ArriveOnSearchHit, el misil no limitará el recuento máximo de búsquedas. Mientras uno solo de sus efectos de búsqueda encuentre un objetivo, el misil estallará y ejecutará SearchHitArriveEffect en su último punto de búsqueda.

Sistema de héroes mejorado

• Nueva clase de CUnit: CUnitHero
• Cinco campos nuevos (en comparación con CUnit):
  • MainAttribute
    • Un solo vínculo de comportamiento que se aplica o retira de manera automática en el momento de la creación o mutación de la unidad.
    • No es diferente a un campo de comportamiento normal. Sin embargo, su uso como un solo campo permite leerlo con facilidad a través de una función de catálogo para determinar el atributo principal de un héroe.
  • MainAttributeDamageBonus
    • Este campo determina la magnitud de la bonificación de daño que recibe un héroe por cada punto de MainAttribute.
  • AttributePointsInfoArray
    • Establece los puntos de atributo iniciales y de subida de nivel de un héroe en función de su nivel actual. Solo afecta a los puntos de atributo y no aplica el comportamiento de atributo si el héroe no tiene ya uno.
  • LearnInfoArray
    • Utiliza la misma estructura que CAbilLearn_LearnInfo. Si cualquiera de los índices establece un vínculo de habilidad, anulará la información correspondiente del aprendizaje de habilidad en el héroe. Como consecuencia, ya no habrá que crear aprendizajes de habilidad aparte para cada héroe.
    • También se puede generar automáticamente el botón de comando de Learn Info cuando se establece la bandera Create Default Button.
  • TierRequirements
    • Este campo anulará los requisitos tecnológicos de CAbilTrain cuando la habilidad se use para entrenar al héroe actual y ya exista más de un alias tecnológico de la unidad para el jugador actual.
• Nueva bandera de CAbilityRevive: Override Alert Icon
  • Cuando un jugador reviva a un héroe con una habilidad CAbilRevive con Override Alert Icon activado, la habilidad utilizará el icono de CAbilRevive como icono de alerta en lugar del icono del propio héroe.
• Se han añadido nuevas funciones nativas:
  • TechTreeSetProduceCap
  • TechTreeGetProduceCap
    • Los activadores pueden llamar a estas funciones para que establezcan un límite tecnológico basado en unidades, mejoras, habilidades, comportamientos o efectos.
    • Se pueden usar también para personalizar el límite de entrenamiento de héroes.
• Puntos de atributo básicos y puntos de atributo adicionales
  • Ahora los comportamientos de los atributos en CHeroUnit tienen dos valores diferentes: Base y Bonus.
  • Los puntos de atributo iniciales y de subida de nivel de un héroe (configurados en AttributePointsInfoArray) conformarán el valor Base, mientras que otros cambios (como bonificaciones de comportamientos) constituirán el de Bonus.
  • En el panel de información de la unidad, los puntos de atributos básicos aparecerán en color blanco, mientras que los de bonificación lo harán en color verde (+X).
  • Las bonificaciones que añaden los puntos de atributos básicos ya no aparecen como números en verde (+X). Ahora se añaden a los campos básicos de daño, armadura y velocidad del arma.
  • Los atributos añadidos por beneficios u objetos seguirán apareciendo como números en verde (+X).
  • Nuevas banderas de CEffectApplyBehavior:
    • SetAttributePoints: Al activar esta bandera, se establecen puntos de atributo para el comportamiento del atributo.
    • SetAttributeBasePoints: Al activar esta bandera, se modifican los puntos básicos en lugar de los de bonificación.
• Se ha añadido un nuevo campo CabilTrain: IgnoreUnitCostRequirements
  • Cuando se establece, la habilidad de entrenar ignora los costes de unidad mientras se cumplan los requisitos tecnológicos.
  • Esto se puede usar para introducir mecánicas especiales como «El primer héroe es gratuito».
• Mejoras en el submenú de aprendizaje de habilidad
  • Nueva bandera de aprendizaje de habilidad: ClearSubmenuOnPointsSpent
    • Cuando se establece, una unidad que use la habilidad saldrá automáticamente de los cuadros de mando del submenú después de gastar todos los puntos de habilidad.
  • Nueva bandera de aprendizaje de habilidad: HideSubmenuOnLearnedAll
    • Cuando se establece, el botón del submenú de aprendizaje de habilidad queda oculto después de que una unidad que use la habilidad haya aprendido todas las posibles.
  • Se ha corregido un error que provocaba que, si se gastaban todos los puntos, el botón de aprendizaje de la unidad mostrase «Nivel requerido:» en color rojo aunque la habilidad ya hubiese llegado al nivel necesario.
  • Se ha corregido un error que, en ocasiones, permitía a los jugadores usar la tecla Mayús para evitar las restricciones de nivel para aprender una habilidad.
• Se ha añadido un nuevo estado de recuento de unidades de un requisito: QueuedOrBetterOrRevivable
  • Al contar unidades tecnológicas, esto incluye a los héroes que están reviviendo y los que pueden revivir.
  • Esto resulta muy útil para introducir restricciones en el entrenamiento de los héroes. Por ejemplo, si habéis establecido la restricción «No puedes entrenar más de 3 héroes», seguramente no queráis que se contabilicen solo los vivos.
• Nivel de héroe y fórmula de EXP
  • Nuevo campo de CBehaviorVeterancy: Levels
    • Establece el nivel máximo de un héroe.
    • El campo se puede mejorar, lo que permite a los creadores de mods cambiar los niveles máximos de las habilidades en tiempo de ejecución.
    • Su valor por defecto es 0, que equivale al funcionamiento anterior del sistema de niveles.
  • Nuevos campos de CBehaviorVeterancy:
    • MinVeterancyXPBonusPerLevel
    • MinVeterancyXPPreviousValueFactor
    • MinVeterancyXPLevelFactor
    • Si el tamaño de VeterancyLevelArray es menor que el número del campo Levels, el juego generará automáticamente la EXP mínima de los niveles extra basándose en estos factores.
    • La fórmula utilizada es la siguiente (donde X es el nivel y F(X) la EXP mínima del nivel):
      • F(X) = F(X-1) * MinVeterancyXPPreviousValueFactor + MinVeterancyXPLevelFactor * X + MinVeterancyXPBonusPerLevel
    • Esto solo se usa cuando el nivel X es superior al tamaño de VeterancyLevelArray. En otros casos, tomará la EXP mínima de la tabla VeterancyLevelArray.
• Fracción de EXP que se recibe en función del tipo de objetivo
  • Nuevo campo de CBehaviorVeterancy: XPReceiveFraction
    • Este campo es una selección de estructuras que permite a los usuarios especificar un filtro de objetivos y un valor fraccionario acumulable para cada selección.
    • Cada vez que un héroe reciba EXP, el juego cotejará los filtros de objetivos y la unidad destruida, y aplicará la fracción de EXP si encaja en alguno de ellos.
    • Esto, si se combina con los acumuladores, permite a los usuarios crear fórmulas de EXP como «Las unidades invocadas dan la mitad de EXP» o «Los héroes ganan menos EXP al destruir criaturas según el nivel actual del héroe».
• Se ha añadido un nuevo validador: CValidatorUnitCompareAbilSkillPoint
  • Comprueba los puntos de habilidad de una unidad. Esto incluye los gastados, los no gastados, los extra y los totales.

Mejoras del sistema de objetos e inventario

• Los sistemas de objetos son fundamentales para los RPG, así que estamos encantados de haber aumentado la cobertura que les ofrece nuestro editor.
• Compatibilidad con construcción con objetos
  • Ahora se pueden usar los objetos del inventario de una unidad para construir estructuras.
  • Se puede hacer que el héroe tenga que mantener una canalización para utilizar esta capacidad de los objetos. También es posible que los jugadores «teletransporten» edificios, como las estructuras protoss.
  • Este tipo de objetos pueden resultar útiles para construir expansiones. El héroe puede construir un concejo de bolsillo y colocarlo en una nueva expansión, donde el edificio se construiría solo.
• Mostrar el inventario a otros jugadores
  • Nueva propiedad de CInventoryPanel: ShowForAllPlayers
    • Si su valor es True, los jugadores podrán seleccionar las unidades de otros jugadores para ver su inventario. Lo que no podrán es usar los objetos que contenga.
• Uso de habilidades sobre objetos del inventario
  • Ahora CCommandButton expone su propiedad ButtonOtherUnit. Los jugadores podrán usar la vinculación de propiedad para vincular el objeto de la unidad (el objeto en sí, no el portador) a un marco de objetivo o de otro tipo.
  • Con esta función, los usuarios pueden lanzar habilidades sobre un objeto de su inventario para transferirlo o mejorarlo.
  • Además, ahora pueden hacer doble clic en los portales a la ciudad para teletransportarse automáticamente a su concejo de mayor nivel.
• Panel de inventario accesible de manera global
  • Ahora los usuarios pueden anular la propiedad del inventario de unidad de CInventoryPanel para que se vea el inventario de una unidad que no es la seleccionada en ese momento.
  • También pueden usar activadores para crear nuevos controles de diálogo para el inventario. Esto permite usar operadores como el control de diálogo del cuadro de mando que se introdujo en Legacy of the Void.
  • Para establecer la unidad, solo hay que seleccionar Use SetDialogItemUnit. Si el valor de este es nulo, la unidad volverá a ser la del líder seleccionado.
• Mostrar el inventario del comprador
  • Hasta ahora, StarCraft II no se entendía bien con las tiendas de objetos neutrales al estilo de Warcraft III. Hasta este parche, al hacer clic en una unidad de una tienda, no se podía ver el inventario de la unidad del comprador.
  • Ahora las tiendas neutrales mostrarán el inventario del comprador siempre que no tengan un inventario propio y el panel del inventario no esté anulado para mostrar el de una unidad concreta.
• Datos de cargas en CUnit
  • Se han añadido datos de cargas a unidades y objetos, de modo que, al venderlos, se pueda establecer la información sobre existencias por defecto (como el tiempo de reutilización inicial en las tiendas, el máximo de acumulaciones en ellas, etc.).
  • Se puede usar una bandera para indicar a una habilidad CAbilTrain que ignore estos ajustes por defecto y use los personalizados de la propia habilidad.
    • Si no se activa la bandera y la habilidad tiene datos propios, se sumarán ambos datos de cargas.
• Objetos potenciadores «reales»
  • Nuevo tipo de objeto: CItemAbilPowerUp
  • Ahora se pueden implementar objetos potenciadores como objetos reales, en lugar de tener que simular unidades.
  • CItemAbilPowerUp procede de CItemAbil. Las únicas diferencias son que se usa automáticamente cuando se recoge y que se puede recoger aunque el inventario de la unidad esté lleno.
  • CItemAbilPowerUp solo lo pueden usar unidades con inventario. Además, la unidad en cuestión debe tener la bandera CanUseItem activada.
  • Estos nuevos objetos potenciadores son objetos reales, así que los eventos de inventario les afectan y se pueden utilizar en el sistema de botín.
  • CItemAbilPowerUp examinará si el lanzador puede utilizar la habilidad potenciadora en CItemAbilPowerUp. En caso de que no, generará un mensaje de error y no obligará al lanzador a ir al objeto.
  • La bandera KillAfterUse permite destruir el objeto después de que el lanzador haya usado el potenciador.
  • Una unidad normal con inventario, pero sin la bandera CanUseItem activada, podrá recoger potenciadores y llevárselos a un héroe.
• Nueva bandera de EAbilInventoryFlag: ItemDropOnDeath
  • Esta bandera obliga a una unidad a soltar todos sus objetos al morir, aunque sea posible revivirla. Esto puede resultar útil para unidades normales con la habilidad Mochila de Warcraft III.
• Nueva bandera de EAbilInventoryFlag: CanUseItem
  • Esta bandera determina si las unidades pueden usar objetos. Ayuda a crear unidades con inventarios portadores, capaces de transportar objetos, pero no usarlos.
• Nueva bandera de EAbilInventoryFlag: CanApplyEquipBehavior
  • Esta bandera determina si las unidades pueden beneficiarse de mejoras de estado de objetos (p. ej., +5 de fuerza). Ayuda a crear unidades con inventarios portadores.
• Nueva bandera de CItemAbil: Transient
  • Con esta bandera activada, la habilidad del objeto se lanzará como «transitoria», aunque la original no lo fuera.
• Se ha corregido un error que provocaba que los inventarios siguiesen intentando recoger objetos cuando eran destruidos al acercarse.
• Se ha corregido un error que impedía que funcionase CAbilSpawn.
• Se ha corregido un error que podía provocar que, al empeñar un objeto del inventario a la distancia máxima de empeño, se perdiese el objeto sin recibir recursos.
• Nuevos subnombres para eventos de actor Abil: PawnSource y PawnTarget
  • Se activan al empeñar un objeto.
• Nuevo campo de CAbilInventory: Requirements
  • Cuando se establece, la habilidad del inventario queda deshabilitada antes de que se cumplan los requisitos tecnológicos.
  • También se oculta entonces la IU del inventario.
• Nueva bandera de CValidatorUnitInventory: RequireEnabled
  • Cuando está marcada, el validador solo devuelve e_CmdOK si se activa la habilidad de inventario con selección de objetivos y se han cumplido sus requisitos tecnológicos.
• Para responder a los eventos de Player Use Effect, hay una nueva API de activadores que permite al usuario capturar el objeto usado para crear el efecto (si lo hay) y su tipo.
• Ahora los objetos de habilidad pueden optar por usar sus propios vínculos de tiempo de reutilización, en lugar de los heredados de la habilidad.

Compatibilidad con tiendas aliadas y neutrales

• Las tiendas aliadas/neutrales son edificios aliados/neutrales con los que pueden interactuar otros jugadores con la ayuda de habilidades CAbilInteract.
• Para todas las habilidades, ahora el campo Tech Player tiene una nueva opción: Caster.
  • Al usar Caster como valor para el campo Tech Player de CAbilTrain, la habilidad comprobará los requisitos tecnológicos del jugador que ha dado la orden.
  • Esto resulta útil para crear una habilidad de «vender unidad/vender objeto basada en el árbol tecnológico del comprador».
• Nuevo campo de CabilTrain: AgentUnitValidator
  • Cuando se establece, la habilidad requiere una unidad agente que la lance, y se coteja con los validadores establecidos en este campo al entrenar unidades.
  • Con este campo es muy fácil crear habilidades de «tienda de objetos» en SC2.
    • Para las tiendas de objetos, normalmente los usuarios querrán que la unidad compradora tenga un inventario para poder comprar objetos.
    • Antes esta opción no existía en SC2, así que, aunque la unidad compradora no tuviera inventario, el objeto se creaba siempre.
    • Con el campo AgentUnitValidator, los usuarios pueden añadir validadores como «La unidad tiene un inventario válido» o «El inventario no está lleno». Por tanto, si la unidad agente no tiene inventario, la habilidad dará un mensaje de error y no se lanzará.
• Nueva bandera de CAbilTrain: ChargeCasterPlayer
  • Normalmente, las habilidades de tiendas neutrales requieren que el comprador y el vendedor intercambien los recursos a través de la bandera Ally Spending. En caso de no ser así, el comprador recibiría el mensaje de error «No se puede gastar en ese jugador».
  • Por defecto, los jugadores neutrales comparten los costes con todos los jugadores, pero, si un usuario fuera a crear una tienda aliada, donde los jugadores aliados puedan comprar objetos o unidades, lo normal es que no quiera que esos jugadores compartan el gasto. De no ser así, los jugadores podrían gastar el dinero de sus aliados.
  • Para resolver este problema, se ha diseñado la bandera ChargeCasterPlayer. Cuando está activada, el coste del objeto o la unidad vendidos se le cobra al jugador que haya emitido la orden de compra, aunque el comprador y el vendedor no compartan el gasto.
  • Si hay otros jugadores que compartan gastos con el comprador y este no tiene recursos suficientes para pagar el coste, la habilidad les cobrará el coste a ellos.
• Nueva bandera de CAbilInteract: AlwaysShowCommandCard
  • Cuando se activa, las unidades de la tienda muestran su cuadro de mando a todos los jugadores que pueden interactuar con ellas (cosa que se determina mediante el campo de filtrado de objetivos de CAbilInteract), aunque el jugador no tenga una unidad agente válida cerca de la tienda.
  • Por tanto, aunque un jugador no tenga una unidad agente cerca de la tienda, podrá ver lo que la tienda vende.
  • Lo que no podrá hacer es usar el cuadro de mando si no controla la unidad de la tienda (por ejemplo, por no tener una unidad agente cerca).
• Se ha corregido un error que provocaba que las habilidades de interacción intentaran adquirir constantemente una unidad sin comprobar el campo ValidatorArray.

Sistema de seguimiento de unidad de comportamiento

• Nuevo tipo de comportamiento: BehaviorUnitTracker
  • El comportamiento funciona como una lista de unidades. Puede almacenar todas las unidades que se le añaden y tiene campos para validadores y recuento máximo. Cada vez que un miembro de la lista no cumple con el validador establecido, se borra de la lista.
  • También hay banderas que permiten a los usuarios convertir el rastreador en una lista global o una lista basada en jugadores, que no requieren una estancia de comportamiento para funcionar.
• Nuevo acumulador: CAccumulatorTrackedUnitCount
  • Permite a los usuarios utilizar acumuladores en función de la cantidad de unidades que hay en la lista en cuestión.
• Nuevos efectos: CEffectAddTrackedUnit, CEffectClearTrackedUnits y CEffectRemoveTrackedUnit
  • Permiten al usuario incluir unidades en una lista o quitarlas.
• Nuevo efecto: CEffectEnumTrackedUnits
  • Permite al usuario recorrer en bucle la lista de seguimiento de unidades y ejecutar efectos basados en filtros en cada una de ellas.
• Nuevos validadores: CValidatorCompareTrackedUnitsCount y CValidatorIsUnitTracked
  • Se pueden usar para contar cuántas unidades están siendo seguidas por el comportamiento y comprobar si una unidad está en una lista de seguimiento determinada.
• El sistema de seguimiento resulta muy útil al tratar de mantener mapeados de tipo «una a muchas» entre unidades.
  • Por ejemplo, permite seguir a una unidad invocadora hasta sus unidades invocadas.

Otros cambios en el sistema de comportamiento

• Alias de acumulación de comportamientos
  • Esta característica permite que se acumulen los comportamientos en función de una «ID de acumulación» y no de una ID de comportamiento.
  • Por ejemplo, en Warcraft III, tanto el archimago como diferentes monstruos tienen una versión de Aura de luminosidad. Se trata de dos beneficios distintos y, si tenéis ambos tipos de unidades, puede que no queráis que las unidades cercanas los reciban ambos. En este caso se debe priorizar siempre la versión del héroe.
  • Dos nuevos campos de CBehaviorBuff: StackAlias (cadena) y StackAliasPriority (entero)
    • Si se aplican a la misma unidad dos beneficios del mismo StackAlias, compartirán un mismo recuento máximo que dará prioridad al inferior. Si el total excede el recuento máximo compartido, el juego empezará a eliminar acumulaciones empezando por el beneficio con el valor más bajo de StackAliasPriority y luego por la duración inferior. Esto continuará hasta que el recuento total de acumulaciones sea igual al máximo.
  • New evento de actor: BehaviorStackAlias
    • Permite capturar eventos de comportamiento (activado, desactivado, respuesta de daño, etc.) en función del StackAlias del comportamiento y no de su ID.
    • También permite compartir actores entre comportamientos con los mismos StackAlias, pues lo normal es que queráis que todas las versiones del beneficio de Aura de luminosidad compartan un mismo diseño artístico.
  • Nuevo campo de CEffectRemoveBehavior: StackAlias
    • Permite eliminar beneficios en función de StackAlias.
  • Nuevo validador: CValidatorUnitBehaviorStackAlias
    • Permite contar acumulaciones de comportamiento por StackAlias. Se contabilizarán todos los comportamientos de la unidad con el StackAlias indicado. Además, se puede hacer que se contabilicen solo los comportamientos habilitados.
• Compatibilidad con texto flotante de respuesta de daño de actor
  • Cuando CActorMsgBehavior activa un evento con un subnombre DamageHandled, el uso de mensajes de SetText y SetTextLocalized después del evento permite establecer automáticamente el texto por medio de la cantidad de daño modificada.
  • El daño reemplazará a la variable «%AMOUNT%» en el texto objetivo.
  • Esto resulta útil para crear texto flotante de daño para las respuestas de daño.
• Mayor compatibilidad para eventos de actor de comportamiento activado/desactivado
  • Ahora los eventos de comportamiento activado/desactivado establecerán parámetros de efecto para la última acumulación aplicada o eliminada.
  • Esto resulta útil para configurar con mayor precisión los actores de comportamiento. Hasta ahora, los usuarios no podían hacer referencia al lanzador de un comportamiento en eventos de comportamiento activado/desactivado.
• Nuevo estado de comportamiento: Cannot Die
  • Indica que una unidad «no puede morir» salvo que se retire el comportamiento.
  • Aunque se puede conseguir un resultado similar utilizando respuestas de daño, las respuestas a la destrucción solo pueden impedir la destrucción por daño. Este estado de comportamiento impide la destrucción por cualquier razón (por ejemplo, que el valor de vida sea 0).
  • Este estado ofrece una alternativa sencilla para un sistema de prevención de destrucción basado en activadores.
• Nuevo estado de comportamiento: Suppress Kill Credit
  • Impide que una unidad otorgue créditos de muerte o créditos de recursos por muerte al jugador causante de la muerte.
  • Es útil para crear alucinaciones de unidades.
• Nuevo campo de CBehaviorBuff: DeathType
  • Esto puede anular el DeathType de una unidad e ignorará el tipo de destrucción del efecto de daño que la destruye.
  • El tipo de destrucción Remove no se puede anular de este modo.
  • El valor por defecto es Unknown, lo que equivale a decir «no anular».
• Nuevo tipo de destrucción: Reincarnation
  • Impide que las unidades suelten botín y objetos al morir.
• Ahora el validador CValidatorUnitCompareBehaviorCount y los efectos CEffectRemoveBehavior y CEffectTransferBehavior comparten los siguientes campos de configuración detallados:
  • BehaviorCategories, BehaviorClass, BehaviorAlignment, ExcludeOriginPlayer, ExcludeCasterUnit, RequireOriginPlayer y RequireCasterUnit.
• Hasta ahora, estos validadores y efectos solo tenían un campo CEffectBehavior, y los nuevos campos adicionales eran exclusivos de CEffectBehavior.
• Estas incorporaciones permiten contar, eliminar y transferir comportamientos con más control.
• Ahora, por ejemplo, los usuarios pueden eliminar acumulaciones de comportamiento añadidas por un jugador lanzador de unidades, etc.
• También resulta útil para implementar «disipaciones inteligentes» que, por ejemplo, eliminen solo los beneficios aplicados por unidades enemigas.
• Nuevo campo de CValidatorUnitCompareBehaviorCount, CEffectRemoveBehavior y CEffectTransferBehavior: Matches All
  • Determina si se ejecuta el efecto/validador cuando se cumple cualquiera de los campos de configuración o cuando hay que cumplir todos.

Compatibilidad mejorada con cadáveres

• Nueva bandera de CEffectModifyUnit_ModifyFlags: Remove
  • Esta bandera elimina directamente la unidad del juego y destruye todo el ámbito de su actor.
  • Se ha añadido porque los usuarios no pueden utilizar el efecto Remove de CEffectDamage para eliminar un cadáver.
• Nuevo filtro de unidad: Decaying
  • Una unidad «Decaying» se define como una que está en el suelo y lleva destruida un tiempo. No es lo mismo que una que, aunque ha sido destruida, está aún cayendo al suelo y generando un cadáver. En términos técnicos, esto se da cuando Death Time está activo y Revive Delay ha pasado.
  • El objeto de este filtro es que las habilidades que afectan a los cadáveres no funcionen con unidades que hayan muerto hace poco y estén aún generando un cadáver.
  • Si el valor de Death Time se ha establecido en -1, se salta la fase de descomposición. Así, por ejemplo, en Warcraft III los héroes nunca pasan por ella.
• Nuevo filtro de unidad: Raiseable
  • Ahora CEffectModifyUnit puede establecer que un cadáver es Unraiseable.
  • Unraiseable nos permite marcar que un cadáver ya ha sido utilizado.
    • Por ejemplo, mientras un necrófago está devorando un cadáver, este aún existe, pero el creador del mod puede querer que no sea posible revivirlo o resucitarlo como no-muerto. En este caso, puede hacer que las habilidades solo afecten a cadáveres Raiseable y aplicar el valor Unraiseable a los cadáveres mientras los están devorando.
• Nueva bandera: Allow Corpse
  • Con esta bandera activada, las habilidades de transporte podrán llevar cadáveres entre su cargamento.

Sistema de tipos de ataque, daño y armadura

• Nuevo campo de CWeapon: Attack Type
  • Los creadores de mods pueden cambiar los multiplicadores de daño de cada tipo de ataque contra cada tipo de armadura en los datos del juego.
  • Attack Type afectará a todos los efectos de daño del árbol de armas entero, así que ahora los creadores de mods podrán modificar los multiplicadores de daño en el nivel de las armas en lugar de tener que pasar por todos los efectos del árbol de efectos para cambiar sus factores de daño.
• Nuevo campo de CUnit: Armor Type
  • Armor Type determina los multiplicadores de daño de las armas usadas contra las unidades.
• Nuevo validador: CValidatorUnitArmor
  • Permite a los usuarios comprobar el tipo de armadura de una unidad.
• Nuevo campo de CEffectDamage: Damage Type
  • Los creadores de mods pueden cambiar los filtros de objetivo para Damage Type en los datos del juego.
  • El uso de filtros de objetivo en los tipos de daño permite configurar todos los efectos de daño y daño de área en el juego. También se pueden usar los filtros para decidir si ciertos efectos de daño afectan a determinados objetivos.
  • Por ejemplo, si usamos el filtro Ally para los objetivos en todos los tipos de daño, los usuarios pueden hacer con facilidad que las armas ya no inflijan daño esparcido a los aliados. Esto resulta útil al crear mods cooperativos, dado que afecta a muchos mods cuyos hechizos y armas de área pueden tener diferentes efectos de fuego amigo.

Desvíos, bloqueos y probabilidad de fallo de los efectos

• Se ha ampliado la estructura Behavior Damage Response para que no afecte solo a los casos de respuesta de daño.
• Probabilidad de fallo
  • Nueva bandera de CWeapon: NeverMiss
    • Por defecto, las armas mantendrán su antiguo comportamiento.
  • Además, los modificadores de ataque pueden añadir la propiedad NeverMiss al árbol de efectos de un arma.
  • Si el árbol de efectos de un arma dice que puede fallar, cuando el arma dispare, se comprobará el porcentaje de fallo tanto para el atacante como para el defensor. A continuación se marcará el resultado del ataque en función de los validadores y probabilidades establecidos en la estructura de respuesta.
  • Las unidades terrestres que atacan a objetivos situados en elevaciones de altura superior también pueden tener mayor probabilidad de fallo, algo que se puede modificar en los datos del juego.
  • Si el árbol de efectos de un arma se ha marcado como Missed, el arma no aplicará el daño de impacto ni el de ningún efecto de orbe.
  • Cuando un arma falla, envía un evento de arma de actor con Missed como subnombre. De este modo, los creadores de mods pueden decidir si quieren capturar el evento para colocar un texto flotante que diga «¡Fallo!» sobre la unidad o generar un efecto de esquivar.
• Probabilidad de bloqueo
  • Nuevo campo de CEffect: CanBeBlocked
    • Determina si se puede bloquear el efecto. Está deshabilitado por defecto.
  • Cuando se ejecuta un efecto, el juego consulta a la estructura de respuesta sobre la unidad que recibe el impacto y comprueba sus probabilidades de bloqueo y los posibles validadores.
  • En caso de bloqueo, se cancela el efecto sin ejecutarse. A continuación, el efecto envía un evento de efecto de actor con Blocked como subnombre para que los usuarios puedan establecer los actores adecuados.
  • Esta característica es útil para crear comportamientos de bloqueo de hechizos.
• Probabilidad de desvío
  • Nueva bandera de CEffect: ValidateImpactDeflection
    • Determina si se puede desviar el efecto. Está deshabilitado por defecto.
  • El desvío es casi igual que el bloqueo, salvo por el hecho de que el efecto que se habría producido se replica y se devuelve al lanzador.
  • En el efecto desviado se revierten las propiedades de lanzador y objetivo, y el sistema considera que se trata de un ataque del objetivo original contra la unidad lanzadora original. La configuración de bonificaciones de daño del árbol de efectos reflejado seguirá utilizando las del lanzador original.
  • Otra diferencia entre el desvío y el bloqueo es que cada árbol de efectos solo evaluará el desvío una vez. Si un efecto supera el chequeo del desvío, el resto del árbol de efectos no volverá a comprobar la probabilidad de desvío, incluso si el árbol incluye efectos posteriores con la bandera ValidateImpactDeflection activada.

Cambios en el sistema de mutación de unidades

• Morph/Unmorph Toggle
  • Nueva bandera de CAbilMorph: Toggle
  • Nuevo campo de CAbilMorph: InforArrayUnmorph
    • Cuando se activa Toggle, se pueden usar habilidades de mutación para alternar entre dos cadenas de tipos de unidad distintas.
  • Nuevo índice de comando de CAbilMorph: Unmorph
    • Para una habilidad de mutación compatible con Toggle, después de que la unidad haya mutado, se sigue pudiendo dar un comando de Unmorph a la habilidad, lo que hará que la unidad dé comienzo al proceso de mutación definido en el campo InforArrayUnmorph.
    • En la mayoría de los casos, hay que establecer el campo InforArrayUnmorph para que el tipo final de la unidad sea su estado normal. De este modo, se podrá devolver a su estado normal con el comando Unmorph.
  • Nuevo campo de CabilMorph: ValidatorArrayUnmorph
    • Valida si una unidad mutada puede usar el comando Unmorph.
  • Nueva bandera de CabilMorph: AutoUnmorph
    • Determina si la unidad mutada intentará automáticamente volver a mutar cuando le sea posible.
  • Nuevos campos de CabilMorph: BehaviorOn/BehaviorOff
    • Cuando se establecen, la habilidad aplica el beneficio de BehaviorOn a la unidad cuando está en su estado mutado y el de BehaviorOff cuando está en su estado normal. Estos dos campos solo funcionarán si la habilidad de mutación está marcada como Toggle.
  • Aunque una unidad se cree directamente en su estado mutado, las habilidades de mutación seguirán considerando que ha pasado por el proceso de mutación. Esto aplicará los comportamientos correspondientes y permitirá usar el comando Unmorph.
• Recuento de tecnología de mutación
  • Nueva bandera de CAbilMorph: ProvideSourceUnitTech
    • Cuando está activada, CAbilMorph transmitirá el tipo de unidad de la unidad de origen a la mutada. La unidad final heredará de forma automática el vínculo de unidad de la original como alias tecnológico.
    • Esta propiedad se transmite a través de toda la cadena de mutación.
    • P. ej., concejo -> fortaleza -> castillo
    • Un castillo contaría como una fortaleza y un concejo, e incluso un castillo creado directamente contaría como ambas cosas a pesar de no haber mutado a partir de ninguna de ellas.
    • ¿Por qué no nos limitamos a añadir el concejo y la fortaleza al alias del castillo (añadiéndolos a su campo de alias tecnológico)? Preferimos este procedimiento indirecto porque ProvideSourceUnitTech solo surte efecto cuando la unidad está en estado completado. Solo entonces contará como unidad original en el recuento de tecnología. Si usáramos el campo TechAlias, el alias existiría en cualquier estado, incluso en medio de la mutación de la unidad (estado InProgress). En este caso, al mutar una fortaleza en castillo, nos encontraríamos en una zona indefinida: al tener una fortaleza Completed y un castillo InProgress al mismo tiempo, el sistema de recuento tecnológico pensaría que tenemos una fortaleza InProgress, que no es el caso.
• Compatibilidad con «Move to and then Morph»
  • Nuevas banderas de CAbilMorph: RequireAcquiredTarget y RequireAcquiredTargetUnmorph
  • Nuevos campos de CAbilMorph: Range y TargetSorts
    • Al establecer estos campos, una unidad buscará en su radio de lanzamiento automático un objetivo que se corresponda con el validador y se desplazará hacia él. La unidad comenzará a mutar al llegar a la unidad objetivo. El campo Range indica la máxima distancia a la que puede empezar a mutar el lanzador.

Unidades para mejorar el rendimiento

• Nueva bandera de unidad: NeverThink
  • Normalmente, cada unidad del juego comprueba el trazado de ruta, la búsqueda de enemigos, la adquisición de habilidades y otras muchas cosas en cada bucle de partida (0,0625 segundos). Esta bandera las libera de dichos chequeos, lo que puede mejorar el rendimiento en mapas personalizados. Las unidades con NeverThink no pueden tener comportamientos ni habilidades, con la única excepción de comportamientos de recursos.

Otros cambios genéricos de unidades

• Velocidad máxima de la unidad
  • Nuevo campo de CUnit: SpeedMaximum
    • Especifica la velocidad máxima que puede alcanzar una unidad incluso si recibe bonificaciones de velocidad.
  • Nuevo campo de comportamiento: MoveSpeedBaseMaximumBonus
    • Se usa para cambiar la velocidad máxima de una unidad.
• Nuevo tipo de unidad en CUnit: Warcraft
  • Ahora en el campo Mob se puede seleccionar el tipo «Warcraft».
  • Esto permite a los activadores distinguir entre unidades de Warcraft y de StarCraft.
• Nuevos campos de CUnit: LifeRegenRateNight, EnergyRegenRateNight y ShieldRegenRateNight
  • Se pueden usar para que los elfos de la noche regeneren de noche sin tener que usar un comportamiento para cada unidad.
• Nuevo campo de CUnit: BuildTime
  • Otro sitio para almacenar un tiempo de construcción en los datos de las unidades, que se puede usar para configurar los tiempos de construcción en CAbilBuild, CAbilTrain y CAbilMorph.
  • Nueva bandera de CAbilBuild y CAbilTrain: IgnoreUnitBuildTime
    • Si no se activa, se sumará el tiempo de construcción de una unidad al de la habilidad.
  • Nueva bandera de selección CAbilMorph para cada fase de cada sección: UseBuildTimeArray
    • Por cada fase con esta bandera activada, se añadirá el tiempo de construcción de la unidad a la duración de la fase.
• Nuevo validador: CValidatorUnitCompareAbilStage
  • Permite validar una fase de habilidad de CAbilEffect.
  • Si el valor del campo Ability es None, validará la fase de cualquier habilidad que esté lanzando. Esto significa que ahora los usuarios pueden comprobar si una unidad está canalizando al lanzar una habilidad.
• Nuevos filtros de objetivo:
  • Powerup: Con valor True cuando el valor del campo CUnit_PowerupEffect es válido.
  • PowerupOrItem: Un potenciador o un objeto.
  • HeroUnit: Una unidad con una bandera de héroe. Es diferente de «Heroic», que es un atributo.
• Nuevo campo de CUnit: Unit Level
  • Cuando su valor es > 0, si una unidad está resaltada, aparece el nivel bajo el nombre de la unidad en la descripción.
  • Este campo se puede usar para clasificar o validar objetivos. También se puede usar en acumuladores.
• Comportamiento principal de addon
  • Nuevo campo de CUnit: ParentBehaviorLink
    • Cuando se vincula un addon a un edificio principal, se aplica a este último el comportamiento de ParentBehaviorLink. El lanzador del comportamiento es el addon, no el edificio principal.
    • Esto permite al comportamiento de ParentBehaviorLink controlar el edificio principal en función del estado del addon.
    • Las habilidades de mutación pueden validar este comportamiento para que genere un mensaje de error cuando el edificio principal reciba un comando de despegue mientras el addon acoplado investiga.
• Ahora se puede mejorar CUnit_LifeDamageGain.
• Ahora CValidatorUnitState puede comprobar hasta 100 estados de unidades distintos, en lugar de solo 1.
  • Ejemplos: Idle, Jumping, Highlighted, ArmorDisabled, Revivable, Dying, ArmySelect, etc.

Otros cambios en el sistema de habilidades

• Generación automática de botones para las habilidades
  • Para que sea más fácil aplicar habilidades a cualquier unidad, ahora todos los botones tienen una propiedad que permite establecer su posición por defecto y la ID del submenú en el cuadro de mando.
  • Con cualquier habilidad, los creadores de mods pueden establecer si cualquier comando de habilidad generará automáticamente botones de habilidad, de manera que la habilidad funcione en cuanto se aplique a una unidad. Los usuarios ya no tendrán que introducir estos botones e iconos en el cuadro de mando de la unidad de forma manual.
• API de activadores para quitar y poner habilidades a las unidades en tiempo de ejecución
  • Nuevas acciones de API de activadores: Unit Add Ability y Unit Remove Ability
• Configuración de niveles más sencilla
  • Ahora, la mayoría de los tipos de habilidades tienen un campo Levels con el que se puede establecer el nivel máximo. Los creadores de mods pueden combinarlo con el sistema de acumuladores para no tener que implantar 1000 conjuntos de habilidades para aquellas que tienen 1000 niveles.
  • El campo Levels se puede mejorar, lo que permite a los creadores de mods cambiar los niveles máximos de las habilidades en tiempo de ejecución.
  • Si el valor de Levels es 0 (valor por defecto), el sistema de niveles de habilidad funcionará como hasta ahora.
• Nuevo campo de CCharge: TimeDelay
  • Funciona con todas las cargas de habilidades/objetos/comportamientos.
  • Funciona como TimeStart, pero solo afecta a la primera carga de habilidad, objeto o comportamiento.
  • Si TimeDelay = 0, el sistema de cargas funciona como antes.
  • Si TimeDelay > 0, se ignora TimeStart.
  • Cuando la habilidad comienza a almacenar cargas, el tiempo de regeneración de la primera usa el valor de TimeDelay, y las cargas posteriores, el de TimeUse.
  • Nueva bandera: IgnoreTimeDelay
    • Permite a las habilidades ignorar el valor establecido para TimeDelay en la unidad y usar el suyo.
• El reemplazo de catálogo ahora es compatible con habilidades de objeto.
  • El reemplazo no se basa en el propietario del objeto, sino en su usuario.
  • Esto permite que el mismo objeto lo usen distintos jugadores con diferentes efectos.
    • Por ejemplo, los creadores de mods podrán crear diferentes unidades al usar un objeto en función de la raza del jugador.
• Ahora SEffectParamsShared tiene un miembro m_level, que guarda el nivel de la habilidad que inició el árbol de efectos.
  • Los árboles de efectos pueden usarlo a modo de instantánea para obtener datos de nivel relacionados, de manera que, aunque una habilidad cambie de nivel después de que comience el árbol de efectos, este siga recordando el antiguo.
  • Los acumuladores también pueden usar estos datos como datos de habilidad.
• Ahora se puede configurar CEffectCreateUnit_SpawnUnit para que cree distintos tipos de unidades en función del nivel del árbol de efectos.
• Ahora CAbilBehavior puede establecer diferentes validadores para Auto Toggle On y Auto Toggle Off en lugar de tener uno solo para lanzamiento automático.
• Nuevas categorías de habilidades y comportamientos
  • Se han añadido varias categorías de habilidades y beneficios.
  • Ahora los comportamientos de beneficios pueden activar y desactivar habilidades por categorías.
• Nuevo campo para todas las habilidades: State Behavior
  • Este campo crea un comportamiento cuando se crea una habilidad, lo destruye cuando se destruye y lo habilita o deshabilita cuando se habilita o deshabilita.

Otros cambios en el sistema de daño

• Nuevo campo de CEffectDamage: DamageInheritEffect
  • El efecto establecido en este campo se ejecutará después de aplicar el daño principal.
  • Hereda la cantidad del daño principal.
• Nueva bandera de CEffectDamage: NoZeroDamageInherit
  • Indica a DamageInheritEffect que no debe aplicarse cuando el daño infligido sea 0.
• Nuevo CEffectDamage: Fraction
  • Una fracción extra que se multiplicará a todas las demás fracciones.
  • Este campo es compatible con acumuladores, así que los creadores de mods podrán realizar fórmulas basadas en esta fracción.

Efecto previo de las armas

• Nuevo campo para las armas: PreEffect
  • Se trata de una versión de efecto de PreEffectBehavior que permite usar la validación en el objetivo para determinar si se debe ejecutar PreEffect.

Compatibilidad con interrupción homogénea

• Nueva bandera de CAbilEffect: HomogenousInterrupt
  • Cuando se active esta bandera, los usuarios verán el siguiente comportamiento: si un jugador selecciona una unidad que esté canalizando un hechizo y le ordena que se mueva, la unidad detendrá la canalización y se moverá. Si selecciona más de una unidad y al menos una de ellas no está canalizando un hechizo, solo las que no lo estén haciendo se moverán al instante. En este caso, la orden de movimiento quedará en cola para todas las unidades que están canalizando.
  • Si se desactiva esta bandera, las unidades utilizarán el antiguo comportamiento de SC2.

Cambios en el sistema de construcción de edificios

• Los obreros dan espacio a las construcciones
  • Si se activan las banderas HomogenousInterrupt y Interrupt en un CAbilBuild que no hace que desaparezcan los obreros durante la construcción, los obreros no bloquearán la colocación de otros edificios en la fase correspondiente. Lo que harán será apartarse y luego volver a buscar un sitio mejor para reanudar la construcción.
• Escalado automático del tiempo de animación de aparición de los edificios
  • Ahora CAbilBuildable enviará eventos Start, Cancel, Complete, Pause y Resume al sistema de actores.
  • Además, los eventos de inicio contendrán el tiempo de construcción del edificio. Los actores igualarán automáticamente la duración de la animación de construcción con el tiempo de construcción. De este modo, los edificios terminarán sus animaciones de aparición en cuanto lo haga la construcción.

Compatibilidad con cursor de AdE al atacar el terreno

• Esta característica comprende estos dos cambios del código:
  • Ahora CActorMsgAbil lleva los datos CMD para que los creadores de mods puedan usar CActorTermAbilCmd para responder a CActorMsgAbil. De este modo, el sistema de actores podrá saber si el modo del cursor se activa mediante un ataque normal o una guía de ataque contra el terreno a través de cmdIndex.
  • Ahora CAbilAttack pasa DisplayEffect al sistema de actores como efecto de cursor. De este modo, este sistema podrá filtrar los objetivos y adaptar la escala del cursor de AdE.
    • Si una unidad cuenta con varias armas, el cursor usará el primer DisplayEffect válido de las armas para decidir qué imagen se usa.

Sistema de mantenimiento

• Nuevo campo de raza: UpkeepTax
  • Permite a los creadores de mods personalizar el ritmo de obtención de recursos de un jugador en función de la cantidad de comida que tenga.

Construcción en rampas

• Hasta ahora, los jugadores de SC2 nunca podían construir en rampas porque el motor estaba así programado.
• Nuevo campo de datos de tipos de terreno: Ramp No Build
  • Permite a los usuarios determinar si las rampas se pintarán siempre como Unbuildable (terreno en el que no se puede construir).
  • Si se desactiva, se podrá construir sobre las rampas.

Mejoras en habilidades de recolección

• Nuevo campo de CAbilHarvest: ResourceAmountCapacity
  • Su valor por defecto es 0.
  • Cada vez que un obrero termina de recolectar recursos, compara la cantidad que lleva con el valor de ResourceAmountCapacity. Si es inferior a este, intentará seguir recolectando hasta llegar a la cantidad esperada, salvo que reciba otra orden o se le indique que cambie de posición.
  • Aunque un obrero no haya llegado a la cantidad esperada de recursos, el jugador podrá ordenarle que pare y entregue los que ya haya extraído.
  • Si se ordena a un obrero que cumpla otra tarea mientras está recolectando, intentará recolectar una vez más antes de cumplir la orden.
  • Si un obrero intenta seguir recolectando, pero el recurso en cuestión se ha agotado, intentará encontrar otra fuente del mismo cerca.
• Nueva bandera de CabilHavrest: No Extract
  • Cuando está activada, la habilidad de recolección no reducirá la cantidad de recursos de los nodos, pero el jugador los obtendrá igualmente.

Mejoras en el sistema de hora del día

• Nuevo evento activador para capturar cambios de día y noche: Game Day/Night State Change
• Nueva función activadora para obtener o establecer la hora del día con un valor fijo: Set Time Of Day (Seconds) y Current Time Of Day (Seconds)
• Nueva función activadora para hacerse con el estado actual de día o noche: Current Day/Night State
• Nuevo validador para el valor de la hora del día: Game Compare Time Of Day

Compatibilidad de actores para soltar recursos

• Nuevo mensaje de actor: UnitResourceDrop
  • Este evento de actor publica cada vez que una unidad deja un recurso en un concejo (o cualquier otro punto de entrega de recursos).
  • El campo del nombre de la fuente es el actor de unidad de la unidad que ha dejado el recurso.
  • El campo del subnombre es el tipo de recurso. Los creadores de mods podrán diferenciar los recursos entregados con él.
  • Mediante los mensajes de SetTextLocalized y SetText se puede hacer que aparezca automáticamente la cantidad de recursos entregados en el texto objetivo después del evento.
  • La cantidad entregada reemplazará a la variable %AMOUNT% en el texto objetivo.

Creación de varias copias de un mismo actor

• Nuevo tipo de actor: CActorBatch
  • Así se resuelve un problema que impedía a los usuarios repetir la creación de un actor.
  • Este actor tiene un campo Count que se puede usar para crear copias del mismo actor asociado.
  • Por defecto, el actor creado usa la marcación de CActorBatch.

Compatibilidad con ejecución forzada de bucles en el sistema de actores

• Ahora el sistema de actores es compatible con la ejecución forzada de animaciones en bucle.
• Nueva bandera de EAnimsFlags: ForceLooping
  • Si se activan tanto esta bandera como PlayForever, el sistema ejecutará una variación elegida al azar de la animación cada vez que se complete la animación, con independencia de que esté programada en bucle.
  • Prioridad de banderas: AssetDrivenLooping > ForceLooping > NonLooping
• Nueva bandera de EAnimBracketStartFlag: ContentForceLooping
  • Si se activa esta bandera y se desactiva ContentPlayOnce, el sistema ejecutará una variación elegida al azar de la animación cada vez que se complete la animación hasta que se envíe un mensaje de AnimBracketStop, con independencia de que esté programada en bucle o no.

Mejoras tácticas (IA)

• Nuevo campo de CUnit: AIExecuteAbilTactical
  • Permite que la asociación de IA funcione con un patrón: Unit, galaxyFuncName, scanned group, inAbility, inItem.
• Se ha corregido una incongruencia entre los datos tácticos y la función táctica que impedía que esta última funcionara con jugadores de la IA hostiles y neutrales.

Compatibilidad con recursos personalizados y terrazine (IA)

• Se ha mejorado la IA de Synapse, que ahora comprende que el terrazine y los recursos personalizados son también recursos y, por tanto, puede recolectarlos.

Revivir en altar (IA)

• Ahora la IA puede interpretar una orden de almacenar como una orden de revivir a un héroe si no encuentra otra forma de entrenar a un tipo de héroe concreto.
• El script de IA debe registrar los edificios para revivir a través de AIReqAddSpecialMaker(), como hace con las habilidades nucleares.
• Cuando la IA intente almacenar a un héroe y no pueda encontrar la habilidad de entrenar, buscará en la lista de revivir y tratará de revivir un héroe del mismo tipo.

Sustitución de almacenamiento (IA)

• Ahora la IA tiene en cuenta la sustitución de catálogo al tratar de construir o entrenar.
• Por ejemplo, si un jugador de la IA sustituye un soldado por un fanático, la IA se dará cuenta de que la habilidad de entrenamiento del soldado es la del fanático y podrá emitir la orden de entrenamiento correctamente.
• Esto afecta también a fusionar, construir, investigar, entrenar y entrenar invocar.
• Nueva bandera de unidades: AIPreplacedForceBully
  • Cuando se coloque en un mapa a esta unidad, el sistema la considerará un bully reemplazable aunque no pueda sustituirla. Esto permite que el sistema utilice habilidades obtenidas a través de la acción activadora Replace Ability para sustituir bullies.

Mejora del conversor de mapas clásicos

• Se ha mejorado el conversor de mapas clásicos. Al convertir mapas de Warcraft III, no solo convertirá la malla del terreno, sino también sus texturas del terreno, las unidades colocadas, los adornos, los elementos destructibles, las cámaras y las regiones.

Sistema de botín basado en datos

• Se han añadido nuevas funciones nativas a Galaxy: UnitLootDropUnit y UnitLootDropPoint
  • Los creadores de mods pueden configurar el botín en el editor de datos del botín y luego usar estas funciones nativas para generarlo. El botín puede ser un objeto, una unidad, un efecto o incluso un objeto aleatorio de nivel X/de X clases de objeto, etc.
• Nuevas funciones nativas: UnitLootLastCreated y UnitLootLastCreatedGroup
  • Los creadores de mods pueden usarlas para hacerse con los objetos de botín que se acaban de generar con UnitLootDropUnit o UnitLootDropPoint.
• Nueva bandera de objeto: IncludeInLootItemPool
  • Cuando está marcada, se incluye un objeto en la lista aleatoria de selección de CLootItem. De este modo, los creadores de mods pueden marcar objetos con la condición «No puede aparecer de forma aleatoria».
• Ahora se puede mejorar CLootItem.ClassArray, y los creadores de mods podrán usar activadores para que el proceso de creación de objetos de diferentes clases sea aleatorio.

Modificador de orden con Ctrl

• Este modificador está desactivado por defecto. Se puede activar y desactivar con la acción activadora UISetCommandAllowed.
• Si se activa, al mantener Ctrl pulsado a la vez que se da una orden, esta se enviará a las unidades del subgrupo resaltado actualmente en lugar de a todas las seleccionadas. Por poner un ejemplo, supongamos que un jugador selecciona un soldado y un fanático, pero resalta solo al primero. Si emite luego una orden de movimiento con el clic derecho al tiempo que mantiene pulsada la tecla Ctrl, la orden solo afectará al soldado.

Otros cambios de propiedades del cuadro de IU

• Se ha añadido una propiedad a CUnitFrame: UseSelectionLeader
  • Otorga a la IU la capacidad de hacerse con la unidad líder de la selección actual (primera unidad del subgrupo activo).
  • Cuando está marcada, CUnitFrame establecerá automáticamente LocalObservedSelectionLeaderUnit() como su unidad. Además, actualizará la propiedad UnitTag para que pueda usar la vinculación de propiedad con otros cuadros.
  • Cuando está marcada, CUnitFrame ignorará todas las vinculaciones de propiedad que asocien UnitTag con otros cuadros porque solo debe reflejar al líder de la selección.
  • Si se desactiva, CUnitFrame se comportará como antes.
• Se ha corregido un error que provocaba que CUnitButton no actualizase su propiedad UnitTag.

Otros cambios en las API de activadores

• Fase de habilidades
  • Ahora CAbilRally puede activar un evento de fase activadora Place cuando se coloca la reunión.
• Hándicap de jugador
  • Ahora el hándicap de jugador puede superar el límite del 100 %.
• Gestión de cargadores de unidades
  • Nueva API de Galaxy: UnitMagazineAssign
    • Añade una unidad existente a un cargador de una unidad.
  • Nueva API de Galaxy: UnitMagazineRemove
    • Quita una unidad existente en un cargador de una unidad.
• Nueva API de estado de jugador: AlwaysShowUnitTooltip
  • Con este estado activado, las descripciones de las unidades del jugador siempre aparecen resaltadas, aunque no estén marcadas como Highlight Tooltipable.
• Nueva API de estado de jugador: GivesBounty
  • Activada por defecto para todos los jugadores. Cuando está activada, las unidades del jugador dan los recursos correspondientes a los enemigos que las destruyen.
• Nueva API de actor: ActorScopeMoveTo
  • Mueve un ámbito de actor a las marcaciones de un actor determinado.
• Nuevo evento activador: Player Spent Vital Event
  • Captura cuándo un jugador ha gastado vital.
  • Puede comprender qué vital se ha gastado y cuánta en la respuesta de evento activador.

Otros cambios en el editor de datos

• Ahora el editor de datos es capaz de encontrar la línea XML correcta cuando un usuario selecciona una entrada de datos por defecto.
• Ahora los vínculos de requisito (const CTechRequirementsGraph*) respetan el reemplazo de las variables XML.
  • Gracias a esto, ahora la mayoría de las habilidades pueden usar variables para que su vínculo de requisito tenga la misma ID de la habilidad.
• Ahora CBehaviorLinkArraynow respeta el reemplazo de las variables XML.
• Ahora las propiedades de animación (CAnimProps) en los mensajes de actor respetan el reemplazo de las variables XML.
• Ya no saltará un mensaje de error al tratar de borrar una propiedad TintColor inexistente.
• Ahora CActorQuad cuenta con banderas que le permiten estirarse automáticamente en función de sus posiciones de lanzamiento e impacto.
• Nuevo tipo de clase de objetivo: CTargetSortValidator
  • Clasifica los objetivos dependiendo de si cumplen los validadores indicados.
• Nueva bandera de comando de órdenes: Attack Once
  • Ahora, al dar una orden de ataque, se puede emitir la orden «Atacar una vez» con banderas de comando de órdenes.
  • Se puede usar la acción activadora Order Set Flags para establecer esta bandera.
• Ahora se pueden mejorar los campos de CEffectOffset con las operaciones Add (añadir), Subtract (sustraer), Multiply (multiplicar) y Divide (dividir), como en un vector en 3D. Hasta ahora solo se podía usar Set (establecer).
• Nueva cinética: CKineticDistance
  • Proyecta la unidad objetivo desde una posición inicial a una distancia determinada en la dirección de la posición original de un parámetro cinético.
• Nuevo campo de CWeapon: DisplayName
  • Se usa para anular el nombre del arma en la descripción.
• Nueva bandera de CEffectModifyUnit: StartingVitals
  • Establece la vida, la energía y los escudos de una unidad en sus vitales iniciales.
• Nueva bandera de CEffectModifyUnit: SetVitals
  • Establece directamente las vitales de una unidad.
• Efectos de sanación para CActorActon
  • Ahora CEffectHeal puede incluir mensajes de ActionParticipantsMessage y ActionCommenceMessage para CActorAction. Esto permite configurar acciones de actor con efectos de sanación.
  • Se ha corregido un error que impedía a CEffectHeal activar el subnombre de la acción de efecto Stop (detener) en el momento correcto.
• Nueva bandera de CValidatorUnitOrderCValidatorUnitOrder: CheckStateOnly
  • Cuando está marcada, este validador solo evalúa si el comando de habilidad está deshabilitado para la unidad, con independencia de que se pueda o no ejecutar el comando por razones como «No hay maná suficiente».
• Nueva bandera de CEffectModifyUnit: ResourceDrop
  • Cuando está marcada, la unidad de impacto suelta al instante el recurso que lleva sin necesidad de volver a un concejo. El jugador propietario lo recibirá.
• Nueva bandera de CEffectEnumArea: UnCreep
  • Cuando está activada, el radio de efecto excluye las criaturas.
• API de valor aleatorio de unidad:
  • Nueva API de activadores que permite establecer, obtener o restablecer el valor aleatorio de una unidad.
  • El valor aleatorio de una unidad determina elementos aleatorios de una unidad como su nombre, sus variaciones, etc.
  • Resulta útil para crear una copia exacta de una unidad.
• Se ha corregido un error relacionado con CEffectSwitch que a veces generaba un mensaje de error equivocado.
• Nueva bandera para habilidades de entrenar: Copy Life Percentage
  • Determina si la unidad entrenada heredará el porcentaje de vida de la unidad entrenadora.
• Nueva bandera para habilidades de entrenar: Bypass Food Restriction
  • Permite que la habilidad evite las restricciones de comida.
• Nueva bandera de habilidades de colocación y construcción: Smart Cast
  • Determina si se puede hacer clic derecho para usar el lanzamiento inteligente de una habilidad.
• Nueva bandera de habilidades de efecto: External Acquire Passenger
  • Permite que las habilidades adquieran unidades dentro de un transporte.
• Se ha corregido un error que provocaba que el validador Unit Weapon Range fallase siempre cuando la unidad estaba bajo un efecto de control mental.
• Nueva bandera de efecto de crear sanador: Continue When Full
  • Determina si el efecto de crear sanador continuará una vez que la vital esté al máximo.
  • Por defecto, está deshabilitada.
• Se ha corregido un error que provocaba que los efectos de crear unidad se activaran en un punto de reunión en lugar de ordenar a las unidades que se desplazaran hasta allí cuando se había establecido el campo Rally Unit.
• Nuevo campo de establecer efecto: RecycleCount
  • Permite que se ejecuten de manera repetida los efectos asociados hasta llegar al recuento del reciclado.
• Nueva bandera de habilidades de efecto: Cancel Reset Auto Cast
  • Determina si se restablece el estado de lanzamiento automático de la habilidad cuando el jugador cancela de forma manual su canalización.
• Nuevo campo del validador Veterancy Level: Result Max Level
  • Comprueba si una unidad ha llegado al nivel máximo de héroe.
• Se ha corregido un error que provocaba que las alertas al revivir no apuntaran a las unidades revividas ni reprodujesen la voz correcta.
• Nueva bandera de establecer efecto: Set Source
  • Establece que el punto o la unidad de origen de los efectos asociados sea el punto o la unidad del objetivo actual.
• Se ha añadido un recuadro de búsqueda al diálogo de lista de comandos de habilidad en el editor de datos.

Correcciones para razas personalizadas

• Ahora, en la lista desplegable de razas de las salas de juego aparecen siempre las razas personalizadas del mapa, en lugar de los terran, los zerg y los protoss.
• El cambio no afecta de momento a los mods de extensión, puesto que, por el momento, no se pueden añadir razas personalizadas a las listas desplegables de razas con estos.
• Se ha corregido un error que podía provocar que fallaran los mapas con razas personalizadas debido a una característica del diseño de la consola.

Compatibilidad con nombres de equipo personalizados

• Ahora el editor de SC2 permite usar nombres de equipos personalizados.
• Los nombres de los equipos pueden ser distintos en función de los modos de juego.
• Para personalizar los nombres de los equipos, id a Mapa/Mod > Variantes de partida.

Ampliación de etiqueta de texto "d time/"

• Se han añadido cinco nuevos Time Types (tipos de tiempo) a la etiqueta de texto Time para mostrar distintos tiempos de juego.
• Al pasar estos nombres en lugar de un número directo, la etiqueta de texto mostrará el tiempo de juego correspondiente.
• Ejemplos:
  • Entrada de texto
    • Tiempo fijo: "d time="9125"/>
    • Tiempo de juego: "d time="GameTime"/>
    • Tiempo de misión: "d time="MissionTime"/>
    • Tiempo de IA: "d time="AITime"/>
    • Fecha: "d time="DateTime"/>
    • Hora del día: "d time="TimeOfDay"/>
  • Texto en pantalla
    • Tiempo fijo: 9125 segundos
    • Tiempo de juego: 11:50
    • Tiempo de misión: 11:50
    • Tiempo de IA: 11:50
    • Fecha: 2020:06:12:12:12:23
    • Hora del día: 22:06:34

Otros cambios de propiedades del cuadro de IU

• Nuevas propiedades de CHeroFrame: HeroTag y Skill Point
  • Muestra la etiqueta de unidad y los puntos de habilidad sin gastar de un héroe.
  • Los creadores de mods pueden usar estas propiedades para personalizar los marcos de sus héroes.

Cambios varios

• Se ha aumentado el valor máximo de foliageCount en el editor de terreno a 10 por celda.
• Se ha corregido un error que hacía aparecer un mensaje de error de color rojo al tratar de revivir a una unidad que hubiera muerto en plena mutación.
• Nuevo campo en datos de GameUI: Suppress Skins In Replay
  • Permite que WCS GameHeart suprima los diseños en las repeticiones.

CORRECCIÓN DE ERRORES

• Se ha corregido un error que provocaba que la primera oleada de ataque se quedara atrapada durante la misión de la campaña de Legacy of the Void «Murmullos de muerte».
• Se ha corregido un error que provocaba que las baterías de escudos no obedeciesen las órdenes de detención en estructuras no defensivas cuando estaba activada la función de lanzamiento automático.
• Ahora el retrato del centro de mando en el diseño de la consola terran de Remastered aparece centrado.
• Se ha corregido un error que provocaba que, en ocasiones, algunos de los adornos del agua apareciesen sobre esta.