Notes de mise à jour pour la version 4.13.0 du RPT de StarCraft II

MISE À JOUR DE L’ÉDITEUR

Nous avons le plaisir de vous annoncer que l’éditeur de cartes de StarCraft II a subi une révision totale !

Depuis la sortie de Wings of Liberty, vous n’avez eu de cesse de nous le dire : l’éditeur devrait être plus facile à utiliser. D’où cette mise à jour, qui n’altère cependant en rien toutes ses possibilités de personnalisation. Nous avons donc intégré des éléments issus de l’éditeur de Warcraft III sans pour autant sacrifier tout ce dont celui de StarCraft II était déjà capable. À vrai dire, nous avons même développé ses capacités.

À tous les créateurs de cartes et de mods : allez-y, plongez-vous dans ce qu’il a à vous offrir et envoyez-nous vos commentaires, car nous sommes toujours à la recherche d’améliorations à lui apporter. Il s’agit de la plus grande mise à jour que nous ayons jamais apportée à l’éditeur, et nous sommes impatients de savoir ce que vous en pensez ! Vous trouverez ci-dessous un aperçu de certaines des nouveautés les plus excitantes.

Avant de commencer : Veuillez ne pas oublier de sauvegarder vos cartes avant de les essayer sur le RPT, car ce dernier se veut expérimental.

Collection de données

• Les collections de données sont un nouveau type de catalogue qui permet à l’utilisateur de déclarer et regrouper un ensemble de données au sein d’une même collection. Cette dernière est considérée comme n’importe quelle autre donnée unique (unité, capacité ou amélioration).
• En cas de copie, de changement de nom ou de suppression d’une collection, l’éditeur appliquera cette action à toutes les données de ladite collection. Par exemple, si vous copiez une collection de données, il vous sera demandé d’indiquer un nom pour la nouvelle collection. L’éditeur dupliquera alors toutes les entrées de données de la collection d’origine et les nommera en conséquence. Il fera également en sorte que tous les champs de liens soient conservés et adaptés à la nouvelle collection.

  

• Exemple : copie de la collection Blizzard afin de créer une nouvelle collection de données nommée « Activision Blizzard ».
• Supprimer une collection de données supprimera toutes les entrées de données qu’elle contient.
• Changer l’ID d’une collection de données modifiera également l’ID de toutes les entrées de données qu’elle contient.
• Les entrées de données d’une collection peuvent être renseignées manuellement ou remplies automatiquement.
• Pour nommer les entrées de données enfant, les collections de données utilisent un nouveau caractère, « @ ». Le système de collection peut chercher automatiquement dans le catalogue toutes les données dont l’ID commence par celui de la collection et est suivi d’un « @ ». Il les ajoute alors automatiquement à la collection.
• Ce lien permet, en cas de modification de l’arbre d’effets d’une compétence, la mise à jour automatique de la collection correspondante et de toutes les entrées de données qu’elle contient.
• Voici un échantillon de données parmi une collection automatique :

  

  • Les données non concernées par cette conversion nominale ne seront donc pas ajoutées automatiquement, mais pourront néanmoins être ajoutées manuellement aux collections.
• Menu : Collection de données -> Remplir la collection automatiquement permet de chercher automatiquement dans le catalogue toutes les données dont l’ID commence par celui de la collection et est suivi d’un « @ ». Elles sont alors ajoutées automatiquement à la collection correspondante.
• Menu : Collection de données -> Nommer la collection automatiquement permet de renommer les entrées de données de la collection en fonction du nom de cette dernière.
• Les collections de données permettent aussi d’ajouter davantage d’informations de lien entre les entrées de données. Par exemple, grâce aux collections de données, le jeu comprend désormais des informations telles que « quel est l’acteur principal de cette unité ? ».
• De nombreuses autres fonctionnalités apportées par cette mise à jour dépendent des collections de données.
• Les collections de données nécessitent de respecter certaines règles ou bases du codage afin de fonctionner au mieux de leurs capacités :
  • Chaque collection de données doit être aussi autonome que possible.
  • Par exemple, une « collection de capacité » doit toujours fonctionner lorsque vous l’ajoutez à une unité. Ne les codez jamais de façon à ce qu’elles ne marchent qu’avec des unités spécifiques ou bien dotées d’armes bien précises. Voici un cas édifiant : dans l’ancienne base de données de SC2, le Disloqueur avait un passif qui augmentait ses dégâts s’il attaquait après un long moment. Il s’agissait en vérité d’un faux passif : cette fonctionnalité avait été incluse au code de l’arme du Disloqueur. Dans cette nouvelle ère qu’inaugurent les collections de données, nous vous recommandons fortement d’éviter ce genre de bricolages. C’est pourquoi la plupart des nouvelles fonctionnalités décrites ci-dessous ont été créées afin de vous y aider.

« Mode facile » de l’éditeur de données

• Le « Mode facile » de l’éditeur de données est une autre fonctionnalité des collections. Lorsqu’activé, l’éditeur de données affiche chaque collection comme s’il ne s’agissait que d’une seule « donnée de capacité », « donnée d’unité », « donnée d’objet », « donnée d’amélioration », etc. Vous pouvez les copier, les retirer, les supprimer ou les renommer comme vous le feriez avec n’importe quelle entrée de donnée unique.
• Ce mode n’est disponible qu’en vue en tableau. Il affiche les champs de données les plus importants, tels que les données de PV des unités ou de dégâts des capacités.
• Les champs affichés en Mode facile sont totalement personnalisables pour chaque type de collection de données.
• Les créateurs de cartes de SC2 se plaignaient très souvent du fait qu’il était trop compliqué de dupliquer des unités ou des capacités, un problème que ne rencontrent pas les utilisateurs de l’éditeur de War3.
  • C’est pourquoi nous avons introduit les collections de données et le Mode facile.
  • À l’avenir, nous feront en sorte de créer davantage de données basées sur les collections afin que les utilisateurs puissent s’en servir plus facilement.
• Nous encourageons les créateurs de mods à travailler sur leurs propres mods en se servant des collections de données afin de se faciliter la vie. Si vous travaillez sur des mods publics, servez-vous aussi du mode facile afin que les autres créateurs puissent modifier facilement leurs mods.

Accumulateurs

• Les accumulateurs sont une nouvelle fonctionnalité qui permet aux créateurs de cartes de concevoir des formules basées sur divers paramètres de commandes.
• Les valeurs personnalisées d’unité et les paramètres utilisateur sont tolérés comme paramètres d’accumulateurs.
• Les accumulateurs supportent les formules et les tableaux définis par l’utilisateur. Alliés aux validateurs, les accumulateurs permettent aussi de créer des fonctionnalités de cas Switch.
• Par exemple, lorsqu’un accumulateur est utilisé dans un comportement aux niveaux variés et utilisable par plusieurs joueurs, il calculera le résultat pour chaque joueur.
• Les accumulateurs sont très polyvalents et utilisables de bien des manières : dégâts, taux de soin, récupération, réduction des dégâts, coût de capacité, bonus d’armure, nombre de lots d’acteurs, nombre de persistances, nombre de comportements, durée de comportement, fraction de dégâts, vitesse d’attaque, vitesse de déplacement, régénération des signes vitaux, chances de comportement, modification des signes vitaux, etc.
• Nouvel article de code de format : $AccumulatedValue:xxx$
  • Cet article permet de calculer la valeur AccumulatedValue dans l’interface. Par exemple :
    • Cet article permet de calculer la valeur AccumulatedValue dans l’interface. Par exemple :
      • Fait s’abattre « d ref="$AccumulatedValue:Effect,JainaBlizzardPersistent,PeriodCount$"/> » vagues d’éclats de glace. Chaque vague inflige des dégâts aux unités dans la zone.

Réponse joueur

• La Réponse joueur est un nouveau catalogue de données qui permet aux utilisateurs de définir des schémas de réponses lorsqu’il arrive quelque chose au joueur équipé. À l’aide de déclencheurs, les créateurs peuvent équiper certains joueurs de ces schémas de réponse. Leurs unités réagiront alors aux évènements indiqués comme si elles avaient toutes des schémas de réponses aux dégâts.
• Les utilisateurs ont la possibilité de définir des méthodes de priorité et d’échec pour les Réponses joueur.
• Grâce aux Réponses joueur, il n’est plus nécessaire d’appliquer certains comportements à toutes les unités lors de la création de commandants, ce qui améliore grandement les performances du jeu. De plus, puisqu’il suffit d’équiper des réponses lorsque le commandant correspondant réagit, le jeu n’a plus besoin d’analyser constamment les données de prévention de mort de tous les commandants.
• Les Réponses joueurs ne sont plus limitées à « l’unité a subi des dégâts », comme le sont les comportements de réponse aux dégâts. Elles peuvent aussi concerner l’apparition d’un joueur ou d’une unité, ou bien la mort d’une unité, etc.

Barre de statut non segmentée

• Action du déclencheur : IU - Supplanter option joueur permet désormais aux créateurs de cartes de changer le style des barres de statut par défaut afin qu’elles soient plus linéaires et non segmentées, ce qui est utile dans le cas des mods personnalisés nécessitant un affichage plus précis des fractions de signes vitaux.

Mise à jour des données du mod de ressources de War3

• En février 2015, nous avons sorti le mod de ressources de War3. Ce pack ne contenait que des ressources, mais beaucoup de créateurs de mods voulaient apprendre à créer des capacités de RPG semblables à celles de War3 avec l’éditeur de SC2. Cette mise à jour modifiant l’éditeur en profondeur, nous tenons à donner quelques exemples de ces nouvelles fonctionnalités aux créateurs.
• En collaboration avec sa créatrice, nous avons recréé le mod communautaire Renee’s Warcraft III Mod en nous aidant de toutes les nouvelles fonctionnalités de l’éditeur.
• À présent, le mode de ressources officiel de War3 comprend tout un ensemble de données de travail, dont des races, unités, bâtiments et capacités. Nous espérons que ces exemples aideront les créateurs à saisir toutes ces nouveautés.

Déplacement en formation

• StarCraft II permet désormais les déplacements en formation, qui peuvent être activés ou désactivés pour chaque joueur via des déclencheurs.
• Les unités peuvent se déplacer et attaquer en formation carrée, séparées par une distance prédéfinie.
• Actuellement et contrairement à sa version de War3, cette formation ne force pas toutes les unités concernées à conserver la même vitesse de déplacement.
• Les créateurs de mods peuvent modifier cette donnée afin de personnaliser leur comportement.

Trajectoires dans l’eau

• StarCraft II permet désormais les trajectoires dans l’eau !
• Nouveaux types de trajectoires : Eau peu profonde et Eau profonde.
• Nouveaux modes trajectoires : Flottant et Amphibie.
• Les unités terrestres peuvent emprunter les dalles terrestres et d’eau peu profonde.
• Les unités flottantes peuvent emprunter les dalles d’eau peu profonde et d’eau profonde.
• Les unités amphibies peuvent emprunter les dalles terrestres, d’eau peu profonde et d’eau profonde.
• Les unités volantes peuvent aller n’importe où du moment qu’il n’y a pas de bloqueur de trajectoire aérienne.
• Ces deux nouveaux types de trajectoires ne peuvent être appliqués qu’à l’aide de la brosse de trajectoire de l’éditeur de terrain.

Calques de falaises multiples

• StarCraft II permet désormais d’appliquer jusqu’à 15 calques de falaises (au lieu de 3).

Refonte du système d’amélioration

• Il s’agit d’un élément important du système de collection de données ainsi que du nouveau système de commandant.
• L’ancien système d’amélioration ne pouvait pas être autonome, ce qui était en totale contradiction avec l’esprit de la nouvelle collection de données. En effet, les améliorations spécifiaient les capacités ou unités qu’elles affectaient ainsi que leurs effets correspondants.
• Le nouveau système permet aux améliorations d’être bien plus autonomes. Les unités doivent désormais déclarer les améliorations qu’elles utilisent au lieu de laisser ces dernières décider des unités qu’elles affectent. Par exemple, les améliorations ne seront plus implémentées avec la condition « Augmente les PV des Marines de 10 points », mais avec « Augmente la vie de toute unité qui m’utilise de 10 points ».
• Nouveau champ CUpgrade : EffectArrayTemplate
  • Ce champ est similaire à l’ancien EffectArray, à quelques exceptions près :
    • Il est compatible avec deux articles supplémentaires :
      • ^ParamId^ : L’ID de toute collection de données utilisant l’amélioration.
      • ^ParamLevel^ : Le niveau actuel de l’amélioration.
    • Il est compatible avec les références de données et l’arithmétique. Utilisez les crochets « { » et « } » pour écrire des formules, comme vous le feriez dans l’éditeur de texte.
    • Les collections de données encouragent déjà les créateurs de mods à nommer toutes les données concernées d’une façon spécifique, ils pourront donc se servir facilement de ^ParamId^ pour les entrées de données liées à l’unité qui les utilise.
    • Par exemple :
      • EffectArrayTemplate Reference="Effect,^ParamId^@Weapon,Amount" Value="{DataCollection,^ParamId^,UpgradeInfoWeapon.DamagePerLevel+3}"/
      • Cette amélioration augmente les dégâts de l’arme de l’unité concernée du montant obtenu en additionnant le champ UpgradeInfoWeapon.DamagePerLevel de la collection de données de l’unité et 3.
      • Vous pouvez indiquer un nombre fixe dans la colonne des valeurs, comme par exemple Value=”4”.
• Les anciens champs de CUpgrade sont toujours là et n’ont pas changé. Ainsi, toutes les anciennes améliorations fonctionnent encore. Il est tout à fait possible de créer des améliorations à l’ancienne, mais nous ne vous le recommandons pas.
• Compatibilité des améliorations pour toutes les unités
  • Certaines améliorations étant conçues pour affecter « toutes les unités » (ou un certain type d’unités), le champ CUpgrade a désormais une balise qui énumère toutes les unités d’une collection de données.
  • Deux filtres, EnumExcludedUserFlags et EnumRequiredUserFlags, ont été ajoutés au champ CUpgrade pour permettre aux améliorations de n’affecter que certaines unités d’une collection en fonction de leurs balises.
• Nouvelles opérations d’amélioration : AddBaseMultiply et SubtractBaseMultiply
  • Ces opérations modifient le champ de cible en fonction de sa valeur par défaut au lieu de sa valeur actuelle, ce qui est souvent plus utilise que l’opération Multiply. Par exemple, si vous avez 100 niveaux d’une amélioration « augmente les PV des unités de 10% », vous voudrez probablement que cette augmentation se fasse à chaque niveau sur la base d’un nombre fixe plutôt que sur la base du niveau précédent. De plus, l’opération Add/SubtractBaseMultiply est compatible avec les rétrogradations technologiques car elle peut s’annuler à tout moment, contrairement à Multiply.
• Les améliorations peuvent désormais servir à activer ou désactiver certaines unités pour les joueurs.
• Nouveau champ CWeapon : Multiplicateur de taux
  • Possède une valeur par défaut de 1.
  • Quand le jeu tente de déterminer la fréquence d’utilisation d’une arme ou d’un effet CP, il prendra ce multiplicateur en compte.
  • Cette modification vous permet d’améliorer la vitesse des armes via un pourcentage, plutôt que d’avoir à modifier directement leur fréquence d’utilisation.

Système d’orbe (ainsi que Tir multiple et Coup critique)

• Les orbes sont des modificateurs d’attaque de haute importance dans les MOBA.
• Le système de réponse aux dégâts de StarCraft II peut permettre de créer des orbes, mais la réponse aux dégâts et les modificateurs d’attaque sont en réalité très différents.
• La plupart des anciennes capacités de type « orbe » de SC2 ne correspondent pas à la définition traditionnelle des orbes, car elles sont intégrées aux armes concernées et peuvent difficilement être ajoutées et retirées d’autres armes. Ainsi, pour créer un objet « orbe », il serait bien peu pratique d’intégrer ses effets à toutes les armes de héros du jeu.
• Le système d’orbe tel que nous l’avons mis à jour a pour base celui des MOBA, et est compatible avec Tir multiple et Coup critique.
• Un véritable système d’orbe nécessite les fonctionnalités suivantes :
  • La possibilité d’appliquer ses effets aux systèmes d’armes pour chaque attaque.
  • La possibilité de modifier les projectiles.
  • La possibilité d’ajouter des effets spéciaux quand l’arme touche sa cible, comme du feu, du givre, ou bien le déclenchement d’un comportement, etc. Il doit aussi pouvoir appliquer des effets avant et après l’impact.
    • Par exemple, la capacité Flèche noire nécessite que l’orbe applique un affaiblissement à la cible qui ait un effet une fois cette dernière tuée (à savoir, générer un squelette). Si le système n’appliquait ses effets qu’après l’impact, l’unité serait tuée sans qu’un squelette ne soit généré.
    • Un autre exemple : la capacité d’orbe Obus à fragmentation infligeant des dégâts de zone bonus basés sur les dégâts de l’attaque de base, l’effet de zone doit se produire après l’impact afin que les dégâts de l’attaque puissent d’abord être générés.
  • Quand une arme est sur le point d’être utilisée, le modificateur d’attaque de l’orbe doit déjà avoir été appliqué, avant même que l’effet ne commence. Ainsi, les unités peuvent bénéficier d’animations spéciales, comme dans le cas d’un Coup critique.
  • Les orbes doivent pouvoir appliquer des bonus de dégâts d’attaque constants.
  • Les orbes doivent pouvoir valider leurs effets, pour éviter par exemple qu’un Coup critique ne se déclenche sur une unité alliée.
• Nouvelle balise d’effet : MainImpact
  • Lorsqu’activée, cette balise marque un effet comme étant l’effet d’impact principal de l’arbre d’effets d’une arme, de façon à ce que les modificateurs d’attaque puissent savoir quand se déclencher.
• Nouveau type de comportement : CBehaviorAttackModifier
  • Lorsqu’appliqué, les modificateurs s’activent en même temps que l’arme. Il s’applique ainsi à l’arbre d’effets d’attaque tout entier.
  • Le champ Chance détermine le chance d’application du modificateur d’attaque. Le calcul s’effectue pour chaque attaque.
  • Plusieurs modificateurs ajoutés à une unité. Le champ Unique Id permet à l’utilisateur de choisir s’ils peuvent tous fonctionner en même temps. Dans War3, seul un orbe pouvait être actif même si un héros en possédait plusieurs. Cependant, les créateurs de mods apprécieront certainement d’avoir la possibilité d’en faire fonctionner plusieurs en même temps.
  • Le champ Stack Max détermine le nombre de cumuls possibles des bonus de dégâts.
  • Les champs Damage Bonus permettent de déterminer si les bonus sont constants ou variables. Ils sont également compatibles avec les Accumulateurs.
  • Les champs Validator déterminent si les modificateurs s’appliquent à certaines cibles de l’attaque. Par exemple, mieux vaut ne pas activer le Coup critique lorsque vous attaquez vos propres unités.
  • Le champ PreImpactEffect permet d’activer un effet avant l’impact.
  • Le champ DamageInheritEffect permet d’activer un effet après l’impact, appliquant ainsi les dégâts d’impact à l’arbre d’effets consécutif. Ces effets permettent à l’utilisateur de créer un effet comme Chaîne d’éclairs ou de générer des dégâts de zone basés sur les dégâts d’impact.
  • Peut déterminer si l’attaque a des chances de manquer. Se référer à la section Systèmes Manquer/Dévier/Bloquer.
  • La balise Hallucination Visual Only permet de déterminer si le modificateur d’attaque doit appliquer l’effet de l’orbe dans le cas où l’unité attaquante est une Hallucination. Dans un tel cas, mieux vaut ne pas leur permettre d’infliger des dégâts de zone et de générer des Squelettes, mais c’est une possibilité qui pourrait néanmoins intéresser certains créateurs.
    • Avec cette balise, le modificateur d’attaque sera quand même appliqué à l’arbre d’attaque, ce qui permet à l’unité attaquante de simuler une animation de Coup critique et de lancer un projectile modifié. Cependant, l’attaque n’appliquera pas l’effet de l’orbe à l’impact.
  • Les champs MultishotEffect et MultishotSearchPattern permettent aux utilisateurs de lancer un effet Tir multiple sur chaque cible présente dans le schéma de recherche en fonction des validateurs et des calculs de Chance. Si le champ MultishotEffect n’est pas défini, l’attaque reprendra son effet d’origine.
  • Permet également de décider si les cibles d’un Tir multiple peuvent aussi se voir appliquer les effets d’impact.
  • Permet d’activer des armes par index, de manière à ce que les héros dotés d’un orbe puissent utiliser leur arme secrète pour attaquer les unités volantes.
  • Lorsqu’appliqué à une attaque, le Modificateur peut remplir le terme acteur WeaponModifier lors de l’évènement WeaponStart afin que le système acteur puisse lancer différentes animations d’attaques en fonction des modificateurs d’attaque actifs.
  • Possède la balise « IsCritical ». Activée, elle peut marquer l’attaque comme « Critique », ce qui déclenche le message acteur Critique et remplit les messages SetText et SetTextlocalized avec le montant de dégâts, afin que les créateurs puissent générer des textes flottants pour les Coups critiques.
• Nouveau type de capacité : CAbilAttackModifier
  • CBehaviorAttackModifier peut gérer la plupart des capacités d’orbes, mais dans le cas de certaines capacités comme Flèche de feu ou Prêtresse de la lune, le sort d’orbe a besoin d’un shell pour activer et désactiver son lancement automatique.
  • CBehaviorAttackModifier est un shell de CBehaviorAttackModifier qui permet d’ajouter un shell d’attaque manuelle ou automatique à l’orbe.
  • Permet d’appliquer le Coût au modificateur pour qu’à chaque lancement de la capacité d’orbe, celle-ci coûte des ressources ou des points de vie.
  • Possède une propriété de niveau de façon à pouvoir être améliorée par les capacités apprises par un héros.
• Nouveau type d’acteur : CActorActionOverride
  • Permet de supplanter les graphismes du projectile, de l’impact et des dégâts de CActorAction.
  • Possède les champs Damage Model, Impact Model, et Missile Model pour définir les liens des modèles prépondérants.
  • Quand CActorAction est initialisé, l’évènement ActionInitModifier est lancé.
  • CActorActionOverride peut capturer cet évènement et se générer dans le cadre de CActorAction. Il peut alors utiliser ActionOverrideApplyTo pour s’appliquer à CActorActions.
  • CActorAction utilisera les données de CActorActionOverride et supplantera ses modèles d’attaque.

Compatibilité des capacités dynamiques

• Les créateurs de mods peuvent désormais utiliser des déclencheurs pour ajouter ou retirer des capacités aux unités.

Échange de capacités

• Nouvelle fonction : UnitAbilityChangeLink()
  • Cette fonction permet aux utilisateurs de conférer la capacité d’une unité à une autre en conservant ses charges, son temps de recharge et son niveau.
  • Diffère du Remplacement de catalogue car fonctionne par capacité.
  • Nous avons également ajouté un champ Ability Replace pour le Comportement de type Utilisateur d’énergie qui fournit une version de données de cette fonctionnalité.
  • Permet uniquement de conférer des capacités de la même classe CAbil que l’ancienne. Par exemple, une capacité ciblée ne peut être remplacée que par une autre capacité ciblée.
  • La version de données de l’Échange de capacités affecte également les capacités qu’apprennent les héros.

Passage des Références Bât. dans l’interface graphique des Déclencheurs

• Les actions et fonctions des déclencheurs peuvent désormais utiliser des types d’Enregistrements comme paramètres.
• Les variables d’enregistrement peuvent désormais de paramètres de référence aux fonctions et actions.
• Les paramètres d’enregistrement sont lisibles et modifiables. Les modifications affectent la variable d’enregistrement en dehors du cadre de la fonction.

Nouvelles API de déclencheurs : Instance de tableau de données

• Fonctionne de la même manière que les tableaux de données, sauf qu’il est possible d’avoir plusieurs instances, de compter leurs valeurs et de copier ces dernières entre les tableaux de données.
• L’ancien tableau de données est un unique tableau général. L’ajout d’une version instanciée permet aux concepteurs de mieux organiser leurs données d’exécution.

Supplanter les encadrés d’aide d’objets ou de capacité pour chaque unité/objet

• Nouvelles fonctions natives : UnitSetInfoButtonTooltip, UnitClearInfoButtonTooltip
• Ceci permet à l’utilisateur de supplanter les encadrés d’aide des boutons de commande.
• L’action de déclencheur « définie » nécessite trois paramètres : la modification de l’unité ou de l’objet, la clé de modification et le texte de l’encadré d’aide souhaité.
• La clé de modification tolère trois formats différents, ce qui permet de personnaliser les encadrés d’aide de commande de trois façons :
  • Supplantation des encadrés d’aide de commande via AbilCmd.
    • Avec comme clé AbilCmd, par exemple « Stimpack,0 »
  • Supplantation des encadrés d’aide de commande via le lien du bouton.
  • Avec comme clé l’ID du bouton, par exemple Marine
  • Supplantation des encadrés d’aide d’objets de l’unité elle-même
    • Dans ce cas de figure, la clé sera « @ ».
• Fonctionne même si le panneau de commande est supplanté pour afficher ceux des autres unités.

Prise en charge des skillshots

• StarCraft II prend désormais les skillshots en charge !
• Nouveau champ de balises d’effet de lancement de projectile : SearchFlags
  • Nouvelle balise de recherche d’effet de lancement de projectile : DynamicSearchArea
    • Permet la recherche de skillshots. Sans cela, le projectile sera normal.
  • Nouvelle balise de recherche d’effet de lancement de projectile : ArriveOnSearchHit
    • Définit si le projectile s’arrête lorsqu’il atteint une cible, ou s’il s’agit d’un projectile perforant. Voir ci-dessous.
• Nouveaux champs d’effet de lancement de projectile :
  • SearchHitArriveEffect
    • Ne fonctionne que lorsque ArriveOnSearchHit est activé. Cet effet s’exécute lorsque le projectile explose en touchant une cible.
    • Note : cet effet s’exécute au point de recherche final avant la disparition du projectile, pas au point ciblé. Cette fonctionnalité est similaire à un effet final.
  • SearchEffect
    • Le projectile exécutera cet effet à chaque cycle de jeu en supplantant le paramètre de hauteur dans la zone de recherche en fonction de sa vitesse. Il n’y aura pas d’intervalle entre chaque recherche.
    • Remarque : la triche TVE affichera une hauteur par défaut erronée au lieu de la bonne hauteur de l’effet de recherche de supplantation.
  • SearchMaxCount
    • Indique le nombre de recherches maximum pendant tout le trajet du projectile, et non le nombre de recherches maximum de chacune des recherches. Le projectile arrêtera sa recherche après avoir trouvé SearchMaxCount cibles.
    • Si SearchMaxCount est atteint et que ArriveOnSearchHit n’est pas défini, le projectile continuera sa route jusqu’à destination mais n’exécutera plus de recherches de skillshot.
    • Si SearchMaxCount est atteint et que ArriveOnSearchHit est défini, le projectile explosera et exécutera SearchHitArriveEffect à son dernier point de recherche. Veuillez noter qu’il ne s’agit pas de la cible du projectile, car il ne l’aura pas atteinte.
    • Si SearchMaxCount = 0 et que ArriveOnSearchHit est défini, le projectile ne limitera pas le nombre maximum de recherches. Du moment que l’un de ses effets de recherche trouve une cible, il explosera et exécutera SearchHitArriveEffect à son dernier point de recherche.

Système de héros amélioré

• Nouvelle classe CUnit : CUnitHero
• Cinq nouveaux champs (par rapport à CUnit) :
  • MainAttribute :
    • Un seul lien de comportement appliqué/non-appliqué automatiquement lors de la création/transformation de l’unité.
    • Similaire à un champ de comportement normal. Cependant, le fait de l’utiliser en tant que champ unique lui permet d’être lu facilement via une fonction de catalogue afin de déterminer l’attribut principal d’un héros.
  • MainAttributeDamageBonus
    • Ce champ définit le montant de bonus de dégâts d’attaque dont bénéficie un héros par point de MainAttribute.
  • AttributePointsInfoArray :
    • Définit les points d’attribut de départ et par niveau d’un héros en fonction de son niveau actuel. Définit uniquement les points d’attribut et n’applique pas son comportement si le héros n’en possède pas.
  • LearnInfoArray :
    • Utilise la même structure que CAbilLearn_LearnInfo. Si un indice définit un lien de capacité, il supplantera l’information correspondante de la capacité apprise par le héros. Ainsi, vous n’aurez plus à créer des capacités apprenables distinctes pour les différents héros.
    • Le bouton de commande de Learn Info peut aussi être généré lorsque que la balise « Créer bouton par défaut » est définie.
  • TierRequirements
    • Ce champ supplante le prérequis technologique de CAbilTrain lorsque la capacité est utilisée pour entraîner l’unité héroïque actuelle et qu’il existe déjà plus d’un exemplaire des Alias techno. de ladite unité pour le joueur.
• Nouvelle balise pour CAbilityRevive : Override Alert Icon
  • Quand un joueur ranime un héros avec une capacité CAbilRevive dotée de Override Alert Icon, la capacité utilisera l’icône de CAbilRevive comme icône d’alerte plutôt que celle de l’unité héroïque.
• Ajout de nouvelles fonctions natives :
  • TechTreeSetProduceCap
  • TechTreeGetProduceCap
    • Ces fonctions peuvent, via des déclencheurs, définir une limite technologique basée sur des unités, améliorations, capacités, comportements ou effets.
    • Permet aussi de personnaliser la limite d’entraînement des héros.
• Points d’attribut de base et Points d’attribut bonus
  • Les comportements d’attribut pour CHeroUnit ont désormais deux valeurs de point différentes : la valeur de base et la valeur bonus.
  • Les points d’attribut de base et par niveau d’un héros (configurés dans AttributePointsInfoArray) comptent comme la valeur de base, tandis que les autres modifications de points tels que les bonus de comportement sont comptabilisés dans la valeur bonus.
  • Dans le panneau d’information de l’unité, les points d’attribut de base seront affichés en blanc tandis que les points bonus le seront en vert et précédés d’un « + ».
  • Les bonus conférés par les points d’attribut de base ne sont plus affichés en vert et précédés d’un « + ». Ils sont désormais ajoutés aux champs de dégâts d’attaque, d’armure, et de vitesse d’attaque de basse.
  • Les attributs conférés par des bonus ou objets sont toujours affichés en vert et précédés d’un « + ».
  • Nouvelles balises CEffectApplyBehavior :
    • SetAttributePoints : Quand cette balise est activée, l’effet définit des points d’attribut pour le comportement d’attribut.
    • SetAttributeBasePoints : Quand cette balise est activée, les points de base sont modifiés au lieu des points bonus.
• Ajout d’un nouveau champ CabilTrain : IgnoreUnitCostRequirements
  • Lorsque définie, la capacité d’entraînement ignore les coûts d’unité du moment que les prérequis technologiques sont remplis.
  • Permet d’implémenter des mécaniques de jeu spéciales, comme la gratuité du premier héros.
• Améliorations du sous-menu d’apprentissage de compétences
  • Nouvelle balise d’apprentissage de compétences : ClearSubmenuOnPointsSpent
    • Lorsque définie, toute unité qui utilise cette capacité verra le sous-menu de son panneau de commande fermé une fois tous ses points de compétence dépensés.
  • Nouvelle balise d’apprentissage de compétences : HideSubmenuOnLearnedAll
    • Lorsque définie, le bouton du sous-menu d’apprentissage de compétences disparaîtra lorsque l’unité concernée aura appris toutes les capacités possibles.
  • Correction d’un problème à cause duquel le bouton d’apprentissage de compétence affichait « Niveau requis : » en rouge lorsque tous les points de compétences avaient été dépensés, et ce même si l’unité avait déjà atteint le niveau requis.
  • Correction d’un problème qui permettait parfois aux joueurs d’utiliser la touche Maj pour contourner les restrictions de niveau lors de l’apprentissage de compétences.
• Ajout d’un nouveau système de comptage d’unités : QueuedOrBetterOrRevivable
  • Lors du comptage des unités technologiques, les héros en réanimation et pouvant être ranimés sont pris en compte.
  • Ceci est très utile lors de l’implémentation de restrictions quant à l’entraînement des héros. Par exemple, si vous avez la restriction « Impossible d’entraîner plus de 3 héros », mieux vaut ne pas comptabiliser uniquement les héros en vie.
• Niveau de héros et Formule d’EXP
  • Nouveau champ pour CBehaviorVeterancy : Levels
    • Définit le niveau maximum d’un héros.
    • Ce champ peut être amélioré, ce qui permet aux créateurs de changer les niveaux de compétences maximum en cours de partie.
    • Par défaut, ce champ est défini sur 0, ce qui confère au système de niveau son ancien fonctionnement.
  • Nouveaux champs de CBehaviorVeterancy :
    • MinVeterancyXPBonusPerLevel
    • MinVeterancyXPPreviousValueFactor
    • MinVeterancyXPLevelFactor
    • Si la taille de VeterancyLevelArray est inférieure à la valeur du champ Levels, le jeu générera automatiquement « l’EXP minimum » des niveaux supplémentaires en fonction de ces facteurs.
    • Voici la formule utilisée (X représente le niveau, et F(X) l’EXP minimum dudit niveau) :
      • F(X) = F(X-1) * MinVeterancyXPPreviousValueFactor + MinVeterancyXPLevelFactor * X + MinVeterancyXPBonusPerLevel
    • Ce système est uniquement utilisé lorsque que le niveau X est supérieur à la taille de VeterancyLevelArray. Sinon, il trouvera directement l’EXP minimum dans le tableau VeterancyLevelArray.
• Fraction d’EXP reçue en fonction du type de cible
  • Nouveau champ pour CBehaviorVeterancy : XPReceiveFraction
    • Ce champ est une matrice structurelle qui permet à l’utilisateur de spécifier un filtre de cibles ainsi qu’une valeur fractionnelle cumulable pour chaque matrice.
    • Quand un héros reçoit de l’EXP, le jeu compare l’unité ennemie aux filtres de cibles et applique la fraction d’EXP correspondante si la victime correspond à l’un d’eux.
    • En combinant cette fonctionnalité aux Accumulateurs, l’utilisateur pourra facilement créer des formules d’EXP telles que « les unités invoquées confèrent moitié moins d’EXP » ou « les monstres confèrent moins d’EXP aux héros en fonction du niveau actuel de ces derniers ».
• Ajout d’un nouveau validateur : CValidatorUnitCompareAbilSkillPoint
  • Vérifie les points de compétence dépensés par une unité, ceux qu’il lui reste, ses points supplémentaires, ou son total de points de compétence.

Améliorations du système d’inventaire et d’objets

• Les systèmes d’objets sont primordiaux dans les jeux de rôle, aussi avons-nous amélioré les possibilités de l’éditeur en ce qui les concerne.
• Prise en charge de la construction via des objets
  • Les objets présents dans l’inventaire d’une unité peuvent désormais servir à construire des bâtiments.
  • Cette capacité d’objet peut-être réglée afin de nécessiter une canalisation de la part du héros. Il est aussi possible de permettre aux joueurs de « transférer » des bâtiments, comme chez les Protoss.
  • Ce type d’objets peut permettre de bâtir des extensions plus facilement. Le héros peut par exemple acheter un Bâtiment principal portable et le placer sur une nouvelle extension. Il se construirait alors automatiquement.
• Montrer l’inventaire des autres joueurs
  • Nouvelle propriété CInventoryPanel : ShowForAllPlayers
    • Cette propriété activée, les joueurs pourront sélectionner les unités des autres joueurs et consulter leurs inventaires (mais pas utiliser les objets qu’ils contiennent).
• Utilisation de capacités sur des objets de l’inventaire
  • CCommandButton affiche désormais la propriété ButtonOtherUnit, qui permet à l’utilisateur d’utiliser le lien de propriété pour lier une unité d’objet (soit l’objet lui-même, pas son porteur) à une image cible ou d’autres images.
  • Ainsi, l’utilisateur pourra lancer des capacités sur des objets présents dans son inventaire pour les transférer ou les améliorer.
  • Cette fonctionnalité permet également à l’utilisateur d’effectuer un double clic sur le Portail de ville pour se téléporter à son Bâtiment principal de plus haut niveau.
• Panneau d’inventaire toujours accessible
  • L’utilisateur peut désormais supplanter la propriété Inventory Unit de CInventoryPanel afin d’afficher l’inventaire d’une unité non sélectionnée.
  • L’utilisateur peut aussi se servir de déclencheurs pour créer de nouvelles commandes de dialogue d’inventaire. Cette manipulation et compatible avec les opérateurs tels que la commande de dialogue du panneau de commande introduite dans Legacy of the Void.
  • L’utilisateur peut définir l’unité en sélectionnant « Use SetDialogItemUnit ». Un réglage nul entraînera le retour à l’unité sélectionnée.
• Afficher l’inventaire de l’acheteur
  • Auparavant, StarCraft II prenait mal en charge les boutiques d’objets neutres comme celles de War3. Avant cette mise à jour, lorsqu’un utilisateur cliquait sur un vendeur, il ne pouvait pas voir l’inventaire de l’unité acheteuse.
  • Désormais, les boutiques neutres affichent l’inventaire de l’acheteur tant qu’elles n’ont pas elles-mêmes d’inventaire et que le panneau d’inventaire n’a pas été supplanté pour afficher celui d’une unité donnée.
• Données de charge pour CUnit
  • Ajout de données de charge aux unités et aux objets de façon à ce que lors de la vente d’objets et d’unités, leurs données puissent définir leur information de Stock par défaut (ce qui permet de lancer des temps de de recharge dans la boutique, de définir les stocks maximum des boutiques, etc).
  • Il est possible de baliser une capacité CAbilTrain afin d’ignorer ces paramètres par défaut et d’utiliser les paramètres personnalisés de ladite capacité.
    • Si la balise n’est pas activée et que la capacité possède ses propres données, les deux instances de données de charge seront prises en compte.
• Objets bonus « véritables »
  • Nouveau type d’objet : CItemAbilPowerUp
  • Il est désormais possible d’implémenter des objets bonus en tant que véritables objets au lieu d’avoir à imiter une unité.
  • CItemAbilPowerUp provient de CItemAbil. Contrairement à ce dernier, il est utilisé automatiquement lorsqu’il est ramassé, et peut l’être même lorsque l’inventaire de l’unité est déjà plein.
  • CItemAbilPowerUp peut uniquement être utilisé par des unités dotées d’un inventaire. Leur balise CanUseItem doit également être activée.
  • Ces nouveaux objets bonus sont de véritables objets, ce qui signifie qu’ils respectent les évènements d’inventaire et sont utilisables au sein du système Loot.
  • CItemAbilPowerUp vérifiera si l’utilisateur peut se servir de la capacité bonus. Dans le cas contraire, il affichera un message d’erreur et ne lancera pas son déplacement jusqu’à l’objet.
  • La balise KillAfterUse permet la destruction de l’objet bonus une fois que l’utilisateur s’en est servi.
  • Une unité normale dotée d’un inventaire mais dont la balise CanUseItem est désactivée pourra ramasser des objets bonus et les apporter à un héros.
• Nouvelle balise pour EAbilInventoryFlag : ItemDropOnDeath
  • Cette balise force une unité à lâcher tous ses objets à sa mort même si elle est réanimable. Cela peut s’avérer utile dans le cas des unités normales dotées de la capacité Sac à dos de Warcraft III.
• Nouvelle balise pour EAbilInventoryFlag : CanUseItem
  • Cette balise permet de définir si une unité peut utiliser des objets ou non. L’utilisateur peut donc s’en servir pour créer des coursiers : des unités dotées d’un inventaire, mais incapables d’utiliser les objets qu’elles transportent.
• Nouvelle balise pour EAbilInventoryFlag : CanApplyEquipBehavior
  • Cette balise permet de définir si une unité peut bénéficier des bonus des objets (Force +5, par exemple). Très utile également pour créer des unités coursiers.
• Nouvelle balise pour CItemAbil : Transient
  • Lorsque cette balise est activée, la capacité d’objet sera forcément lancée en tant que capacité transitoire, même si la capacité d’origine de l’objet n’est pas censée l’être.
• Correction d’un problème à cause duquel les inventaires essayaient de ramasser des objets même si ces derniers étaient détruits à l’approche des unités.
• Correction d’un problème qui empêchait CAbilSpawn de fonctionner.
• Correction d’un problème qui pouvait entraîner la perte de l’objet sans gain de ressources lorsque les joueurs confiaient un objet au magasin en se tenant à la distance maximum.
• Ajout de sous-noms aux évènements d’acteur Abil : PawnSource, PawnTarget.
  • Il s’activent lorsque vous confiez un objet.
• Nouveau champ pour CAbilInventory : Requirements
  • Lorsque définie, la compétence d’inventaire est désactivée jusqu’à ce que les prérequis technologiques soient remplis.
  • L’interface de l’inventaire sera également dissimulée jusqu’à ce que les prérequis soient remplis.
• Nouvelle balise pour CValidatorUnitInventory : RequireEnabled
  • Cette balise activée, le validateur renverra uniquement e_CmdOK si la compétence d’inventaire ciblée est activée et que ses prérequis technologiques sont remplis.
• Pour ce qui est des réponses aux évènements Player Use Effect, un nouveau déclencheur API permet à l’utilisateur de capturer l’objet utilisé pour créer l’effet (si objet il y a) ainsi que son type.
• Les objets de capacité peuvent désormais choisir d’utiliser leurs propres liens de temps de recharge, et ainsi de supplanter le lien hérité de la capacité elle-même.

Prise en charge des boutiques neutres/alliées

• Les boutiques neutres/alliées sont des bâtiments neutres/alliés avec lesquels d’autres joueurs peuvent interagir via les capacités CAbilInteract.
• Pour toutes les capacités, le champ Tech Player possède désormais une option supplémentaire : Caster.
  • Lorsque le champ Tech Player d’une CAbilTrain est défini sur Caster, la capacité vérifiera les prérequis technologiques du joueur ayant donné l’ordre.
  • Cela permet de créer une capacité « vendre l’unité/l’objet en fonction de l’arbre technologique de l’acheteur ».
• Nouveau champ pour CabilTrain : AgentUnitValidator
  • Lorsque ce champ est défini, la capacité ne se lancera jamais sans unité agent et vérifiera les validateurs de ce champ lors de l’entraînement d’unités.
  • Ce champ permet de créer facilement des capacités de « boutiques d’objets » dans SC2.
    • Pour ce qui est des boutiques d’objets, l’utilisateur veut généralement que l’unité acheteuse ait un inventaire afin de pouvoir s’offrir des objets.
    • Auparavant, SC2 ne permettait pas ce genre de choses. Aussi, même si l’unité acheteuse n’avait pas d’inventaire. l’objet était créé systématiquement.
    • Grâce au champ AgentUnitValidator, l’utilisateur peut ajouter des validateurs tels quel "l’unité à un inventaire valide" et "l’inventaire n’est pas plein". Ainsi, si l’unité agent n’a pas d’inventaire. la capacité affichera un message d’erreur et ne se lancera pas.
• Nouvelle balise pour CAbilTrain : ChargeCasterPlayer
  • En principe, les capacités de boutiques neutres nécessitent que les joueurs acheteurs et vendeurs se partagent les dépenses de ressources via la balise « Ally Spending ». Dans le cas contraire, l’acheteur obtiendra un message d’erreur « Dépense impossible sur ce joueur ».
  • Par défaut, les joueurs neutres partagent les coûts avec tous les joueurs. Mais si l’utilisateur veut créer une boutique alliée (dans laquelle les joueurs alliés peuvent acheter des objets ou unités), il ne tient peut-être pas à ce que ces joueurs se partagent les dépenses, car ils pourraient utiliser l’argent de leurs alliés.
  • La nouvelle balise ChargeCasterPlayer a pour but de résoudre ce problème. Lorsqu’activée, seul le joueur ayant initié un achat doit payer l’unité ou l’objet concerné, même si l’acheteur et le vendeur ne se partagent pas les dépenses.
  • Si d’autres joueurs partagent les dépenses avec l’acheteur et que ce dernier n’a pas assez de ressources pour payer son achat, le capacité fera quand même payer ces autres joueurs.
• Nouvelle balise pour CAbilInteract : AlwaysShowCommandCard
  • Quand cette balise est activée, l’unité vendeuse affichera son panneau de commande à tous les joueurs capables d’interagir avec elle (comme le détermine le champ Target Filter de CAbilInteract), même si le joueur n’a pas d’unité agent valide près de la boutique.
  • Ainsi, les joueurs pourront voir les objets en vente même s’ils n’ont pas d’unité agent près de la boutique.
  • Il leur sera cependant impossible d’utiliser le panneau de commande de l’unité vendeuse s’ils ne la contrôlent pas (par exemple, s’ils n’ont aucune unité agent à proximité).
• Correction d’un problème à cause duquel les capacités d’interaction essayaient constamment d’acquérir une unité sans vérifier le champ ValidatorArray.

Système de suivi d’unité de comportement

• Nouveau type de comportement : BehaviorUnitTracker
  • Ce comportement fonctionne comme une liste d’unités. Il emmagasine toutes les unités qui y sont ajoutées et possède des champs de nombre maximum et de validateur. À chaque fois qu’un membre de la liste ne remplit pas le validateur défini, il se voit retiré de ladite liste.
  • Des balises permettent également à l’utilisateur de convertir le traqueur en une liste générale ou une liste joueur, qui ne nécessitent aucune instance de comportement pour fonctionner.
• Nouvel accumulateur : CAccumulatorTrackedUnitCount
  • Permet à l’utilisateur de se servir d’accumulateurs en fonction du nombre d’unités présentes dans une liste donnée.
• Nouveaux effets : CEffectAddTrackedUnit CEffectClearTrackedUnits, CEffectRemoveTrackedUnit
  • Permettent aux utilisateur d’ajouter des unités à une liste ou de les en supprimer.
• Nouvel effet : CEffectEnumTrackedUnits
  • Permet à l’utilisateur de passer en revue la liste de traqueurs d’unités et d’exécuter des effets sur chaque élément en fonction de certains filtres.
• Nouveaux validateurs : CValidatorCompareTrackedUnitsCount, CValidatorIsUnitTracked
  • Permettent de compter le nombre d’unités traquées par le comportement et de vérifier si une unité est présente dans une liste de traqueurs donnée.
• Le système de traqueurs est très utile pour conserver un à plusieurs mappages entre les unités.
  • Par exemple, il peut relier une unité invocatrice aux unités qu’elle a invoquées.

Autres modifications du système de comportement

• Comportement : alias d’empilement
  • Cette fonctionnalité permet aux comportements d’empiler via un « ID d’empilement » plutôt qu’un ID de comportement.
  • Par exemple, dans WC3, l’Archimage et divers monstres possèdent une version de l’aura d’Illumination. Mais ces bonus sont différents, et si vous possédez ces deux types d’unités, vous n’avez peut-être pas envie que les autres unités à proximité bénéficient des deux versions de l’aura. Dans ce genre de cas, c’est l’aura du héros qui doit être favorisée.
  • Deux nouveaux champs de CBehaviorBuff : StackAlias (segment) et StackAliasPriority (entier)
    • Si deux bonus du même StackAlias sont appliqués à la même unité, ils se partageront un même nombre maximum, le plus bas ayant la priorité. Si le total dépasse le nombre maximum partagé, le jeu retirera des cumuls en commençant par le bonus à la valeur de StackAliasPriority la plus basse puis à la durée la plus courte. Ce processus se répète jusqu’à ce que le nombre de cumuls maximum corresponde au nombre de cumuls maximum partagés.
  • Nouvel évènement d’acteur : BehaviorStackAlias
    • Permet à l’utilisateur de capturer des évènements de comportement (Activé, Désactivé, Réponse de dégâts, etc) en fonction du StackAlias de comportement plutôt que de l’ID de comportement.
    • Permet également de partager des acteurs entre les comportements dotés du même StackAlias (en effet, mieux vaut par exemple que toutes les versions de l’aura d’Illumination possèdent la même illustration).
  • Nouveau champ pour CEffectRemoveBehavior : StackAlias
    • Permet à l’utilisateur de retirer des bonus en fonction du StackAlias.
  • Nouveau validateur : CValidatorUnitBehaviorStackAlias
    • Permet à l’utilisateur de compter les cumuls de comportement via leur StackAlias. Il comptera tous les comportements affectant l’unité dotés du StackAlias donné, et peut ne compter que les comportements activés.
• Prise en charge du texte flottant de réponse de dégâts de l’acteur
  • Désormais, lorsque CActorMsgBehavior déclenche un évènement doté d’un sous-nom DamageHandled, le fait d’utiliser des messages SetTextLocalized et SetText après ledit évènement dotera automatiquement ces derniers du montant de dégâts modifié.
  • Les dégâts remplaceront l’article « %AMOUNT% » dans le texte cible.
  • Cette fonctionnalité est très utile pour créer des textes flottants de dégâts pour les réponses de dégâts.
• Prise en charge améliorée des évènements d’acteur de comportement On/Off
  • Les évènements de comportement On/Off définissent désormais des paramètres d’effets pour le dernier cumul appliqué ou retiré.
  • Cela permet de configurer plus précisément les acteurs de comportement. Auparavant, l’utilisateur ne pouvait pas référencer le lanceur d’un comportement dans les évènements de comportement On/Off.
• Nouvel état de comportement : Cannot Die
  • Marque une unité comme « immortelle » jusqu’au retrait du comportement.
  • Si les réponses de dégâts permettent d’obtenir un effet similaire, les réponses de mort peuvent uniquement empêcher les morts dues aux dégâts. Cet état de comportement empêche la mort quelle qu’en soit l’origine.
  • Cet état fournit une alternative simple à un système de prévention de mort basé sur les déclencheurs.
• Nouvel état de comportement : Suppress Kill Credit
  • Empêche une unité de conférer des crédits ou ressources de victime au joueur qui l’a éliminée.
  • Utile lors de la création d’hallucinations.
• Nouveau champ pour CBehaviorBuff : DeathType
  • Peut supplanter le DeathType d’une unité. Ignore le DeathType de l’effet de dégâts mortel.
  • Ne peut pas supplanter le DeathType « Remove ».
  • Sa valeur par défaut est « Unknown », soit « ne pas supplanter ».
• Nouveau DeathType : Reincarnation
  • Empêche les unités de lâcher du butin et des objets à leur mort.
• Le validateur CValidatorUnitCompareBehaviorCount ainsi que les effets CEffectRemoveBehavior et CEffectTransferBehavior partagent désormais les champs de configuration détaillés suivants :
  • BehaviorCategories, BehaviorClass, BehaviorAlignment, ExcludeOriginPlayer, ExcludeCasterUnit, RequireOriginPlayer, RequireCasterUnit
• Auparavant, ces validateurs/effets ne possédaient qu’un unique champ CEffectBehavior. Ces nouveaux champs étaient exclusifs à CEffectBehavior.
• Ces ajouts donnent à l’utilisateur plus de contrôle dans le comptage, le retrait et le transfert de comportements.
• Par exemple, l’utilisateur peut désormais retirer des cumuls de comportement ajoutés par un joueur lanceur d’unités cible, etc.
• Ils facilitent également l’implémentation de « dissipations intelligentes », par exemple pour ne retirer que les bonus appliqués par des unités ennemies.
• Nouveau champ pour CValidatorUnitCompareBehaviorCount, CEffectRemoveBehavior, et CEffectTransferBehavior : Matches All
  • Détermine si l’effet ou le validateur doit être exécuté quand l’un des champs de configuration est validé ou seulement s’ils le sont tous.

Prise en charge améliorée des cadavres

• Nouvelle balise pour CEffectModifyUnit_ModifyFlags : Remove
  • Cette balise permet de retirer directement l’unité du jeu en supprimant son acteur et tout ce qui s’y rapporte.
  • Nous l’avons ajoutée car l’effet « Remove » de CEffectDamage ne permettait pas de retirer un cadavre.
• Nouveau filtre d’unité : Decaying
  • Une unité Decaying est une unité à terre morte depuis un moment. Elle diffère d’une unité morte mais en train de tomber et de générer un cadavre. En des termes plus techniques, il s’agit d’une unité pour laquelle Death Time est actif et Revive Delay est terminé.
  • Le but de ce filtre est d’empêcher les capacités ciblant des cadavres de fonctionner sur des unités qui viennent de mourir et dont le cadavre n’est pas encore généré.
  • Si pour l’unité Death Time est défini sur -1, la phase de décomposition sera ignorée. Par exemple, dans Warcraft III, les héros ne se décomposent jamais.
• Nouveau filtre d’unité : Raiseable
  • CEffectModifyUnit peut désormais définir si un cadavre est Unraiseable.
  • Unraiseable permet de marquer les cadavres ayant déjà été utilisés.
    • Par exemple : si une goule dévore un cadavre, ce dernier est toujours là, mais l’utilisateur n’a peut-être pas envie qu’il soit ranimable ou ramené comme mort-vivant. Auquel cas, il peut régler les capacités pour qu’elles ne fonctionnent que sur les corps marqués comme Raiseable, et définir les corps en train d’être dévorés comme étant Unraiseable.
• Nouvelle balise : Allow Corpse
  • Quand cette balise est activée, les capacités de transport pourront prendre les cadavres en charge.

Systèmes Attack Type, Damage Type et Armor Type

• Nouveau champ pour CWeapon : Attack Type
  • Les créateurs de mods peuvent modifier les multiplicateurs de dégâts de chaque type d’attaque contre chaque type d’armure dans Game Data.
  • Le champ Attack Type affecte tous les effets de dégâts de l’arbre d’une arme, les créateurs peuvent donc désormais modifier directement les multiplicateurs de dégâts d’une arme plutôt que d’intervenir manuellement sur chaque élément de l’arbre d’effets.
• Nouveau champ pour CUnit : Armor Type
  • Le champ Armor Type définit les multiplicateurs de dégâts des armes contre les unités.
• Nouveau validateur : CValidatorUnitArmor
  • Permet à l’utilisateur de vérifier le type d’armure d’une unité.
• Nouveau champ pour CEffectDamage : Damage Type
  • Les créateurs peuvent changer les filtres de ciblage des types de dégâts dans Game Data.
  • L’utilisation des filtres de ciblage avec les types de dégâts permet à l’utilisateur de configurer tous les effets de dégâts (de zone ou non) du jeu. Elle permet aussi de définir si certains effets de dégâts peuvent affecter ou non certaines cibles.
  • Par exemple : rien qu’en excluant les cibles alliées de tous les types de dégâts, l’utilisateur peut facilement empêcher toutes les armes du jeu d’affecter les alliés dans le cas d’effets de zone. Ceci s’avère très utile lors de la création de mods coop, car il aurait sinon fallu ajouter cet aspect-là en plus des autres mods utilisés, d’autant que les armes et sorts de zone de ces autres mods possèdent divers effets de tir allié.

Effets : Chances de rater, blocage et déviation

• Le système de réponse de dégâts de comportement a été étendu pour prendre en charge plus que de simples cas de réponses de dégâts.
• Chances de rater
  • Nouvelle balise pour CWeapon : NeverMiss
    • Par défaut, les armes conservent leur ancien comportement.
  • Les modificateurs d’attaque peuvent aussi ajouter la propriété NeverMiss à l’arbre d’effets d’une arme.
  • Si l’arbre d’effets d’une arme fait qu’elle peut rater son coup, alors au moment du tir, le système vérifiera les Chances de rater de l’attaquant comme du défenseur. Il déterminera alors si l’effet ratera son coup ou non en fonction des validateurs et des chances définies au sein de la structure de réponse.
  • Les unités terrestres qui attaquent des cibles situées en hauteur peuvent subir un malus aux Chances de rater (modifiable dans Game Data).
  • Si l’arbre d’effets d’une arme va échouer, elle n’exécutera pas ses dégâts d’impact ni aucun effet d’orbe.
  • Quand une arme rate son coup, elle enverra un évènement d’arme d’acteur ayant pour sous-nom « Missed ». Ainsi, les créateurs de mods pourront décider de marquer le coup avec un texte flottant « Raté ! » sur l’unité ou en affichant un effet d’évitement.
• Chances de bloquer
  • Nouvel effet CEffect : CanBeBlocked
    • Détermine si l’effet peut être bloqué. Par défaut, est réglé sur Off.
  • Lors de l’exécution d’un effet, le jeu ira chercher la structure de réponse du côté de l’unité impactée et vérifiera ses Chances de bloquer ainsi que d’éventuels validateurs.
  • S’il est bloqué, l’effet est annulé et ne s’exécute pas. Il enverra alors un évènement d’effet d’acteur ayant pour sous-nom « Blocked » afin que l’utilisateur puisse définir des acteurs appropriés.
  • Cette fonctionnalité sert à créer des comportements de blocage de sorts.
• Chances de dévier
  • Nouvelle balise pour CEffect : ValidateImpactDeflection
    • Détermine si l’effet peut être dévié. Par défaut, est réglé sur Off.
  • Quasiment identique aux Chances de bloquer, à ceci près que l’effet qui aurait dû se produire est dupliqué puis renvoyé à l’attaquant.
  • L’effet dévié verra ses propriétés de lanceur et de cible inversées et comptera comme un tir effectué par la cible d’origine contre le lanceur d’origine. Les paramètres de dégâts bonus de l’arbre d’effets resteront les mêmes que ceux du lanceur d’origine.
  • De plus, dans le cas d’une déviation, les arbres d’effets n’évalueront les chances de déviation qu’une seule fois chacun. Si un effet passe la vérification une fois, le reste de l’arbre n’évaluera plus les chances de déviation, même si la balise ValidateImpactDeflection a été activée pour d’autres effets présents dans l’arbre.

Modifications du système de transformation d’unité

• Activation/Désactivation de la transformation
  • Nouvelle balise pour CAbilMorph : Toggle
  • Nouveau champ pour CAbilMorph : InforArrayUnmorph
    • Si la balise Toggle est activée, les capacités de transformation peuvent être utilisées pour passer d’une chaîne de type d’unité à l’autre.
  • Nouvel index de commandes CAbilMorph : Unmorph
    • Dans le cas d’une capacité de transformation avec Toggle, si l’unité s’est déjà transformée, il est toujours possible d’envoyer à la capacité une commande « Unmorph », ce qui lance le processus de transformation tel que défini dans le champ InforArrayUnmorph.
    • Dans la plupart des cas, le champ InforArrayUnmorph doit être défini de façon à ce que le type final de l’unité soit son état normal. Ainsi, elle retrouvera son état normal grâce à la commande Unmorph.
  • Nouveau champ pour CabilMorph : ValidatorArrayUnmorph
    • Valide la possibilité pour une unité transformée d’utiliser la commande Unmorph.
  • Nouvelle balise pour CabilMorph : AutoUnmorph
    • Détermine si l’unité transformée essaiera automatiquement de retrouver son état normal dès que possible.
  • Nouveaux champs de CabilMorph : BehaviorOn/BehaviorOff
    • Une fois ces champs définis, la capacité applique le bonus BehaviorOn à l’unité une fois cette dernière transformée. Le bonus BehaviorOff, lui, est appliqué lorsqu’elle est dans son état normal. Ces deux champs fonctionnent uniquement si la balise Toggle de la capacité de transformation est activée.
  • Même si une unité est directement créée sous sa forme transformée, les capacités de transformation considèrent qu’elle a subi une transformation. Les comportements associés sont alors appliqués et l’unité peut utiliser la commande Unmorph.
• Compte de technologie de transformation
  • Nouvelle balise pour CAbilMorph  : ProvideSourceUnitTech
    • Quad cette balise est activée, CAbilMorph transfère le type d’unité de l’unité source à celle en laquelle elle s’est transformée. L’unité finale hérite automatiquement du lien d’unité de l’unité source en tant qu’Alias technologique.
    • Cette propriété est attribuée tout au long de la chaîne de transformation.
    • Exemple : Hôtel de ville -> Donjon -> Château
    • Un Château compterait à la fois comme un Donjon et un Hôtel de ville, même s’il était directement créé en tant que tel sans avoir subi de transformation.
    • Pourquoi ne pas simplement ajouter l’Hôtel de ville et le Donjon à l’alias du Château (en les incluant au champ de son Alias technologique) ? Tout simplement parce que ProvideSourceUnitTech ne fait effet que lorsque l’unité a terminé sa transformation. C’est seulement à ce moment-là qu’elle est considérée comme l’unité source dans le compte de technologie. Si nous utilisions le champ TechAlias, l’alias existerait quel que soit l’état de l’unité, même au cours de sa transformation (état InProgress). Auquel cas, lors de la transformation d’un Donjon en Château, vous vous trouveriez dans une situation intermédiaire un peu étrange : comme vous auriez en même temps un Donjon terminé (état Completed) et un Château InProgress, le système de compte de technologie croirait à tort que vous auriez un Donjon InProgress.
• Prise en charge de « se déplacer vers puis se transformer »
  • Nouvelles balises CAbilMorph : RequireAcquiredTarget, RequireAcquiredTargetUnmorph
  • Nouveaux champs de CAbilMorph : Range, TargetSorts
    • Quand ces champs sont définis, une unité cherchera son rayon de lancement automatique, essaiera de trouver une cible à portée compatible avec le validateur, puis s’en approchera. L’unité commencera sa transformation une fois l’unité ciblée atteinte. Le champ Range indique la portée maximale à laquelle le lanceur peut commencer à se transformer.

Unités et économies de ressources

• Nouvelle balise d’unité : NeverThink
  • En principe, chaque unité du jeu vérifie sa trajectoire, s’il y a des ennemis à proximité, si elle est la cible de capacités, et tout un tas d’autres choses à chaque cycle de jeu (0,0625 secondes en jeu). Cette balise leur évite d’avoir à faire ces vérifications, ce qui peut améliorer les performances sur les cartes personnalisées. Les unités pour qui elle est activée ne peuvent jouir d’aucun comportement ni aucune capacité, à l’exception des comportements de Ressources.

Autres modifications génériques pour les unités

• Vitesse maximum des unités
  • Nouveau champ pour CUnit : SpeedMaximum
    • Spécifie la vitesse maximum d’une unité, bonus de vitesse compris.
  • Nouveau champ de comportement : MoveSpeedBaseMaximumBonus
    • Permet de changer la vitesse maximum d’une unité.
• Nouveau type de créature CUnit : Warcraft
  • Le champ Mob des unités permet désormais de choisir le type de créature « Warcraft ».
  • Ceci permet aux déclencheurs de différencier les unités de Warcraft des unités de StarCraft
• Nouveaux champs pour CUnit : LifeRegenRateNight, EnergyRegenRateNight, ShieldRegenRateNight
  • Permet notamment aux Elfes de la nuit de se régénérer de nuit sans avoir à créer de comportement pour chaque unité.
• Nouveau champ pour CUnit : BuildTime
  • Un endroit supplémentaire où saisir un temps de construction dans les données d’unité, qui peut ensuite servir à configurer des temps de construction dans CAbilBuild, CAbilTrain, et CAbilMorph.
  • Nouvelle balise pour CAbilBuild et CAbilTrain : IgnoreUnitBuildTime
    • Lorsque cette balise est désactivée, le temps de construction d’une unité est ajouté à celui de la capacité.
  • Nouvelle balise de tableau CAbilMorph pour chaque phase de chaque section : UseBuildTimeArray
    • Chaque phase dont cette balise est activée voit sa durée ajoutée au temps de construction de l’unité.
• Nouveau validateur : CValidatorUnitCompareAbilStage
  • Permet à l’utilisateur de valider un niveau de capacité de CAbilEffect.
  • Si le champ Ability est défini sur None, il valide le niveau de n’importe quelle capacité en cours de lancement. Cela signifie que l’utilisateur peut désormais vérifier si une unité canalise la capacité qu’elle lance.
• Nouveaux filtres de ciblage :
  • Powerup : renvoie vrai si la valeur du champ CUnit_PowerupEffect est valide.
  • PowerupOrItem : un bonus ou un objet.
  • HeroUnit : unités dotées d’une balise Hero. Diffère de « Heroic », qui est un attribut.
• Nouveau champ CUnit  : Unit Level
  • Lorsque ce champ est défini sur > 0, si une unité est surlignée, son encadré d’aide affichera ce niveau sous son nom.
  • Ce champ peut servir à cibler, trier ou valider. Il peut aussi s’avérer utile par rapport aux accumulateurs.
• Comportement parent d’extension
  • Nouveau champ pour CUnit : ParentBehaviorLink
    • Quand une extension est liée à un bâtiment, le comportement du champ ParentBehaviorLink est appliqué audit bâtiment. C’est l’extension qui lance ce comportement, pas le bâtiment.
    • Ceci permet au comportement ParentBehaviorLink de contrôler le bâtiment en fonction de l’état de l’extension.
    • Les capacités de transformation peuvent utiliser ce comportement pour valider l’affichage d’un message d’erreur lorsque que le bâtiment reçoit une commande de décollage alors que son extension est en pleine recherche.
• CUnit_LifeDamageGain peut désormais être amélioré.
• CValidatorUnitState a été grandement amélioré pour pouvoir vérifier l’état de jusqu’à 100 unités différentes au lieu d’une seule.
  • Par exemple : Idle, Jumping, Highlighted, ArmorDisabled, Revivable, Dying, ArmySelect, etc.

Modifications d’autres systèmes de capacités

• Génération auto de boutons pour les capacités
  • Pour permettre aux capacités d’être appliquées facilement à toute unité, les créateurs peuvent désormais définir la position par défaut et l’ID de sous-menu de tous les boutons sur le panneau de commandes.
  • Pour chaque capacité, les créateurs peuvent définir si une commande de capacité donnée générera automatiquement des boutons associés de façon à qu’elle fonctionne dès son application à une unité. Ils n’auront plus à définir manuellement ces boutons et icônes dans le panneau de commandes.
• Déclencheur API permettant d’ajouter et de retirer des capacités à des unités en cours de partie
  • Nouvelles actions de Déclencheur API : Unit Add Ability, Unit Remove Ability
• Configuration de niveau plus facile
  • La plupart des types de capacité possèdent un champ Levels permettant de définir directement le niveau max de la capacité associée. En l’associant aux accumulateurs, les créateurs n’auront plus besoin d’implémenter 1 000 ensembles de capacités pour celles possédant autant de niveaux.
  • Ce champ peut être amélioré, ce qui permet aux créateurs de changer les niveaux de compétences maximum en cours de partie.
  • S’il est défini sur 0, sa valeur par défaut, le système de niveaux de capacité s’appuiera sur la fonctionnalité précédente.
• Nouveau champ pour CCharge : TimeDelay
  • Fonctionne avec toutes les charges de capacité, d’objet et de comportement.
  • Fonctionne de la même manière que TimeStart mais n’affecte que la première charge de la capacité, de l’objet ou du comportement.
  • Si TimeDelay = 0, le système de charges fonctionnera comme avant.
  • Si TimeDelay > 0, TimeStart sera ignoré.
  • Quand la capacité commence à accumuler des charges, le temps de recharge de la première utilise la valeur de TimeDelay, tandis que les suivantes utiliseront la valeur de TimeUse.
  • Nouvelle balise : IgnoreTimeDelay
    • Ceci permet aux capacités d’ignorer la valeur de TimeDelay pour l’unité en faveur de leurs propres paramètres.
• Le Remplacement de catalogue prend désormais en charge les capacités d’objets.
  • Le remplacement n’est pas basé sur le propriétaire de l’objet mais sur son utilisateur.
  • Cela permet à différents joueurs d’utiliser le même objet tout en obtenant des effets différents.
    • Par exemple, les créateurs pourront créer différentes unités lorsqu’un objet s’utilise en fonction de la race du joueur.
• SEffectParamsShared possède désormais un membre m_level, ce qui conserve le niveau de la capacité ayant lancé l’arbre d’effets.
  • Les arbres d’effets peuvent s’en servir d’aperçu pour obtenir les données de niveau associées de façon à ce que même si la capacité change de niveau après le lancement de l’arbre d’effets, ce dernier garde en mémoire son ancien niveau.
  • Les accumulateurs peuvent aussi utiliser ces données en tant que données de capacité.
• Il est désormais possible de configurer CEffectCreateUnit_SpawnUnit pour créer différents types d’unités en fonction du niveau de l’arbre d’effets.
• CAbilBheavior peut désormais définir différents validateurs pour Auto Toggle On et Auto Toggle Off au lieu de n’avoir qu’un seul validateur pour le lancement automatique.
• Nouvelles catégories de comportements et de capacités
  • Ajout de plusieurs nouvelles capacités et catégories de bonus.
  • Les comportements de bonus peuvent désormais activer/désactiver les capacités par catégorie.
• Nouveau champ pour toutes les capacités : State Behavior
  • Ce champ crée un comportement lorsqu’une capacité est elle-même créée. Il le détruit une fois la capacité détruite, et l’active ou le désactive quand la capacité fait de même.

Autres modifications du système de dégâts

• Nouveau champ pour CEffectDamage : DamageInheritEffect
  • L’effet défini dans ce champ se déclenchera une fois les dégâts primaires pris en compte.
  • Il héritera du montant des dégâts primaires.
• Nouvelle balise pour CEffectDamage : NoZeroDamageInherit
  • Demande à DamageInheritEffect de ne pas se déclencher quand les dégâts infligés sont nuls.
• Nouveau champ pour CEffectDamage : Fraction
  • Il s’agit d’une fraction supplémentaire qui sera appliquée à toutes les autres fractions.
  • Ce champ prend les accumulateurs en charge, les créateurs pourront donc créer des formules basées sur cette fraction.

Pré-effet d’arme

• Nouveau champ d’arme : PreEffect
  • Il s’agit d’une « version effet » de PreEffectBehavior qui prend en charge la validation de l’unité de cible afin de déterminer si PreEffect doit être exécuté.

Prise en charge de l’interruption homogène

• Nouvelle balise pour CAbilEffect : HomogenousInterrupt
  • Quand cette balise est activée, les utilisateurs verront le comportement suivant : si un joueur sélectionne une unité qui canalise un sort et lui ordonne de se déplacer, elle interrompra sa canalisation pour effectuer son déplacement. Si le joueur sélectionne plusieurs unités et qu’au moins l’une d’entre elle n’est pas en cours de canalisation, seules les unités ne canalisant pas de sort se déplaceront tout de suite. Dans ce scénario, l’ordre de déplacement est mis en attente pour toutes les unités en cours de canalisation.
  • Quand la balise est désactivée, les joueurs verront l’ancien comportement de SC2.

Modification du système de construction de bâtiments

• Faire céder la priorité aux ouvriers lors d’une construction
  • Quand les balises HomogenousInterrupt et Interrupt sont toutes les deux activées dans un CAbilBuild qui n’entraîne pas la disparition des ouvriers à l’intérieur du bâtiment lors d’une construction, alors au cours du processus, ces derniers ne bloqueront pas le placement d’autres bâtiments. Ils s’éloigneront puis reviendront pour trouver un meilleur emplacement depuis lequel continuer la construction.
• Échelonnage automatique du temps d’animation de Building Birth
  • CAbilBuildable envoie désormais des évènements Start, Cancel, Complete, Pause, et Resume au système d’acteurs.
  • Les évènements de départ contiendront aussi l’information du temps de construction du bâtiment. Les acteurs définiront automatiquement la durée de l’animation de construction pour qu’elle corresponde au temps de construction. Ainsi, l’animation Birth des bâtiments se terminera en même temps que leur construction.

Prise en charge du curseur de dégâts de zone pour Attaquer emplacement

• Cette fonctionnalité consiste en deux modifications du code :
  • CActorMsgAbil possède désormais les informations cmd pour que les créateurs puissent utiliser CActorTermAbilCmd afin de répondre à CActorMsgAbil. Ainsi, le système d’acteurs pourra déterminer si le mode curseur est déclenché par une attaque normale ou un guide d’attaque d’emplacement via cmdIndex.
  • CAbilAttack transmet désormais le DisplayEffect au système d’acteurs en tant qu’effet de curseur. Ainsi, le système d’acteur pourra filtrer les cibles et échelonner le curseur de dégâts de zone.
    • Si une unité possède plusieurs armes, le curseur utilisera le premier DisplayEffect valide de ses armes pour déterminer son apparence.

Système de maintenance

• Nouveau champ de race : UpkeepTax
  • Ceci permet aux créateurs de personnaliser le taux de revenus du joueur en fonction de son montant de nourriture.

Construction sur les rampes

• Auparavant dans SC2, le code empêchait les joueurs de construire des bâtiments sur les rampes.
• Nouveau champ de données pour les types de terrain : Ramp No Build
  • Permet à l’utilisateur de choisir si les rampes peuvent ou non accueillir des constructions.
  • Lorsqu’il est désactivé, la construction est possible.

Améliorations de la capacité Collecte

• Nouveau champ pour CAbilHarvest : ResourceAmountCapacity
  • Possède une valeur par défaut de 0.
  • À chaque fois qu’un ouvrier finit de collecter des ressources, il compare le montant qu’il transporte à la valeur ResourceAmountCapacity. S’il est inférieur, l’ouvrier essaiera de continuer à en collecter jusqu’à ce qu’il atteigne le montant voulu, à moins de recevoir un autre ordre.
  • Même si un ouvrier n’a pas atteint le montant voulu de ressources à collecter, le joueur peut lui ordonner d’arrêter et de rapporter celles qu’il transporte.
  • Si un ouvrier se voit attribuer une autre tâche pendant sa collecte, il essaiera de récolter une dernière fois des ressources avant de l’effectuer.
  • Si un ouvrier essaie de continuer sa collecte mais que la ressource ciblée a disparu, il essaiera de trouver une autre source à proximité.
• Nouvelle balise pour CabilHavrest : No Extract
  • Cette balise activée, le capacité Collecte rapportera des ressources sans en épuiser les sources.

Améliorations du système de période du jour

• Nouvel évènement de déclencheur pour saisir les changements jour/nuit : Game Day/Night State Change
• Nouvelle fonction de déclencheur pour obtenir/définir la période du jour selon une valeur fixe : Set Time Of Day (Seconds), Current Time Of Day (Seconds)
• Nouvelle fonction de déclencheur pour obtenir l’état actuel du système jour/nuit : Current Day/Night State
• Nouveau validateur pour valider la valeur de la période du jour : Game Compare Time Of Day

Prise en charge des acteurs pour le dépôt de ressources

• Nouveau message d’acteur : UnitResourceDrop
  • Cet évènement d’acteur intervient à chaque fois qu’une unité dépose une ressource dans un Hôtel de ville (ou toute unité de dépôt).
  • Le champ de nom source correspond à l’acteur d’unité de l’unité ayant déposé la ressource.
  • Le champ de sous-nom correspond au type de ressource. Les créateurs peuvent différencier les dépôts en fonction du sous-nom.
  • L’utilisation des messages SetTextLocalized et SetText après l’évènement définira automatiquement le texte cible sur le montant du dépôt de ressources.
  • Le montant du dépôt (Drop Amount) remplacera l’article « %AMOUNT% » dans le texte cible.

Créer plusieurs fois le même acteur

• Nouveau type d’acteur : CActorBatch
  • Ceci résout un problème qui empêchait l’utilisateur de répéter la création d’un acteur.
  • Cet acteur possède un champ Count, qui permet de créer plusieurs fois le même type d’acteur enfant.
  • Par défaut, l’acteur ainsi créé utilise les repères de CActorBatch.

Prise en charge de la boucle forcée du système d’acteurs

• Le système d’acteurs prend désormais en charge la boucle forcée des animations.
• Nouvelle balise pour EAnimsFlags : ForceLooping
  • Si cette balise et PlayForever sont définies, le système lance une variation aléatoire de l’animation à chaque fois que celle-ci se termine, qu’elle soit censée se lancer en boucle ou non.
  • Priorité des balises : AssetDrivenLooping > ForceLooping > NonLooping
• Nouvelle balise pour EAnimBracketStartFlag : ContentForceLooping
  • Quand cette balise est activée et que ContentPlayOnce ne l’est pas, le système lance une variation aléatoire de l’animation de contenu à chaque fois que celle-ci se termine à moins qu’un message AnimBracketStop soit envoyé, qu’elle soit censée se lancer en boucle ou non.

Amélioration tactique de l’IA

• Nouveau champ pour CUnit : AIExecuteAbilTactical
  • Lance la fonction hook de l’IA tactique avec le schéma suivant : Unit, galaxyFuncName, scanned group, inAbility, inItem.
• Correction d’une incohérence entre les données tactiques et la fonction tactique qui empêchait cette dernière de fonctionner sur les joueurs IA neutres et hostiles.

Prise en charge des ressources personnalisées et de la terrazine pour l’IA

• L’IA synaptique a été améliorée afin que l’IA puisse voir la terrazine et les ressources personnalisées comme des types de ressources. De plus, l’IA peut désormais les collecter.

Réanimation à l’autel par l’IA

• L’IA peut désormais interpréter un ordre Stock comme un ordre de réanimation de héros si elle ne trouve aucun moyen d’en entraîner un certain type.
• Le script d’IA doit enregistrer les bâtiments de réanimation via AIReqAddSpecialMaker(), de la même façon qu’elle enregistre les capacités nucléaires.
• Quand l’IA essaie d’obtenir un héros mais ne trouve pas la capacité d’entraînement, elle parcourt la liste de réanimation et essaie de ranimer un héros du même type.

Remplacement de stock de l’IA

• L’IA respecte désormais le remplacement de catalogue lors d’une tentative de construction ou d’entraînement.
• Par exemple, si un joueur IA remplace un Marine par une Zélote, il reconnaîtra la capacité d’entraînement du Marine comme étant celle du Zélote et pourra donner l’ordre d’entraînement sans problème.
• Ceci affecte également la fusion, la construction, la recherche, l’entraînement, et la formation au Transfert.
• Nouvelle balise d’unité : AIPreplacedForceBully
  • Lorsque préplacée sur une carte, cette unité sera considérée comme une brute remplaçable par l’ordinateur même si ce dernier ne peut actuellement pas la remplacer. Ceci permet à l’ordinateur d’utiliser les capacités conférées par l’action du déclencheur Replace Ability pour remplacer les brutes.

Convertisseur de cartes classiques amélioré

• Le convertisseur de cartes classiques a été amélioré. Lors de la conversion de cartes de Warcraft III, il ne convertira plus uniquement les maillages de terrain mais également leur texture, ainsi que les unités préplacées, les éléments de décor, les éléments destructibles, les caméras et les régions.

Système de butin basé sur les données

• Ajout de nouvelles fonctions natives à Galaxy : UnitLootDropUnit, UnitLootDropPoint
  • Les créateurs de mods peuvent configurer leur butin dans l’éditeur de données associé puis utiliser ces fonctions natives pour en générer (sous la forme d’objets, d’unités, d’effets, ou même d’objets aléatoires de niveau X / de X objet(s) de classe, etc).
• Nouvelles fonctions natives : UnitLootLastCreated, UnitLootLastCreatedGroup
  • Les créateurs de mods peuvent les utiliser pour ramasser le butin qui vient d’être généré via UnitLootDropUnit ou UnitLootDropPoint.
• Nouvelle balise d’objet : IncludeInLootItemPool
  • Cette balise activée, un objet sera inclus à la sélection aléatoire de CLootItem. Les créateurs peuvent ainsi marquer des objets comme « ne pouvant apparaître aléatoirement ».
• CLootItem.ClassArray peut désormais être amélioré. Les créateurs pourront utiliser des déclencheurs pour randomiser la création d’objets de différentes classes.

Modificateur de Ctrl + ordre

• Le modificateur est désactivé par défaut. Utilisez l’action de déclencheur UISetCommandAllowed pour l’activer et le désactiver.
• Si ce modificateur est activé : quand vous maintenez Ctrl en donnant un ordre, celui-ci sera envoyé uniquement aux unités du sous-groupe surligné au lieu de toutes les unités sélectionnées. Par exemple : si un joueur sélectionne un Marine et un Zélote en s’assurant que seul le premier soit surligné. S’il lance un ordre de déplacement à l’aide du clic droit en maintenant Ctrl, seul le Marine se déplacera.

Autres modifications des propriétés du cadre d’IU

• Ajout d’une propriété à CUnitFrame : UseSelectionLeader
  • Donne à l’IU la capacité de détecter l’unité principale de la sélection actuelle (la première unité du sous-groupe actif).
  • Cette propriété activée, CUnitFrame définira automatiquement LocalObservedSelectionLeaderUnit() comme étant son unité. Elle mettra également sa propriété UnitTag à jour afin qu’elle puisse se lier à d’autres cadres.
  • Cette propriété activée, CUnitFrame ignorera tous les liens de propriétés qui lient UnitTag aux autres cadres, puisqu’elle ne doit se baser que sur l’unité principale de la sélection.
  • Cette propriété désactivée, CUnitFrame se comportera comme avant.
• Correction d’un problème qui empêchait CUnitButton de mettre correctement à jour sa propriété UnitTag.

Autres modifications de Déclencheurs API

• Niveau de capacité
  • CAbilRally peut désormais lancer un évènement de niveau de déclencheur : Placer après le ralliement.
• Handicap de joueur
  • Le handicap de joueur peut désormais dépasser la limite des 100 %.
• Gestion des magasins d’unités
  • Nouvelle API Galaxy : UnitMagazineAssign
    • Ajoute une unité existante à un magasin d’unités.
  • Nouvelle API Galaxy : UnitMagazineRemove
    • Retire une unité existante d’un magasin d’unités.
• Nouvelle API d’état de joueur : AlwaysShowUnitTooltip
  • Quand cet état est activé, les unités du joueur afficheront toujours des encadrés d’aides surlignés même si elles ne sont pas marquées comme pouvant le faire.
• Nouvelle API d’état de joueur : GivesBounty
  • Activée par défaut pour tous les joueurs. Lorsqu’activée, les unités du joueur confèrent leurs ressources de victime aux joueurs ennemis qui les ont tuées.
• Nouvelle API d’acteur : ActorScopeMoveTo
  • Déplace un domaine d’acteur vers le positionnement d’un acteur donné.
• Nouvel évènement de déclencheur : Player Spent Vital Event
  • Détecte lorsqu’un joueur a dépensé des ressources vitales.
  • Peut comprendre quelle ressource vitale a été dépensée et en quelle quantité dans la réponse d’évènement de déclencheur.

Autres modifications de l’éditeur de données

• L’éditeur de données peut désormais localiser la ligne XML appropriée lorsqu’un utilisateur sélectionne une entrée de données par défaut.
• Requirement Links (const CTechRequirementsGraph*) respecte désormais le remplacement d’articles XML.
  • Ainsi, la plupart des capacités peuvent désormais utiliser des articles afin que leur Requirement Link possède le même ID qu’elles.
• CBehaviorLinkArraynow respecte désormais le remplacement d’articles XML.
• Dans les messages d’acteur, Animation Props (CAnimProps) respecte désormais le remplacement d’articles XML.
• Tenter d’effacer une propriété TintColor inexistante sur un acteur n’entraînera plus l’affichage d’un message d’erreur.
• CActorQuad possède désormais des balises afin qu’il puisse s’étirer automatiquement en fonction de son lancement et de ses positions d’impact.
• Nouveau type de classement cible : CTargetSortValidator
  • Classe les cibles en fonction de leur respect des validateurs donnés.
• Nouvelle balise de commande d’ordre : Attack Once
  • Lorsqu’un ordre d’attaque est donné, il est désormais possible de donner un ordre d’attaque unique à l’aide des balises de commande d’ordre.
  • L’action de déclencheur Order Set Flags peut servir à définir cette balise.
• Les champs de CEffectOffset peuvent désormais être améliorés à l’aide d’opérations Add, Subtract, Multiply, et Divide, comme avec un vecteur 3D. Auparavant, il était seulement possible de les définir.
• Nouvelle cinétique : CKineticDistance
  • Projettera l’unité depuis la position de départ jusqu’à un endroit donné dans la direction de l’emplacement indiqué via un paramètre cinétique.
• Nouveau champ pour CWeapon : DisplayName
  • Sert à supplanter le nom de l’arme dans l’encadré d’aide.
• Nouvelle balise pour CEffectModifyUnit : StartingVitals
  • Ramène les PV, l’Énergie et les Boucliers d’une unité à leur montant de départ.
• Nouvelle balise pour CEffectModifyUnit : SetVitals
  • Définit directement le montant des caractéristiques d’une unité.
• Effets de soin pour CActorActon
  • CEffectHeal peut désormais fournir les messages ActionParticipantsMessage et ActionCommenceMessage à CActorAction. Ceci permet aux effets de soin de configurer les actions d’acteur.
  • Correction d’un problème qui empêchait CEffectHeal de déclencher le sous-nom de son action d’effet Stop au bon moment.
• Nouvelle balise pour CValidatorUnitOrderCValidatorUnitOrder : CheckStateOnly
  • Cette balise activée, ce validateur ne lancera son évaluation que si la commande de capacité est désactivée pour l’unité concernée, même si ladite commande peut être exécutée pour des raisons telles que « pas assez de mana ».
• Nouvelle balise pour CEffectModifyUnit : ResourceDrop
  • Cette balise activée, l’unité impactée lâchera instantanément la ressource qu’elle transporte sans avoir à se rendre à un Hôtel de ville, et son propriétaire la recevra.
• Nouvelle balise pour CEffectEnumArea : UnCreep
  • Cette balise activée, l’effet de recherche exclura les monstres de son rayon de recherche.
• API de source aléatoire d’unité :
  • Nouvelle API de déclencheur permettant de définir, d’obtenir ou de réinitialiser la source randomisée d’une unité.
  • La source randomisée d’une unité détermine aléatoirement son nom, ses variations, etc.
  • Ceci s’avère utile lorsque vous voulez créer une copie conforme d’une unité.
• Correction d’un problème à cause duquel CEffectSwitch renvoyait parfois un message d’erreur erroné.
• Nouvelle balise pour les capacités d’entraînement : Copy Life Percentage
  • Détermine si l’unité entraînée doit hériter du pourcentage de PV de l’unité entraîneuse.
• Nouvelle balise pour les capacités d’entraînement : Bypass Food Restriction
  • Permet à la capacité de contourner les restrictions de nourriture.
• Nouvelle balise pour Placement Build : Smart Cast
  • Détermine s’il est possible d’effectuer un clic droit pour lancer rapidement la capacité.
• Nouvelle balise pour les capacités d’effet : External Acquire Passenger
  • Permet aux capacités de cibler des unités à l’intérieur d’un transport.
• Correction d’un problème à cause duquel le validateur Unit Weapon Range échouait toujours lorsqu’une unité était sous l’effet d’un contrôle mental.
• Nouvelle balise pour d’effet Create Healer : Continue When Full
  • Détermine si l’effet Create Healer continue une fois la caractéristique soignée à son maximum.
  • Désactivée par défaut.
• Correction d’un problème à cause duquel les effets Create Unit créaient directement les unités au point de ralliement au lieu de les y déplacer s’il était défini.
• Nouveau champ pour Set Effect : RecycleCount
  • Permet aux effets enfants d’être exécutés à volonté jusqu’à ce que le nombre de recyclage défini soit atteint.
• Nouvelle balise pour les capacités d’effet : Cancel Reset Auto Cast
  • Détermine si l’état de lancement automatique de la capacité doit être réinitialisé quand le joueur en annule manuellement la canalisation.
• Nouveau champ de validateur Veterancy Level : Result Max Level
  • Vérifie si une unité a atteint le niveau de héros maximum.
• Correction d’un problème qui empêchait les alertes de réanimation d’indiquer les unités ranimées et de diffuser le bon fichier audio.
• Nouvelle balise pour Set Effect : Set Source
  • Définit le point/unité source de ses effets enfants en tant que point/unité cible du point/unité cible actuel.
• Ajout d’une boîte de recherche à la boîte de dialogue de la liste de commandes de capacités dans l’éditeur de données.

Correctifs pour les races personnalisées

• Le menu déroulant des races dans les salons de jeu affiche désormais correctement les races personnalisées définies pour la carte au lieu de n’afficher que les Terrans, les Zergs et les Protoss.
• Veuillez noter que cette modification n’affecte pas encore les modules de carte. Il est pour l’instant impossible d’ajouter des races personnalisées au menu déroulant via un module de carte.
• Correction d’un problème qui entraînait un plantage des cartes dotées de races personnalisées à cause d’une fonctionnalité d’apparence de la console.

Prise en charge des noms d’équipes personnalisés

• L’éditeur de SC2 prend désormais en charge les noms d’équipes personnalisés.
• Les noms d’équipes personnalisés peuvent être définis de façon différente en fonction des différents modes de jeu.
• Pour personnaliser les noms de jeu, rendez-vous dans Map/Mod->Game Variants.

Extension du tag de texte « d time/ »

• Ajout de cinq nouveaux Time Types au tag de texte « time » afin d’afficher différents temps de jeu.
• Utiliser ces noms de types au lieu d’un nombre direct permet au tag de texte d’afficher le temps en jeu correspondant.
• Exemples :
  • Texte saisi
    • Temps fixe : "d time="9125"/>
    • Temps de jeu : "d time="GameTime"/>
    • Durée de la mission : "d time="MissionTime"/>
    • Temps de l’IA : "d time="AITime"/>
    • Date et heure : "d time="DateTime"/>
    • Heure : "d time="TimeOfDay"/>
  • Texte affiché
    • Temps fixe : 9125 seconds
    • Temps de jeu : 11:50
    • Durée de la mission : 11:50
    • Temps de l’IA : 11:50
    • Date et heure : 2020:06:12:12:12:23
    • Heure : 22:06:34

Autres modifications des propriétés du cadre d’IU

• Nouvelles propriétés de CHeroFrame : HeroTag, Skill Point
  • Affiche le tag d’unité d’un héros et ses points de compétences disponibles.
  • Les créateurs peuvent utiliser ces propriétés pour personnaliser leurs cadres de héros.

Modifications diverses

• Le foliageCount maximum de l’éditeur terran a été porté à 10 par cellule.
• Correction d’un problème qui entraînait l’affichage d’un message d’erreur rouge en cas de tentative de réanimation d’une unité morte pendant sa transformation.
• Nouveau champ dans les données GameUI : Suppress Skins In Replay
  • Permet à WCS GameHeart de supprimer les modèles dans les parties enregistrées.

CORRECTIONS DE BUGS

• Correction d’un problème qui pouvait entraîner le blocage de la première vague d’attaque dans la mission de campagne « Les murmures de l’oubli » de Legacy of the Void.
• Correction d’un problème qui empêchait les Batteries de boucliers d’obéir aux commandes d’arrêt sur les bâtiments non défensifs lorsque le lancement automatique était activé.
• Le portait du Centre de commandement apparaît désormais correctement centré sur le modèle de console Terran Remastered.
• Correction d’un problème à cause duquel certains éléments de décor aquatiques clignotaient au-dessus de l’eau.