Direkt zum Inhalt
Teaser Bild von SC2: Die Patchnotes zu dem neuen Patch 5.0

Wie bereits in dem Beitrag zu dem 10. Geburtstag von Starcraft 2 erwähnt wurde, haben die Entwickler von Blizzard Entertainment mit den in dieser Woche durchgeführten Wartungsarbeiten den brandneuen Patch 5.0 in der europäischen Spielregion veröffentlicht.

Praktischerweise wurde dieses Update dann auch wieder von offiziellen Patchnotes begleitet, die wie üblich ganz genau auflisten, was für Änderungen und Neuerungen dieser Patch mit sich brachte. Dieser Übersicht zufolge beinhaltete Patch 5.0 eine handvoll von notwendigen Fehlerbehebungen, alle Inhalten für den 10. Geburtstag des Spiels, einige kleinere Neuerungen und eine enorm hohe Anzahl von Verbesserungen für den Editor des Spiels. Folgend könnt ihr bei Interesse selbst einen Blick auf diese Patchnotes werfen.   StarCraft II 5.0 – Patchnotes: ALLGEMEIN Countdown-Timer zum Spielstart In Versus-Spielen wurde ein kurzer Countdown-Timer hinzugefügt, der jetzt bis zum Beginn des Spiels herunterzählt, sobald der Ladevorgang aller Spieler abgeschlossen ist. Auswahl vom Spielserver bei der Erstellung von Lobbys Lobby-Hosts können jetzt bei der Erstellung einer benutzerdefinierten Lobby ihren Spielserver auswählen. Hinweis: Dafür müsst ihr in den Optionen unter „Sprache und Region“ eine Option aktivieren. Neuer Ansager: White-Ra „Mehr GG, mehr Können.“ Neuer Ansager: Stone Ein Ghost der Liga mit einer geheimnisvollen Vergangenheit. Er ist nur als „Stone“ bekannt.“   NEUE KAMPAGNENERFOLGE Ein neuer Kampagnenerfolg wurde für jede Mission in Wings of Liberty, Heart of the Swarm, Legacy of the Void und Novas Geheimmissionen hinzugefügt. Sobald ihr alle Kampagnenerfolge zum 10. Jubiläum abgeschlossen habt, erhaltet ihr den neuen Ansager Stone. Hinweis: Diese Erfolge können auf jedem Schwierigkeitsgrad über Normal verdient werden. Sie wurden entwickelt, um sogar auf Brutal skalierbar und erzielbar zu sein, allerdings sind sie extrem schwierig.   EIGENE KAMPAGNEN Das neue Genre „Kampagne“ wurde für Arcade-Karten hinzugefügt. Unter „Benutzerdefiniert“ wurde eine neue Kategorie namens „Kampagnen“ hinzugefügt, über die Karten aus dem Genre „Kampagne“ angezeigt werden. In StarCraft II kann jetzt eine Mehrspielerlobby von einer Karte auf eine andere übertragen werden. Für die Übertragung müssen beide Karten vom selben Autor veröffentlicht worden sein. Eine neue Funktion für Online-Kartenübergänge wurde hinzugefügt, mit der der Autor einen zugewiesenen Kartenplatz für alle Spieler laden und verschiedenen Spielergruppen Sieg bzw. Niederlage zuweisen kann. Kartenplätze können im Fenster „Veröffentlichungen verwalten“ über das Rechtsklick-Kontextmenü einer veröffentlichten Karte zugewiesen werden. Kartenplätze müssen in jeder Region einzeln zugewiesen werden. Wir empfehlen euch, dass die erste Karte in der Kette die für alle anderen Karten benötigten Asset-Abhängigkeiten beinhaltet, um die Ladezeiten zwischen Karten möglichst gering zu halten. Das neue Genre „Kampagne“ wurde hinzugefügt und kann im Menü „Spielvarianten“ zugewiesen werden.   PRESTIGE FÜR CO-OP-KOMMANDANTEN Ein neues „Prestige“-System wurde hinzugefügt, mit dem Spieler die Fortschritte von Stufe 1 –15 mit jedem Kommandanten bis zu dreimal zusätzlich durchspielen können. Jedes Mal, wenn ein Spieler mit einem Kommandanten Prestige erreicht, wird ein einzigartiges Prestigetalent freigeschaltet, mit dem das grundlegende Gameplay des Kommandanten geändert werden kann. Für jeden Kommandanten kann jeweils nur ein Prestigetalent ausgerüstet werden. Wenn ein Spieler keines dieser Talente ausrüstet, hat der Kommandant sein normales Loadout. Beispiele für Prestigetalente sind: Abathur: Der Unbegrenzte Die Anzahl Ultimativer Evolutionen ist unbegrenzt. Für Ultimative Evolutionen werden allerdings 200 Biomasse für die Metamorphose benötigt und Biomasse gewährt die Hälfte der normalen Vorzüge. Alarak: Konstrukteur der Seelen Wenn ein Helot stirbt, erhöht er dauerhaft den Schaden und die Angriffsgeschwindigkeit einer nicht heroischen mechanischen Einheit in der Nähe von Alarak. Alaraks aktive Fähigkeiten verursachen allerdings um 50 % verringerten Schaden. Dehaka: Brutsbruder Dehaka bekommt einen Bruder. Allerdings haben beide weniger Trefferpunkte. Bei 18 Kommandanten und 3 Prestigetalenten pro Kommandanten könnt ihr also insgesamt 54 neue Prestigetalente ausprobieren.   CO-OP-MISSIONEN Mutatoren Neuer Mutator: Bummbots Gefühllose Roboter halten bestückt mit Nuklearsprengsätzen auf eure Basis zu. Ein Spieler muss sich den Code zum Entschärfen besorgen und der andere muss ihn eingeben. Kommandanten Abathur Die Meisterung Chance auf doppelte Biomasse wurde von 2 auf 3 % pro Punkt erhöht. Die maximalen Boni wurden von 30 auf 45 % erhöht. Artanis Die Reichweite der Luftabwehr von Tempests wurde von 6 auf 10 erhöht. Dehaka Die Meisterung Abklingzeit des großen Urwurms wurde von 1,5 auf 2 % pro Punkt erhöht. Die maximalen Boni wurden von 45 auf 60 % erhöht. Die Meisterung Genmutation wurde von 2 auf 1 % pro Punkt verringert. Sie wird jetzt aber mit der Standardeigenschaft addiert und nicht mehr multipliziert. Dadurch hat sich die maximale Chance auf Genmutation von 32 auf 50 % erhöht. Fenix Taktisches Datennetz erhöht jetzt den Schaden von Talis‘ Fähigkeit Querschlägergleve und verringert nicht mehr die Abklingzeit. Der Schaden der Fähigkeit Überladungsstoß von Warbringer wurde von 300 auf 150 verringert. Die Abklingzeit von Überladungsstoß wurde von 10 auf 5 Sek. verringert. Taktisches Datennetz erhöht jetzt den Schaden von Überladungsstoß und verringert nicht mehr die Abklingzeit. Der Schaden von Mojos Fähigkeit Unterdrückungsprotokoll wurde von 11 (22 gegen gepanzerte Ziele) auf 6 (12 gegen gepanzerte Ziele) verringert. Die Betäubungsdauer von Unterdrückungsprotokoll wurde von 2 auf 1 Sek. verringert. Die Abklingzeit von Unterdrückungsprotokoll wurde von 10 auf 5 Sek. verringert. Taktisches Datennetz erhöht jetzt den Schaden von Unterdrückungsprotokoll und verringert nicht mehr die Abklingzeit. Han und Horner Kampfgaleonen mit dem Upgrade Hangarbucht verfügen jetzt über die Fähigkeit Abhärtung, durch die sie außerhalb des Kampfes Trefferpunkte regenerieren können. Der Schaden von Hellions wurde von 15 (30 gegen gepanzerte Einheiten) auf 15 (40 gegen gepanzerte Einheiten) erhöht. Die Boni von Waffenupgrades wurden dementsprechend angepasst. Der Grundwert des Suchradius von Lauffeuersprengsätze wurde von 3 auf 4 erhöht. Der Meisterungsbonus für den Suchradius von Lauffeuersprengsätze wurde von 4,24 auf 5,66 erhöht. Karax Die Kosten des Upgrades Solareffizienz der Stufe 1 wurden von 200/200 auf 100/100 verringert. Die Kosten des Upgrades Solareffizienz der Stufe 2 wurden von 250/250 auf 150/150 verringert. Die Kosten des Upgrades Solareffizienz der Stufe 3 wurden von 300/300 auf 200/200 verringert. Das Upgrade Solareffizienz der Stufe 1 erhöht jetzt die Energieregeneration alle 6 Sek. um 1 (vorher alle 6 Sek. um 2). Das Upgrade Solareffizienz der Stufe 3 erhöht jetzt die Energieregeneration alle 6 Sek. um 3 (vorher alle 6 Sek. um 2). Die Forschungskosten für Verbesserte Zielfindung wurden von 150/150 auf 100/100 verringert. Die Forschungskosten für Optimierte Geschütze wurden von 150/150 auf 100/100 verringert. Die Forschungskosten für Rekonstruktion wurden von 150/150 auf 100/100 verringert. Die Forschungskosten für Schnelle Aufladung wurden von 150/150 auf 100/100 verringert. Die Forschungskosten für Schattenkanone wurden von 150/150 auf 100/100 verringert. Das Upgrade Feuerstrahl verringert die Waffengeschwindigkeit von Kolossen nicht mehr. Die Forschungskosten für Reparaturdrohnen wurden von 200/200 auf 100/100 verringert. Neues Upgrade: Graviton-Katapult: Kosten: 150/150: Träger können Interceptoren schneller freigeben und erhöht die Angriffsgeschwindigkeit von Interceptoren um 25 %. Der Meisterungsbonus von Heilungsrate des Reparaturstrahls wurde von 1 auf 3 % pro Punkt erhöht. Die maximalen Boni wurden von 30 auf 90 % erhöht. Der Meisterungsbonus von Energieerzeugung durch Zeitschleifenwelle wurde von 1 auf 3 Energie pro Punkt erhöht. Der maximale Bonus wurde von 30 auf 90 Energie erhöht. Mengsk Imperiale Wachen auf Rang 0/1/2/3 erhöhen jetzt Imperiale Unterstützung um 1/1,5/2/2,5 pro Versorgung (vorher 0,5/1/1,5/2). Der Radius von Fortifikationsfeld wurde von 3 auf 5 erhöht. Der Panzerungsbonus von Fortifikationsfeld wurde von 3 auf 5 erhöht. Himmelszorn-Einheiten auf Rang 1+ fügen jetzt in jedem Modus massiven Zielen 50 Bonusschaden zu (vorher 25 Bonusschaden). Nova Die Upgrades für Fahrzeug- und Schiffwaffen erhöhen jetzt den Schaden von Sturmfalken pro Upgrade um 13 (vorher 5). Stetmann Das Talent Freunde fürs Leben wurde von Stufe 5 auf Stufe 9 verschoben. Das Talent Prozessoptimierung wurde von Stufe 9 auf Stufe 15 verschoben. Das Talent Meisterwerk wurde von Stufe 15 auf Stufe 5 verschoben. Stukov Die Kosten für Verseuchte Space-Marines wurden von 25 auf 15 verringert. Tychus Die Meisterung Verfügbarkeit von Outlaws wurde von 2 auf 3 Sek. pro Punkt erhöht. Der maximale Bonus wurde von 60 auf 90 Sek. erhöht.   NEUE ÄNDERUNGEN AM GALAXIE-EDITOR Data Collections Die Data Collection (Datensammlung) ist eine neue Art von Katalog, mit der Benutzer eine Reihe von Datenelementen in einer Sammlung bestimmen und gruppieren können. Ihr könnt euch eine Sammlung wie alle anderen Daten vorstellen, wie zum Beispiel Einheiten, Fähigkeiten oder Upgrades. Wird eine Datensammlung kopiert, umbenannt oder gelöscht, wendet der Editor intelligent dieselbe Aktion für alle Datenelemente in der Sammlung an. Wenn ihr zum Beispiel eine Datensammlung kopiert, werdet ihr gebeten, der neuen Sammlung einen Namen zu geben. Der Editor wird dann alle Dateneinträge in der Sammlung duplizieren und sie dementsprechend benennen. Der Editor wird außerdem alle verknüpften Felder festlegen, sodass die neuen Dateneinträge mit ihren neuen Gegenstücken verbunden sind.   Beispiel: Kopiert die Sammlung „Blizzard“ und legt den Namen der neuen Datensammlung als „Activision Blizzard“ fest. Wird eine Datensammlung gelöscht, so werden alle Einträge in der Sammlung gelöscht. Wird die ID einer Datensammlung geändert, so werden auch die IDs aller Dateneinträge in der Sammlung geändert. Die Dateneinträge einer Datensammlung können entweder manuell festgelegt oder automatisch vervollständigt werden. Datensammlungen verwenden bei der Benennung untergeordneter Dateneinträge das neue Schlüsselsymbol „@“. Das System für die Datensammlungen kann automatisch den gesamten Katalog durchsuchen, um Dateneinträge zu finden, deren IDs mit der ID der Datensammlung, gefolgt vom Symbol „@“, beginnen. Daraufhin werden sie automatisch der Sammlung hinzugefügt. Wenn der Effektbaum einer Fähigkeit geändert wird, werden aufgrund dieser verknüpften Funktionsweise die entsprechende Datensammlung und ihre Einträge automatisch aktualisiert. Hier ist ein Beispiel für Daten innerhalb einer automatisch vervollständigten Datensammlung:   Daten, für die diese automatische Benennung nicht angewendet wird, werden zwar nicht automatisch vervollständigt, aber sie können trotzdem manuell Datensammlungen hinzugefügt werden. Das Menü Data Collection -> Auto Fill Data Collection durchsucht automatisch den gesamten Katalog und findet alle Dateneinträge, die mit einer ID der Datensammlung, gefolgt vom Symbol „@“, beginnen. Daraufhin werden sie automatisch der entsprechenden Sammlung hinzugefügt. Das Menü Data Collection -> Auto Name Data Collection benennt die Dateneinträge in der Datensammlung anhand des Namens der Datensammlung um. Mithilfe von Datensammlungen können wir außerdem zusätzliche Informationen über die Beziehungen von Dateneinträgen hinzufügen. Zum Beispiel kann das Spiel mithilfe von Datensammlungen jetzt Informationen wie „Was ist der Hauptakteur für diese Einheit?“ verstehen. Viele andere Features in diesem Update hängen von diesem Feature für die Datensammlung ab. Mithilfe von bestimmten Regeln für das Programmieren könnt ihr das volle Potenzial von Datensammlungen ausschöpfen: Alle Datensammlungen sollten so eigenständig wie möglich sein. Beispielsweise sollte eine „Einheitensammlung“ immer funktionieren, wenn ihr sie einer Einheit hinzufügt, und eine Fähigkeit sollte nie so festgelegt sein, dass sie nur mit bestimmten Einheiten oder Einheiten mit bestimmten Waffen funktioniert. Ein warnendes Beispiel: In der alten Datenbank von SC2 befand sich eine passive Fähigkeit, durch die sich der Schaden von Phasengleitern erhöhte, wenn sie über längere Zeit dasselbe Ziel angriffen. Diese passive Fähigkeit war in Wirklichkeit geschummelt, und die Funktionsweise war in die Waffe des Phasengleiters programmiert. Wenn ihr in Zukunft auf Datensammlungen zurückgreifen könnt, möchten wir euch stark davon abraten, Daten missbräuchlich zu verwenden. Um dieses Ziel zu erreichen, haben wir viele der unten beschriebenen Features entwickelt.   „Easy Mode“ für den Daten-Editor Der „Easy Mode“ (einfacher Modus) für den Daten-Editor ist ein erweitertes Feature von Datensammlungen. Wenn dieser Modus aktiviert wird, wird der Daten-Editor nur Datensammlungen anzeigen und sie imitieren, als wären sie einzelne „Fähigkeitendaten“, „Einheitendaten“, „Gegenstandsdaten“ oder „Upgradedaten“ usw. Ihr könnt diese Daten kopieren, entfernen, löschen oder umbenennen, als wären sie einzelne Datenobjekte. Dieser Modus ist nur in der Tabellenansicht verfügbar. Er kombiniert die wichtigsten Datenfelder wie Daten für Trefferpunkte von Einheiten oder Daten für Fähigkeitenschaden. Die im einfachen Modus angezeigten Felder sind für jede Art von Datensammlung vollständig anpassbar. Eine der häufigsten Beschwerden von Kartenentwicklern ist, dass es im Editor von SC2 zu kompliziert ist, Einheiten oder Fähigkeiten zu duplizieren. In dieser Hinsicht bietet der Editor von Warcraft 3 den größten Vorteil gegenüber dem Editor von SC2. Unsere Lösung ist die Kombination von Datensammlungen und dem einfachen Modus. In Zukunft möchten wir mehr Daten basierend auf Datensammlungen erzeugen, sodass Benutzer einfacher mit ihnen interagieren können. Wir möchten Modder dazu anregen, ihre eigenen Mods mit Datensammlungen zu entwickeln, sodass sie ihre Vorzüge genießen können. Außerdem möchten wir Entwickler von öffentlichen Mods bitten, ihre Ansicht im einfachen Modus zu definieren, sodass andere Modder ihre Mods problemlos ändern und modifizieren können. Akkumulatoren Akkumulatoren sind ein neues Feature, mit dem Kartenentwickler Formeln in Datenfeldern anhand von verschiedenen Eingabeparametern entwickeln können. Zum Beispiel kann der Schaden einer Fähigkeit folgendermaßen festgelegt werden: Die Trefferpunkte des Casters + das Intelligenzattribut des Casters * 2 – 75 + die fehlenden Trefferpunkte des Ziels – , und wenn der Caster eine Banane hatte, dann + (2 * der vom Schild des Casters absorbierte Schaden). Natürlich müssen Formeln für die Schadensberechnung in richtigen Spielen nicht unbedingt so kompliziert sein. Das ist nur ein Beispiel dafür, was ihr mit Akkumulatoren anstellen könnt. Akkumulatoren verwenden benutzerdefinierte Einheitenwerte und Benutzerdaten als Parameter. Akkumulatoren unterstützen nicht nur Formeln, sondern auch benutzerdefinierte Tabellen. In Kombination mit Validatoren können Akkumulatoren auch für die Funktion von Case Switches verwendet werden. Wenn beispielsweise ein Akkumulator in einem Verhalten verwendet wird, das über unterschiedliche Stufen verfügt und von mehreren Spielern ausgeführt werden kann, berechnet der Akkumulator das Ergebnis pro Spieler einzeln. Akkumulatoren sind sehr vielseitig und können unter vielen Umständen eingesetzt werden. Beispiele dafür sind Schaden, Heilungsrate, Trefferpunkteregeneration, Schadensverringerung, Kosten von Fähigkeiten, Panzerungsbonus, Zählsektionen von Akteuren, Anzahl von „Beständig“-Effekten, Anzahl von Verhalten, Dauer von Verhalten, Anteile von Schaden, Angriffsgeschwindigkeit, Bewegungsgeschwindigkeit, Regeneration von Vitalwerten, Chance von Verhalten, Modifikation von Vitalwerten usw. Neuer String-Parsertoken: $AccumulatedValue:xxx$ Dieser Token kann verwendet werden, um in der Benutzeroberfläche AccumulatedValue zu berechnen. Zum Beispiel: Dieser Token kann verwendet werden, um in der Benutzeroberfläche AccumulatedValue zu berechnen. Zum Beispiel: Ruft „d ref=“$AccumulatedValue:Effect,JainaBlizzardPersistent,PeriodCount$“/>“ Wellen von Eissplittern herbei, die das Ziel einfrieren. Jede Welle fügt Einheiten im Wirkungsbereich Schaden zu. Player Level Response Der neue Datenkatalog „Player Response“ ermöglicht Benutzern, Reaktionsmuster zu definieren, wenn etwas mit dem ausgerüsteten Spieler passiert. Designer können Auslöser verwenden, um diese Reaktionsmuster bestimmten Spielern zuzuweisen, und die Einheiten des Spielers reagieren auf die registrierten Ereignisse, als hätten sie alle Verhalten für Schadensreaktionen. Benutzer haben die Möglichkeit, Prioritäten und Fehlschlagmethoden für Spielerreaktionen festzulegen. Durch Player Level Response müssen bei der Erstellung von Kommandanten nicht mehr jedem bestimmte Verhaltensformen zugewiesen werden, was die Leistung des Spiels deutlich verbessert. Weil ihr außerdem nur Reaktionen ausrüsten müsst, wenn der entsprechende Kommandant reagiert, muss das Spiel nicht mehr jedes Mal die Daten für Todesvermeidung aller Kommandanten durchlaufen. Player Response ist nicht mehr aus Schadensreaktionsverhalten wie „Einheit ist beschädigt“ eingeschränkt. Sie kann auch auf Erschaffen von Spielern, Einheiten, Tod von Spielereinheiten usw. reagieren.   Statusleiste ohne Segmente   Die Auslöseraktion UI – Override Player Option ermöglicht Kartenentwicklern jetzt, die Darstellung der standardmäßigen Statusleisten anzupassen, sodass sie linear und ohne Segmente angezeigt werden. Das ist besonders nützlich für benutzerdefinierte Mods, für die eine genauere Darstellung von Vitalwert-Teilen benötigt wird. Aktualisierte Daten für den Asset-Mod War3 Im Februar 2015 haben wir einen Mod mit Assets aus War3 veröffentlicht. Obwohl das Paket nur Assets enthielt, wollten viele Modder lernen, Fähigkeiten im Rollenspielstil von War3 mit dem Editor von SC2 zu erstellen. Bei so vielen Änderungen am Editor in diesem Patch möchten wir Moddern einige Beispiele mit all diesen neuen Features bieten. Wir haben mit dem Entwickler des Communitymods Renee’s Warcraft III Mod zusammengearbeitet, um seinen Mod mit all den neuen Features für den Editor nachzubilden. Jetzt enthält der Asset-Mod War3 eine ganze Reihe an funktionierenden Daten, die Spezies, Einheiten, Gebäude und Fähigkeiten umfasst. Wir hoffen, dass Modder aus diesen Beispielen lernen können. Wenn ihr eine Warcraft-Standardkarte erstellen möchtet, solltet ihr am besten nicht die Standardoptionen von StarCraft II für Standardkarten verwenden, weil Helden dadurch keine EP erhalten können. Stattdessen haben wir im „Warcraft Sample“-Mod die benutzerdefinierte Auslöseraktion „War3 Standardeinstellung verwenden“ hinzugefügt. Diese Auslöseraktion legt die Heldenbegrenzung, Startgebäude, Tageszeit und Kriecher basierend auf den Einstellungen der Warcraft III-Standardkarte fest.   Bewegung in Formation   StarCraft II unterstützt jetzt Bewegung in Formation. Diese Funktion kann für jeden Spieler mit Auslösern ein- und ausgeschaltet werden. Einheiten können sich in Quadratformation mit vorbestimmten Abständen zwischen ihnen bewegen und angreifen. Aktuell werden durch diese Bewegung in Formation nicht alle Einheiten in der Formation gezwungen, sich mit derselben Bewegungsgeschwindigkeit fortzubewegen, was sich von der Version aus War3 unterscheidet. Modder können diese Daten bearbeiten, um das Verhalten anzupassen.   Wegfindung über Wasser   StarCraft II unterstützt jetzt Wegfindung über Wasser! Neue Wegfindungstypen: Seichtes Wasser und Tiefes Wasser. Neue Wegfindungsmodi: Schwimmen und Amphibisch. Bodeneinheiten können sich auf Kacheln für Boden und Seichtes Wasser fortbewegen. Schwimmende Einheiten können sich auf Kacheln für Seichtes Wasser und Tiefes Wasser fortbewegen. Amphibische Einheiten können sich auf Kacheln für Boden, Seichtes Wasser und Tiefes Wasser fortbewegen. Flugeinheiten können sich überall bewegen, wo sie nicht durch Wegfindungssperren in der Luft behindert werden. Diese beiden neuen Arten der Wegfindung können momentan nur durch den Wegfindungspinsel im Terrain-Editor festgelegt werden.   Mehrere Klippen-Layer   StarCraft II unterstützt jetzt bis zu 15 Klippen-Layer (vorher 3). Fehlerbehebung für PTR-Patch 4.13: Die Wegfindung über Klippen ist jetzt für Klippenstufen, die größer als 3 sind, wie vorgesehen belegt. Überarbeitetes Upgrade-System Das hier ist ein großer Teil der neuen Datensammlungs- und Kommandantensysteme. Das alte Upgrade-System war nicht eigenständig, was unserem Ansatz mit der neuen Datensammlung völlig widersprach. Im alten Upgrade-System bestimmten Upgrades die von ihnen betroffenen Fähigkeiten oder Einheiten mit ihren entsprechenden Upgrade-Effekten. Durch das neue Upgrade-System können Upgrades viel eigenständiger sein. Einheiten müssen jetzt bestimmen, welche Upgrades sie verwenden. Davor bestimmten Upgrades, welche Einheiten von ihnen betroffen sind. Ein Beispiel: Upgrades sollten nicht mehr im Stil von „Erhöht die Trefferpunkte von Space-Marines um 10“ implementiert werden. Stattdessen sollten sie so funktionieren: „Erhöht die Trefferpunkte jeder beliebigen Einheit, die mich verwendet, um 10.“ Neues CUpgrade-Feld: EffectArrayTemplate Dieses Feld ähnelt dem alten Feld „EffectArray“, abgesehen von diesen Ausnahmen: Es unterstützt zwei zusätzliche Token: ^ParamId^: Die ID einer Datensammlung, die dieses Upgrade verwendet. ^ParamLevel^: Die aktuelle Stufe des Upgrades. Es unterstützt Datenreferenzen und Arithmetik. Mit geschweiften Klammern „{“ und „}“ könnt ihr wie in einem Text-Editor Formeln erstellen. Datensammlungen ermutigen Modder bereits dazu, alle zugehörigen Daten mithilfe einer bestimmten Namenskonvention zu benennen. Modder können also jetzt ganz einfach ^ParamId^ für Dateneinträge verwenden, die mit der Einheit, die sie verwendet, in Verbindung stehen. Zum Beispiel: EffectArrayTemplate Reference=“Effect,^ParamId^@Weapon,Amount“ Value=“{DataCollection,^ParamId^,UpgradeInfoWeapon.DamagePerLevel+3}“/ Dieses Upgrade wird den Waffenschaden der Einheit, die es verwendet, um das Feld UpgradeInfoWeapon.DamagePerLevel der Datensammlung der Einheit plus 3 erhöhen. Ihr könnt eine festgelegte Zahl in die Spalte für „Value“ (= Wert) einfügen, z. B. Value=“4“. Die alten Felder von CUpgrade gibt es weiterhin und sie werden auch wie gewohnt funktionieren, das gilt also auch für alle alten Upgrades. Ihr könnt weiterhin Upgrades im alten Stil entwickeln, wir möchten euch aber davon abraten. Unterstützung von Upgrades für alle Einheiten Weil einige Upgrades entwickelt wurden, um für „alle Einheiten“ (eines bestimmten Typs) zu funktionieren, verfügt CUpgrade jetzt über eine Kennzeichnung, um alle Einheiten einer Datensammlung aufzuzählen. Zwei Filterfelder, EnumExcludedUserFlags und EnumRequiredUserFlags, wurden ebenfalls zu CUpgrade hinzugefügt. Durch sie können Upgrades alle Einheiten in der Datensammlung anhand ihrer Kennzeichnungen filtern. Neue Upgrade-Vorgänge: AddBaseMultiply und SubtractBaseMultiply Diese Vorgänge modifizieren das Zielfeld anhand seines Standardwerts anstatt seines aktuellen Werts. Das ist grundsätzlich im Vorgang „Multiply“ nützlicher. Wenn ihr zum Beispiel 100 Stufen des Upgrades „erhöht die Trefferpunkte einer Einheit um 10 %“ habt, sollte dieses Upgrade die Trefferpunkte auf jeder Stufe um einen festgelegten Wert erhöhen, anstatt jedes Mal mit den Trefferpunkten der letzten Stufe multipliziert zu werden. Add/SubtractBaseMultiply unterstützt außerdem technologische Downgrades, weil es sich im Gegensatz zu Multiply jederzeit selbst auflösen kann. Upgrades können jetzt verwendet werden, um Einheiten für Spieler zu aktivieren oder zu deaktivieren. Neues Feld für CWeapon: Rate Multiplier Hat einen Standardwert von 1. Wenn das Spiel versucht, die Zeit zwischen Angriffen einer Waffe oder den CP-Effekt zu ermitteln, berücksichtigt es dabei diesen Multiplikator. Durch diese Änderung könnt ihr die Waffengeschwindigkeit um einen Prozentsatz erhöhen, anstatt die Zeit zwischen Angriffen direkt ändern zu müssen. Orb-System (sowie Mehrfachschüsse und Kritische Treffer) Orbs sind als Angriffsmodifikatoren wichtige Teile des MOBA-Genres. Das Schadensreaktionssystem von StarCraft II kann zwar zur Entwicklung von Orbs verwendet werden, aber Schadensreaktion und Angriffsmodifikationen unterscheiden sich sehr stark. Die meisten alten „Orb“-Fähigkeiten in SC2 entsprechen nicht der traditionellen Definition, wie Orbs funktionieren, weil sie in die Waffen selbst eingebaut sind und von beliebigen Waffen nicht einfach entfernt bzw. zu ihnen hinzugefügt werden können. Wenn ihr also einen Orb-Gegenstand entwickeln wollt, wäre es unrealistisch, die Gegenstandseffekte des Orbs in alle Heldenwaffen im Spiel einzubauen. Das hier aktualisierte Orb-System ist ein erweitertes Konzept eines gewöhnlichen Orb-Systems, wie man es aus MOBAs kennt. Es umfasst offizielle Unterstützung für Mehrfachschüsse und Kritische Treffer. Ein echtes Orb-System muss die folgenden Funktionsweisen enthalten: Die Fähigkeit, seine Effekte bei jedem Angriff auf Waffensysteme anzuwenden. Die Fähigkeit, Geschosse zu modifizieren. Die Fähigkeit, besondere Effekte hinzuzufügen, wenn die Waffe das Ziel trifft, z. B. Feuer, Frost, ein angewendetes Verhalten usw. Außerdem sollte es seine Effekte sowohl vor als auch nach dem Treffer anwenden können. Beispielsweise muss für die Fähigkeit Schwarzer Pfeil der Orb das Ziel mit einem Schwächungseffekt belegen, der etwas bestimmtes bewirkt (ein Skelett erschaffen), wenn das Ziel getötet wird. Könnte das Orb-System Effekte nur nach dem Treffer anwenden, würde die Einheit möglicherweise durch den Treffer getötet und es würde kein Skelett entstehen. Ein weiteres Beispiel ist die Orb-Fähigkeit Schrapnellsplitter. Weil sie basierend auf dem primären Angriffsschaden zusätzlichen Flächenschaden verursacht, muss der Effekt des Flächenschadens nach dem Effekt des Treffers auftreten, weil zunächst der zufällige primäre Schaden generiert werden muss. Wenn eine Waffe mit dem Feuervorgang beginnt, muss der Angriffsmodifikator des Orbs bereits vor Ausführung des Angriffseffekts registriert sein. Dadurch können Einheiten besondere Angriffsanimationen wie für kritische Treffer abspielen. Orbs müssen die Fähigkeit haben, dauerhafte Boni für Angriffsschaden anzuwenden. Orbs sollten die Option haben, ihre Effekte zu validieren, z. B. sollten die Fähigkeiten Hieb und Kritischer Treffer nicht auf verbündete Einheiten ausgelöst werden. Neue Effektkennzeichnung: MainImpact Wenn sie aktiv ist, markiert diese Kennzeichnung einen Effekt als den Hauptangriffseffekt aus dem Waffeneffektbaum, sodass Angriffsmodifikatoren wissen, wann sie ihre Modifikatoreffekte auslösen können. Neuer Verhaltenstyp: CBehaviorAttackModifier Wenn diese Modifikatoren angewendet werden, lösen sie ihre Effekte aus, wenn ein Angriff beginnt. Sie registrieren sich zum gesamten Angriffseffektbaum. Das Feld Chance bestimmt die Wahrscheinlichkeit des Angriffsmodifikators, der bei jedem Angriff berechnet wird. Mehrere Modifikatoren können zu einer Einheit hinzugefügt werden. Das Feld Unique Id ermöglicht Benutzern, zu bestimmen, ob sie alle gleichzeitig funktionieren können. In War3 kann nur ein Orb-Effekt stattfinden, auch wenn ein Held mehrere Orbs ausgerüstet hat. Modder wünschen sich aber wahrscheinlich trotzdem, dass mehrere Orbs gleichzeitig funktionieren können. Das Feld Stack Max bestimmt, wie häufig Schadensboni gestapelt werden können. Die Felder Damage Bonus bestimmen, ob es konstante oder variable Boni gibt. Diese Felder unterstützten außerdem Akkumulatoren. Die Felder Validator bestimmen, ob Modifikatoren bei bestimmten Angriffszielen funktionieren. Zum Beispiel wollt ihr wahrscheinlich nicht, dass Kritischer Treffer funktioniert, wenn ihr eure eigenen Einheiten angreift. Das Feld PreImpactEffect löst einen Effekt vor dem Zeitpunkt des Treffers aus. Das Feld DamageInheritEffect löst einen Effekt nach dem Zeitpunkt des Treffers aus und gibt den Schaden des Treffers an den folgenden Effektbaum weiter. Durch diese Effekte können Benutzer einen Kettenblitz-Effekt entwickeln oder Flächenschaden basierend auf dem Angriffsschaden verursachen. Kann bestimmen, ob ein Angriff das Ziel verfehlen kann. Genaueres findet ihr im Abschnitt für das System für Verfehlen/Umlenken/Blockieren. Mit der Kennzeichnung Hallucination Visual Only können Modder bestimmen, ob der Angriffsmodifikator den Orb-Effekt anwendet, wenn die Caster-Einheit eine Halluzination ist. Sollte die Caster-Einheit eine Halluzination sein, wollt ihr wahrscheinlich nicht, dass sie Flächenschaden verursacht und Tote als Skelette wiederbelebt. Einige unter euch möchten aber vielleicht genau diese Möglichkeit haben. Mit dieser Kennzeichnung wird der Angriffsmodifikator weiterhin auf den Angriffsbaum angewendet, sodass die Caster-Einheit die Animation für einen Kritischen Treffer vortäuschen und ein modifiziertes Geschoss werfen kann. Der Angriff wendet allerdings beim Treffer keinen echten Orb-Effekt an. Die Felder MultishotEffect und MultishotSearchPattern ermöglichen Benutzern, einen Mehrfachschusseffekt auf jedes Ziel im Suchbereich abzufeuern, wenn „Chance“ wahr ist und alle Validatoren erfüllt werden. Wenn das Feld MultishotEffect nicht festgelegt ist, wird stattdessen der ursprüngliche Waffeneffekt des Angriffs ausgeführt. Kann außerdem entscheiden, ob Ziele von Mehrfachschüssen die Treffereffekte erleiden. Kann Waffen nach Index aktivieren, sodass Nahkampfhelden mit dem Orb-Gegenstand ihre versteckte Waffe für Luftangriffe einsetzen können. Wenn dieser Modifikator auf einen Angriff angewendet wird, kann er das Akteurargument WeaponModifier auf das Ereignis WeaponStart legen, sodass das Akteursystem je nach aktuell aktiven Angriffsmodifikatoren unterschiedliche Angriffsanimationen abspielen kann. Hat die Kennzeichnung ‚IsCritical‘. Mit dieser Kennzeichnung kann der Angriff als ‚Critical‘ markiert werden, wodurch die Akteurnachricht „Kritisch“ ausgelöst und die Nachrichten SetText und SetTextlocalized mit der Schadensmenge belegt werden, sodass Modder schwebenden Text für Kritische Treffer erstellen können. Neuer Fähigkeitstyp: CAbilAttackModifier CBehaviorAttackModifier kann die meisten Orb-Fähigkeiten bewältigen, aber bei einigen Fähigkeiten, wie Sengpfeile der Mondpriesterin, benötigt der Orb-Zauber weiterhin eine Hülle, um seinen Autocast ein- und auszuschalten. CAbilAttackModifier ist eine Hülle von CBehaviorAttackModifier, sodass dem Orb eine Hülle für Autocast/manuellen Zauber hinzugefügt werden kann. Kann dem Modifikator Kosten zuweisen, sodass Ressourcen oder Vitalwerte verbraucht werden, wenn die Orb-Fähigkeit gezaubert wird. Hat eine Stufeneigenschaft, sodass sie durch die erlernten Fähigkeiten von Helden Stufen aufsteigen kann. Neuer Akteurtyp: CActorActionOverride Kann die Grafik von Geschossen, Treffern und Schaden von CActorAction überschreiben. Hat die Felder Damage Mode, Impact Model und Missile Model, um festzulegen, welche Modelle überschrieben werden. Wenn CActorAction initialisiert wird, startet es das Ereignis ActionInitModifier. CActorActionOverride kann dieses Ereignis erfassen und sich selbst im Rahmen von CActorAction erstellen. Danach kann es ActionOverrideApplyTo verwenden, um sich selbst auf CActorActions anzuwenden. CActorAction ermittelt die Daten von CActorActionOverride und überschreibt seine Angriffsmodelle. Unterstützung für Dynamische Fähigkeiten Modder können jetzt Auslöser verwenden, um Fähigkeiten von Einheiten zu entfernen oder sie zu ihnen hinzuzufügen. Tauschen von Fähigkeiten Neue Funktion: UnitAbilityChangeLink() Mit dieser Funktion können Benutzer eine existierende Fähigkeit einer Einheit auf eine andere übertragen, wobei sie ihre alten Aufladungen, ihre Abklingzeit und Stufen beibehält. Unterscheidet sich von Katalogersetzung, weil sie auf einzelne Fähigkeiten angewendet wird. Wir haben außerdem das neue Feld Ability Replace in Verhaltenstypen von Energieverbrauchern hinzugefügt, das eine Datenversion dieses Features bietet. Kann nur Fähigkeiten mit derselben CAbil-Klasse der alten Fähigkeit tauschen. Eine zielgerichtete Fähigkeit kann beispielsweise nur mit einer anderen zielgerichteten Fähigkeit getauscht werden. Die Datenversion von Ability Swap betrifft außerdem erlernbare Fähigkeiten von Helden.   Weitergabe von Strukturreferenz in der Auslöser-GUI   Auslöserfunktionen und -aktionen können jetzt Verbundtypen als Parameter definieren. Verbundvariablen können jetzt an Funktionen und Aktionen als Parameter durch Referenz weitergegeben werden. Verbundparameter können gelesen und modifiziert werden. Modifikationen betreffen die Verbundvariablen außerhalb des Funktionsrahmens. Neue Auslöser-APIs: Data Table Instance Funktioniert genau wie Data Tables, mit der Ausnahme, dass ihr mehrere Instanzen haben, ihre Werte zählen und Werte zwischen Datentabellen kopieren könnt. Das alte Data Table ist eine einzelne, globale Datentabelle. Durch das Hinzufügen einer instanziierten Version können Designer ihre Laufzeitdaten besser organisieren. Im Auslöser-Editor könnt ihr außerdem eine GUI-Version finden. Überschreiben von Gegenstands-/Fähigkeitstooltips auf Einheits-/Gegenstandsbasis Neue Natives: UnitSetInfoButtonTooltip, UnitClearInfoButtonTooltip Ermöglicht es Benutzern, Tooltips auf Befehlsschaltflächen zu überschreiben, damit die Tooltips von Gegenständen oder Fähigkeiten einer Einheit angepasst werden können. Im Auslöser-Editor könnt ihr außerdem eine GUI-Version finden: Einheit – Schaltfläche für Einheiteninformationen festlegen – FähigkeitenTooltip Einheit – Schaltfläche für Einheiteninformationen festlegen – SchaltflächenTooltip Einheit – Schaltfläche für Einheiteninformationen festlegen – GegenstandsTooltip Einheit – Schaltfläche für Einheiteninformationen zurücksetzen – FähigkeitenTooltip Einheit – Schaltfläche für Einheiteninformationen zurücksetzen – SchaltflächenTooltip Einheit – Schaltfläche für Einheiteninformationen zurücksetzen – GegenstandsTooltip Funktioniert auch, wenn die Befehlsleiste überschrieben ist, um die Befehlsleisten anderer Einheiten anzuzeigen. Unterstützung von zielbaren Fähigkeiten StarCraft II unterstützt jetzt zielbare Fähigkeiten! Neues Effektkennzeichnungsfeld für Geschoss-Start: SearchFlags Neue Effektsuchkennzeichnung für Geschoss-Start: DynamicSearchArea Dadurch wird die Suche für zielbare Fähigkeiten ermöglicht. Ohne die Kennzeichnung erhaltet ihr ein normales Geschoss. Neue Effektsuchkennzeichnung für Geschoss-Start: ArriveOnSearchHit Konfiguriert, ob das Geschoss „explodiert, wenn es das Ziel trifft“ oder „Ziele durchschlägt“. Siehe unten. Neue Effektfelder für Geschoss-Start: SearchHitArriveEffect Funktioniert nur, wenn ArriveOnSearchHit aktiviert ist. Dieser Effekt wird ausgeführt, wenn das Geschoss explodiert, nachdem es ein Ziel getroffen hat. Hinweis: Dieser Effekt wird am letzten Suchpunkt ausgeführt, bevor das Geschoss erlischt, nicht am Zielpunkt des Geschosses. Die Funktionsweise ist ähnlich wie die eines Endeffekts. SearchEffect Das Geschoss führt diesen Effekt bei jedem Spielzyklus aus und überschreibt die Höhenparameter im Suchbereich anhand der aktuellen Geschwindigkeit des Geschosses. Im Grunde genommen hinterlässt es zwischen Suchen keine Lücken. Hinweis: Der TVE-Cheat wird eine falsche Standardhöhe anstatt der richtigen Höhe des Überschreiben-Sucheffekts anzeigen. SearchMaxCount Bestimmt die maximale Anzahl an Suchen während des Flugs des Geschosses, nicht die maximale Anzahl von Suchen jeder einzelnen Suche. Das Geschoss wird nicht weitersuchen, nachdem es SearchMaxCount Ziele gefunden hat. Wenn SearchMaxCount erreicht wurde und ArriveOnSearchHit nicht festgelegt ist, wird das Geschoss weiter in Zielrichtung fliegen, aber keine Suchen für zielbare Fähigkeiten mehr ausführen. Wenn SearchMaxCount erreicht wurde und ArriveOnSearchHit festgelegt ist, wird das Geschoss explodieren und bei seinem letzten Suchpunkt SearchHitArriveEffect ausführen. Beachtet bitte, dass das nicht das Ziel des Geschosses ist, weil es seinen Zielpunkt noch nicht erreicht hat. Wenn SearchMaxCount 0 ist und ArriveOnSearchHit festgelegt ist, wird das Geschoss die maximale Anzahl an Suchen nicht beschränken. Solange einer seiner Sucheffekte ein Ziel findet, wird das Geschoss explodieren und bei seinem letzten Suchpunkt SearchHitArriveEffect ausführen. Verbessertes Heldensystem Neue CUnit-Klasse: CUnitHero Fünf neue Felder (verglichen mit CUnit): MainAttribute: Eine einzelne Verhaltensverknüpfung, die automatisch beim Erstellen/Morphen einer Einheit angewendet/entfernt wird. Unterscheidet sich nicht von normalen Verhaltensfeldern. Wenn sie allerdings als einzelnes Feld verwendet wird, kann sie einfach über eine Katalogfunktion gelesen werden, um das Hauptattribut eines Helden zu bestimmen. MainAttributeDamageBonus Dieses Feld bestimmt, wie hoch der Bonus auf Angriffsschaden ist, den eine Heldeneinheit pro Punkt in MainAttribute erhält. AttributePointsInfoArray: Legt die Attributpunkte zu Beginn und bei Stufenaufstieg eines Helden basierend auf der aktuellen Stufe des Helden fest. Dadurch werden nur die Attributpunkte festgelegt. Das Attributverhalten wird nicht angewendet, wenn der Held nicht bereits über eines verfügt. LearnInfoArray: Verwendet dieselbe Struktur wie CAbilLearn_LearnInfo. Wenn einer der Indizes eine Fähigkeitenverknüpfung festlegt, überschreibt er die entsprechenden Informationen der Erlernen-Fähigkeit des Helden. Dadurch müsst ihr für unterschiedliche Helden nicht mehr eigene Erlernen-Fähigkeiten erstellen. Die Befehlsschaltfläche von Learn Info kann außerdem automatisch generiert werden, wenn die Kennzeichnung „Create Default Button“ festgelegt ist. TierRequirements Dieses Feld überschreibt die Technologievoraussetzungen von CAbilTrain, wenn die Fähigkeit verwendet wird, um die aktuelle Heldeneinheit auszubilden, und es bereits mehr als ein Tech-Alias der aktuellen Einheit für den aktuellen Spieler gibt. Neue Kennzeichnung für CAbilityRevive: Override Alert Icon Wenn ein Spieler einen Helden mit einer CAbilRevive-Fähigkeit mit einem aktiven Überschreiben-Alarmsymbol wiederbelebt, legt die Fähigkeit das Alarmsymbol auf das Symbol von CAbilRevive fest und nicht auf das Symbol der Heldeneinheit. Neue Natives hinzugefügt: TechTreeSetProduceCap TechTreeGetProduceCap Diese Funktionen können von Auslösern aufgerufen werden, um eine Technologiebegrenzung basierend auf Einheiten, Upgrades, Fähigkeiten, Verhalten oder Effekten festzulegen. Kann auch verwendet werden, um die Ausbildungsgrenze von Helden anzupassen. Grundattributpunkte und Bonusattributpunkte Attributverhalten auf CHeroUnit hat jetzt zwei unterschiedliche Punktwerte: Grund und Bonus. Die Attributpunkte zu Beginn und bei Stufenaufstieg eines Helden (konfiguriert in AttributePointsInfoArray) zählen als Grundwerte, die anderen Punkteveränderungen wie Verhaltensboni werden als Bonuswerte gezählt. In der Einheiteninformationsübersicht werden die Grundattributpunkte als weiße Zahl angezeigt, die Bonusattributpunkte als (+X) in grüner Schrift. Die durch Grundattributpunkte hinzugefügten Boni werden nicht mehr als (+X) in grüner Schrift angezeigt. Stattdessen werden sie zu den Feldern für die Grundwerte von Schaden/Panzerung/Waffengeschwindigkeit addiert. Durch Stärkungseffekte oder Gegenstände hinzugefügte Attribute werden weiterhin als (+X) in grüner Schrift angezeigt. Neue Kennzeichnungen für CEffectApplyBehavior: SetAttributePoints: Wenn diese Kennzeichnung aktiv ist, legt der Effekt Attributpunkte für das Attributverhalten fest. SetAttributeBasePoints: Wenn diese Kennzeichnung aktiv ist, werden Grundpunkte anstatt Bonuspunkte modifiziert. Neues Feld für CabilTrain hinzugefügt: IgnoreUnitCostRequirements Wenn festgelegt, ignoriert die Ausbilden-Fähigkeit Einheitenkosten, solange die Technologievoraussetzungen erfüllt werden. Dadurch können besondere Spielmechaniken wie „Dein erster Held ist kostenlos“ implementiert werden. Verbesserungen am Untermenü für Erlernen-Fähigkeiten Neue Kennzeichnung für Erlernen-Fähigkeiten: ClearSubmenuOnPointsSpent Wenn festgelegt, verlässt eine Einheit, die diese Fähigkeit verwendet, automatisch ihr Befehlsfeld-Untermenü, nachdem alle Fähigkeitspunkte ausgegeben wurden. Neue Kennzeichnung für Erlernen-Fähigkeiten: HideSubmenuOnLearnedAll Wenn festgelegt, wird die Schaltfläche für das Untermenü von Erlernen-Fähigkeiten versteckt, nachdem eine Einheit, die die Fähigkeit verwendet, alle Fähigkeiten erlernt hat, die sie erlernen kann. Es wurde ein Fehler behoben, durch den die Schaltfläche für Erlernen-Fähigkeiten „Erforderliche Stufe:“ in roter Schrift anzeigte, obwohl die Einheit die erforderliche Stufe bereits erreicht hatte. Es wurde ein Fehler behoben, durch den Spieler manchmal die Umschalttaste verwenden konnten, um auf Erlernen-Fähigkeit Stufenvoraussetzungen zu umgehen. Neue Voraussetzung für Einheitenanzahl – Status hinzugefügt: QueuedOrBetterOrRevivable Beim Zählen von Technologieeinheiten werden auch Helden während der Wiederbelebung und wiederbelebbare Helden mitgezählt. Das ist sehr nützlich, wenn ihr Einschränkungen für das Ausbilden von Helden implementieren wollt. Wenn ihr beispielsweise die Einschränkung „Du kannst nicht mehr als 3 Helden ausbilden“ habt, sollen auch Helden mitgezählt werden, die gerade nicht am Leben sind. Heldenstufe und EP-Formel Neues Feld für CBehaviorVeterancy: Levels Legt die Höchststufe eines Helden fest. Dieses Feld kann auch aufgewertet werden, sodass Modder die maximalen Fähigkeitsstufen bei Laufzeit ändern können. Dieses Feld liegt standardmäßig bei 0, wodurch das Stufensystem auf die Version zurückfällt, mit der es davor funktionierte. Neue Felder für CBehaviorVeterancy: MinVeterancyXPBonusPerLevel MinVeterancyXPPreviousValueFactor MinVeterancyXPLevelFactor Wenn die Größe von VeterancyLevelArray kleiner ist als die Anzahl im Feld Levels, generiert das Spiel automatisch das „EP-Minimum“ der zusätzlichen Stufen anhand dieser Faktoren. Diese Formel wird verwendet, wobei X die Stufe ist und F(X) das EP-Minimum der Stufe: F(X) = F(X-1) * MinVeterancyXPPreviousValueFactor + MinVeterancyXPLevelFactor * X + MinVeterancyXPBonusPerLevel Das wird nur verwendet, wenn die Stufe X größer ist als die Größe von VeterancyLevelArray. Andernfalls wird direkt das EP-Minimum aus der Tabelle VeterancyLevelArray herangezogen. EP-Anteile basierend auf Zieltyp Neues Feld für CBehaviorVeterancy: XPReceiveFraction Dieses Feld ist ein Structure Array, mit dem Benutzer für jedes Array einen Zielfilter und einen akkumulierbaren Teilwert festlegen können. Immer wenn ein Held EP erhält, überprüft das Spiel die Zielfilter auf der getöteten Einheit und wendet den EP-Anteil an, wenn das Ziel einem der Filter entspricht. In Kombination mit Akkumulatoren können Benutzer einfache EP-Formeln wie „beschworene Einheiten gewähren halbe EP“ oder „Helden erhalten verringerte EP von Monstern basierend auf der aktuellen Stufe des Helden“ erstellen. Neuer Validator hinzugefügt: CValidatorUnitCompareAbilSkillPoint Überprüft die ausgegebenen, nicht ausgegebenen, zusätzlichen oder gesamten Fähigkeitspunkte einer Einheit. Verbesserungen am Gegenstands- und Inventarsystem Gegenstandssysteme sind aus Rollenspielen nicht wegzudenken, und wir freuen uns, für sie mehr Möglichkeiten im Editor anbieten zu können. Unterstützung für Gegenstände zum Bauen Gegenstände im Inventar einer Einheit können jetzt zum Bauen von Gebäuden verwendet werden. Für diese Gegenstandsfähigkeit kann festgelegt werden, dass der Held sie für den Einsatz kanalisieren muss. Alternativ können Spieler ähnlich wie bei den Protoss Gebäude „heranwarpen“. Diese Art von Gegenstand kann für den Bau von Expansionen nützlich sein. Der Held kann ein tragbares Rathaus kaufen und es an einer neuen Expansion platzieren, worauf sich das Gebäude automatisch selbst baut. Inventar für andere Spieler anzeigen Neue Eigenschaft für CInventoryPanel: ShowForAllPlayers Wenn wahr, können Spieler Einheiten anderer Spieler anwählen, um das Inventar anzusehen. Allerdings könne sie diese Gegenstände nicht verwenden. Neue Eigenschaft für CInventoryPanelInventory: UseAlertIcon Wenn aktiv, zeigen Gegenstände im Inventar den Versionsnamen, das Symbol und Tooltips des Alarms des Gegenstands an. Wenn inaktiv, wird ein normales Symbol angezeigt. Das ist nützlich, wenn ihr Gegenstände erstellen wollt, die in Gegenstandsshops und Inventaren unterschiedliche Beschreibungen haben. Ist standardmäßig deaktiviert. Auf Gegenstände im Inventar Zauber wirken CCommandButton legt jetzt seine Eigenschaft ButtonOtherUnit frei. Jetzt können Benutzer die Gegenstandseinheit (den Gegenstand selbst, nicht den Träger) mit Property Bind entweder an den Ziel-Frame oder an andere Frames binden. Mit dieser Funktionsweise können Benutzer Fähigkeiten auf einen Gegenstand im Inventar wirken, um ihn entweder zu übertragen oder aufzuwerten. Mit diesem Feature können Benutzer außerdem doppelt auf Stadtportale klicken, um automatisch zum Hauptgebäude mit der höchsten Stufe teleportiert zu werden. Global verfügbares Inventarfenster Benutzer können jetzt die Eigenschaft Inventareinheit von CInventoryPanel überschreiben, um das Inventar einer Einheit anzuzeigen, die aktuell nicht ausgewählt ist. Benutzer können außerdem mit Auslösern neue Dialogfenstersteuerungen erstellen. Dies unterstützt Operatoren wie die Befehlsfelddialogsteuerung, die in Legacy of the Void eingeführt wurde. Benutzer können die Einheit festlegen, indem sie „Use SetDialogItemUnit“ auswählen. Wenn dies auf Null gesetzt wird, wird die Einheit zur ausgewählten Anführereinheit zurückgesetzt. Inventar von Käufern anzeigen Bisher wurden neutrale Shops für Gegenstände im Stil von War3 von StarCraft II nur unzureichend unterstützt. Vor diesem Patch konnten Benutzer das Inventar der kaufenden Einheit nicht sehen, wenn sie auf eine Shop-Einheit klickten. Neue Boolesche Eigenschaft für den Frame CInventoryPanel: ShowAgentInventory Das Inventarfenster von neutralen Shops wird das „Inventar des Käufers“ nur anzeigen, wenn dieser Wert aktiv ist und solange das Inventarfenster nicht überschrieben ist, um das Inventar einer bestimmten Einheit anzuzeigen. Daten zu Aufladungen auf CUnit Es wurden Daten zu Aufladungen zu Einheiten und Gegenständen hinzugefügt, sodass Einheits- und Gegenstandsdaten jetzt beim Verkauf von Gegenständen und Einheiten ihre Informationen über standardmäßige Vorräte (wie anfängliche Abklingzeiten in Shops, maximaler Vorrat in Shops usw.) festlegen können. Eine Fähigkeit von CAbilTrain kann gekennzeichnet werden, um diese Standardeinstellungen zu ignorieren und in der Fähigkeit selbst die benutzerdefinierten Einstellungen zu verwenden. Wenn die Kennzeichnung nicht aktiv ist und die Fähigkeit über ihre eigenen Daten verfügt, werden beide Instanzen der Aufladungsdaten zusammengezählt. „Echte“ Powerup-Gegenstände Neuer Gegenstandstyp: CItemAbilPowerUp Powerup-Gegenstände können jetzt als echte Gegenstände implementiert werden und müssen nicht mehr eine Einheit imitieren. CItemAbilPowerUp wird von CItemAbil vererbt. Die einzigen Unterschiede sind, dass sie beim Aufsammeln automatisch verwendet werden und nicht aufgesammelt werden können, wenn das Inventar bereits voll ist. CItemAbilPowerUp kann nur von Einheiten mit einem Inventar verwendet werden. Die Einheit muss außerdem über die Kennzeichnung CanUseItem verfügen. Diese neuen Powerup-Gegenstände sind echte Gegenstände und unterliegen somit Inventarereignissen und können nicht im Beutesystem verwendet werden. CItemAbilPowerUp überprüft, ob die Caster-Einheit die Powerup-Fähigkeit in CitemAbilPowerUp einsetzen kann. Falls nicht, erhaltet ihr eine Fehlermeldung und die Caster-Einheit wird sich nicht zum Gegenstand bewegen. Durch die Kennzeichnung KillAfterUse kann der Gegenstand zerstört werden, nachdem die Caster-Einheit das Powerup verwendet hat. Eine normale Einheit mit Inventar, aber ohne die Kennzeichnung CanUseItem kann Powerups aufsammeln und sie zu einem Helden bringen. Neue Kennzeichnung für EAbilInventoryFlag: ItemDropOnDeath Diese Kennzeichnung zwingt eine Einheit dazu, alle Gegenstände beim Tod fallenzulassen, auch wenn sie wiederbelebt werden kann. Das kann für normale Einheiten mit der Rucksack-Fähigkeit aus Warcraft III nützlich sein. Neue Kennzeichnung für EAbilInventoryFlag: CanUseItem Diese Kennzeichnung gibt an, ob Einheiten Gegenstände verwenden können. Dadurch können Einheiten mit Kurier-Inventaren erstellt werden, die Gegenstände tragen, aber nicht verwenden können. Neue Kennzeichnung für EAbilInventoryFlag: CanApplyEquipBehavior Diese Kennzeichnung gibt an, ob Einheiten von Stärkungseffekten für ihren Status wie z. B. +5 Stärke profitieren können. Auch diese Kennzeichnung ist beim Erstellen von Einheiten mit Kurier-Inventaren hilfreich. Neue Kennzeichnung für CItemAbil: Transient Wenn diese Kennzeichnung aktiv ist, wird die Gegenstandsfähigkeit als Sofort eingesetzt, auch wenn die ursprüngliche Fähigkeit auf dem Gegenstand keine Sofort-Fähigkeit ist. Es wurde ein Fehler behoben, durch den Inventare versuchten, Gegenstände aufzusammeln, obwohl sie während der Annäherung zerstört wurden. Es wurde ein Fehler behoben, durch den CAbilSpawn nicht funktioniert hat. Es wurde ein Fehler behoben, durch den beim Verpfänden von Gegenständen aus der maximalen Verpfändungsdistanz der Gegenstand verlorenging, Benutzer aber keine Ressourcen erhielten. Neue Unternamen für Abil-Akteurereignisse: PawnSource, PawnTarget. Diese werden ausgelöst, wenn ihr einen Gegenstand verpfändet. Neues Feld für CAbilInventory: Requirements Wenn festgelegt, wird die Inventarfähigkeit deaktiviert, bevor ihre Technologievoraussetzungen erfüllt sind. Die Benutzeroberfläche des Inventars wird außerdem ausgeblendet, bevor die Voraussetzungen erfüllt sind. Neue Kennzeichnung für CValidatorUnitInventory: RequireEnabled Wenn aktiv, gibt der Validator nur e_CmdOK aus, wenn die anvisierte Inventarfähigkeit aktiviert ist und ihre Technologievoraussetzungen erfüllt. Für die Antwort auf „Player Use Effect“-Ereignisse gibt es eine neue Auslöser-API, mit der Benutzer den für den Effekt verwendeten Gegenstand (falls es einen Gegenstand gibt) und seinen Gegenstandstyp erfassen können. Gegenstände mit Fähigkeiten können jetzt auswählen, ob sie ihre eigenen Abklingzeitlinks verwenden und so den vererbten Abklingzeitlink der Fähigkeit überschreiben möchten. Unterstützung für neutrale/verbündete Shops Neutrale/verbündete Shops sind neutrale/verbündete Gebäude, mit denen andere Spieler mithilfe von CAbilInteract-Fähigkeiten interagieren können. Das Feld Technologie – Spieler hat jetzt für alle Fähigkeiten eine zusätzliche Option: Caster. Wenn das Feld Technologie – Spieler einer CAbilTrain auf Caster festgelegt wird, überprüft die Fähigkeit die Technologievoraussetzungen des Spielers, der den Auftrag gegeben hat. Das ist nützlich, wenn ihr eine Fähigkeit mit „Einheit/Gegenstand basierend auf dem Technologiebaum des Käufers verkaufen“ erstellen wollt. Neues Feld für CabilTrain: AgentUnitValidator Wenn festgelegt, benötigt diese Fähigkeit immer eine Agenteneinheit, um gezaubert zu werden, und überprüft beim Ausbilden von Einheiten die in diesem Feld festgelegten Validatoren. Mit diesem Feld können jetzt in SC2 ganz einfach „Gegenstandsshop“-Fähigkeiten erstellt werden. Für Gegenstandsshops wollen Benutzer meistens, dass die Käufereinheit des Shops über ein Inventar verfügt, um Gegenstände kaufen zu können. Bisher wurde das von SC2 nicht unterstütz, sodass der Gegenstand immer erstellt wurde, obwohl die Käufereinheit über kein Inventar verfügte. Mit dem Feld AgentUnitValidator können Benutzer Validatoren wie „Einheit verfügt über gültiges Inventar“ und „Inventar ist nicht voll“ hinzufügen. Wenn die Agenteneinheit über kein Inventar verfügt, gibt die Fähigkeit einfach eine Fehlermeldung aus und wird nicht gezaubert. Neue Kennzeichnung für CabilTrain: ChargeCasterPlayer Normalerweise setzen Fähigkeiten aus neutralen Shops voraus, dass die kaufenden und verkaufenden Spieler den Austausch von Ressourcen über die Kennzeichnung „Ally Spending“ teilen. Ist das nicht der Fall, erhält der Käufer die Fehlermeldung „Can’t Spend On that Player“. Standardmäßig teilen neutrale Spieler die Kosten mit allen Spielern. Wenn aber ein Benutzer einen verbündeten Shop, also einen Shop, in dem verbündete Spieler Gegenstände oder Einheiten kaufen können, erstellen möchte, will er wahrscheinlich nicht, dass sich diese Spieler die Ausgaben teilen. Andernfalls könnten Spieler die Ressourcen ihrer Verbündeten ausgeben. Die neue Kennzeichnung ChargeCasterPlayer löst dieses Problem. Wenn aktiv, werden die Kosten des verkauften Gegenstands an den Spieler verrechnet, der den Kaufauftrag gegeben hat, auch wenn Käufer und Verkäufer die Ausgaben nicht teilen. Wenn es andere Spieler gibt, die mit dem kaufenden Spieler Ausgaben teilen, und der kaufende Spieler nicht genug Ressourcen für die Kosten besitzt, verrechnet die Fähigkeit weiterhin die Kosten auf diese anderen Spieler. Neue Kennzeichnung für CAbilInteract: AlwaysShowCommandCard Wenn diese Kennzeichnung aktiv ist, zeigt eine Shop-Einheit ihr Befehlsfeld für alle Spieler an, die damit interagieren können (entschieden durch das Zielfilterfeld von CAbilInteract), auch wenn der Spieler keine gültige Agenteneinheit in der Nähe des Shops besitzt. Wenn ein Spieler also keine Agenteneinheit in der Nähe des Shops besitzt, kann er dadurch trotzdem eine Vorschau dessen erhalten, was der Shop verkauft. Dieser Spieler kann allerdings immer noch nicht das Befehlsfeld verwenden, wenn er die Shop-Einheit nicht kontrolliert, zum Beispiel, wenn er keine Agenteneinheit in der Nähe hat. Es wurde ein Fehler behoben, durch den interagierende Fähigkeiten immer wieder versuchten, eine Einheit zu kaufen, ohne das Feld ValidatorArray zu überprüfen. System zur Verfolgung des Verhaltens von Einheiten Neuer Verhaltenstyp: BehaviorUnitTracker Das Verhalten funktioniert wie eine Einheitenliste. Es kann alle Einheiten speichern, die ihm hinzugefügt wurden, und verfügt über Felder für Validatoren und maximale Anzahl. Jedes Mal, wenn ein Mitglied dieser Liste nicht dem festgelegten Validator entspricht, wird es aus der Liste entfernt. Es gibt außerdem Kennzeichnungen, mit denen Benutzer den Tracker in eine globale oder spielerbasierte Liste umwandeln können, wofür keine Verhaltensinstanz aktiv sein muss. Neuer Akkumulator: CAccumulatorTrackedUnitCount Ermöglicht Benutzern, Akkumulatoren basierend auf der Anzahl der Einheiten in der angegebenen Liste zu verwenden. Neue Effekte: CEffectAddTrackedUnit CEffectClearTrackedUnits, CEffectRemoveTrackedUnit Ermöglicht Benutzern, Einheiten zu einer Liste hinzuzufügen bzw. von ihr zu entfernen. Neuer Effekt: CEffectEnumTrackedUnits Ermöglicht Benutzern, eine Schleife durch die Einheitenverfolgungsliste zu durchlaufen und für jede von ihnen anhand von Filtern Effekte auszuführen. Neue Validatoren: CValidatorCompareTrackedUnitsCount, CValidatorIsUnitTracked Können verwendet werden, um zu zählen, wie viele Einheiten über das Verhalten mitverfolgt werden, und zu überprüfen, ob sich eine Einheit in einer angegebenen Verfolgungsliste befindet. Das Tracker-System ist sehr nützlich, wenn ihr eine „Eine zu vielen“-Zuordnung zwischen Einheiten beibehalten wollt. Zum Beispiel kann es eine Beschwörereinheit zu ihren beschworenen Einheiten verfolgen. Weitere Änderungen am Verhaltenssystem Verhalten – Stapel, Alias Mit diesem Feature können Verhaltensformen basierend auf einer „Stack-ID“ anstatt einer Verhaltens-ID gestapelt werden. Zum Beispiel verfügen in WC3 sowohl der Erzmagier als auch verschiedene Kriecher über eine Version von Brillianzaura. Das sind zwei unterschiedliche Stärkungseffekte, und wenn ihr beide dieser Einheitentypen besitzt, wollt ihr vielleicht nicht, dass Einheiten in der Nähe beide Versionen von Brillianzaura erhalten. In diesem Fall soll die Version des Helden immer Priorität erhalten. Zwei neue Felder für CBehaviorBuff: StackAlias (String) und StackAliasPriority (Integer). Wenn zwei Stärkungseffekte vom selben StackAlias auf dieselbe Einheit angewendet werden, teilen sie sich eine Max. Anzahl und die niedrigere hat Priorität. Wenn ihre kombinierte Anzahl die Max. Anzahl überschreitet, beginnt das Spiel, Stapel zu entfernen, beginnend mit dem Stärkungseffekt mit der niedrigsten StackAliasPriority und dann der kürzesten Dauer. Das geht weiter, bis die kombinierte Anzahl an Stapeln der gemeinsamen Max. Anzahl an Stapeln entspricht. Neues Akteurereignis: BehaviorStackAlias Ermöglicht Benutzern, Verhaltensereignisse (Ein, Aus, Schadensreaktion usw.) basierend auf dem StackAlias des Verhaltens anstatt der Verhaltens-ID zu erfassen. Ermöglicht außerdem das Teilen von Akteuren zwischen Verhaltensformen mit denselben StackAliases, weil ihr wahrscheinlich wollt, dass alle Versionen des Stärkungseffekts Brillianzaura dieselbe Grafik verwenden. Neues Feld für CEffectRemoveBehavior: StackAlias Ermöglicht Benutzern, Stärkungseffekte zu entfernen, die auf StackAlias basieren. Neuer Validator: CValidatorUnitBehaviorStackAlias Ermöglicht Benutzern, Verhaltensstapel von StackAlias zu zählen. Er zählt alle Verhaltensformen auf der Einheit mit dem angegebenen StackAlias und hat die Option, nur aktivierte Verhaltensformen zu zählen. Unterstützung für schwebenden Text als Schadensreaktion von Akteuren Wenn CActorMsgBehavior ein Ereignis mit einer Unterbezeichnung von DamageHandled auslöst, wird durch die Verwendung von SetTextLocalized- und SetText-Nachrichten nach dem Ereignis jetzt automatisch der Text über die modifizierte Schadensmenge festgelegt. Der Schaden ersetzt den Token „%AMOUNT%“ im Zieltext. Das ist bei der Erstellung von schwebendem Text für Schadensreaktionen nützlich. Bessere Unterstützung für Verhaltensereignisse mit Ein/Aus-Akteuren Ein/Aus-Verhaltensereignisse legen jetzt Effektparameter für den letzten angewendeten oder letzten entfernten Stapel fest. Das ist nützlich, um Verhaltensakteure genauer zu konfigurieren. Bisher konnten Benutzer den Caster eines Verhaltens nicht unter Ein-/Aus-Verhaltensereignissen prüfen. Neuer Verhaltensstatus: Cannot Die Markiert eine Einheit als „unsterblich“, solange das Verhalten nicht entfernt wird. Schadensreaktionen können zwar einen ähnlichen Effekt erzielen, aber Todesreaktionen können nur Tod durch Schaden verhindern. Dieser Verhaltensstatus verhindert Tod aus allen Gründen, z. B. wenn die Trefferpunkte auf 0 festgelegt sind. Dieser Status bietet eine einfache Alternative für ein auslöserbasiertes System zur Todesvermeidung. Neuer Verhaltensstatus: Suppress Kill Credit Verhindert, dass eine Einheit dem Spieler, der sie getötet hat, Kill-Prämien oder Ressourcen durch den Kill gewährt. Nützlich für die Erstellung von Halluzinationseinheiten. Neues Feld für CBehaviorBuff: DeathType Dieses Feld kann den DeathType einer Einheit überschreiben und ignoriert die Todesart des Schadenseffekts, der zum Tod geführt hat. Die Todesart „Entfernen“ kann auf diese Weise nicht überschrieben werden. Der Standardwert ist „Unbekannt“ und bedeutet „nicht überschreiben“. Neue Todesart: Reincarnation Verhindert, dass Einheiten beim Tod Beute und Gegenstände fallenlassen. Der Validator CValidatorUnitCompareBehaviorCount und die Effekte CEffectRemoveBehavior und CEffectTransferBehavior teilen sich jetzt die folgenden detaillierten Konfigurationsfelder: BehaviorCategories, BehaviorClass, BehaviorAlignment, ExcludeOriginPlayer, ExcludeCasterUnit, RequireOriginPlayer, RequireCasterUnit Bisher verfügten diese Validatoren/Effekte nur über das Feld CEffectBehavior und diese neuen zusätzlichen Felder waren ausschließlich für CEffectBehavior verfügbar. Diese Neuerungen ermöglichen Benutzern, Verhaltensformen kontrollierter zu zählen, zu entfernen und zu übertragen. Zum Beispiel können Benutzer jetzt Verhaltensstapel entfernen, die von einem Ziel-Unitcaster-Spieler usw. hinzugefügt wurden. Das ist außerdem bei der Implementierung von „schlauen Bannzaubern“ nützlich, wenn beispielsweise nur von gegnerischen Einheiten angewendete Stärkungseffekte entfernt werden sollten. Neues Feld für CValidatorUnitCompareBehaviorCount, CEffectRemoveBehavior und CEffectTransferBehavior: Matches All Bestimmt, ob der Effekt/Validator ausgeführt wird, wenn eines der Konfigurationsfelder erfüllt ist, oder wenn alle Konfigurationsfelder erfüllt werden müssen. Bessere Unterstützung für Leichen Neue Kennzeichnung für CEffectModifyUnit_ModifyFlags: Remove Diese Kennzeichnung entfernt die Einheit direkt aus dem Spiel und zerstört den gesamten Rahmen des Einheitenakteurs. Dies wurde hinzugefügt, weil Spieler den „Entfernen“-Effekt von CEffectDamage nicht verwenden konnten, um eine Leiche zu entfernen. Neuer Einheitenfilter: Decaying Eine Verwesende Einheit ist definiert als Einheit, die sich aktuell auf dem Boden befindet und schon seit einer Weile tot ist. Das steht im Gegensatz zu einer Einheit, die bereits getötet wurde, aber gerade noch zu Boden geht und eine Leiche erzeugt. Technisch gesagt ist das wahr, wenn Todeszeit aktiv und Wiederbelebungsverzögerung abgelaufen ist. Dieser Filter kann eingesetzt werden, damit Fähigkeiten, die Leichen anvisieren, nicht mit Einheiten funktionieren, die kürzlich gestorben sind und noch im Begriff sind, eine Leiche zu erzeugen. Wenn die Todeszeit einer Einheit auf -1 festgelegt wurde, wird die Verwesungsphase übersprungen. Beispielsweise sollten Helden aus Warcraft III niemals verwesen. Neuer Einheitenfilter: Raiseable CEffectModifyUnit kann jetzt festlegen, ob eine Leiche Unraiseable (= unerweckbar) ist. Mit Unraiseable können wir markieren, ob eine Leiche bereits verwendet wurde. Wenn beispielsweise ein Ghul gerade eine Leiche frisst, die Leiche noch existiert, aber der Modder nicht möchte, dass sie wiederbelebbar oder als Untoter wiedererweckbar ist. In diesem Fall kann der Modder Fähigkeiten festlegen, sodass sie nur Erweckbare Leichen akzeptieren und Leichen auf Unerweckbar festlegen, während sie gefressen werden. Neue Kennzeichnung: Allow Corpse Wenn diese Kennzeichnung aktiv ist, können Transportfähigkeiten Leichen als Fracht einladen. System für Angriffstyp, Schadenstyp und Panzerungstyp Neues Feld für CWeapon: Attack Type Modder können die Schadensmultiplikatoren aller Angriffstypen gegen alle Panzerungstypen in den Spieldaten ändern. Der Angriffstyp beeinflusst alle Schadenseffekte im gesamten Waffenbaum, sodass Modder jetzt Schadensmultiplikatoren bei Waffen modifizieren können und nicht mehr jeden Eintrag für Effekte im Effektbaum durchsuchen müssen, um ihre Schadensfaktoren zu ändern. Neues Feld für CUnit: Armor Type Der Panzerungstyp bestimmt die Schadensmultiplikatoren von Waffen, die gegen Einheiten verwendet werden. Neuer Validator: CValidatorUnitArmor Ermöglicht Benutzern, den Panzerungstyp einer Einheit zu überprüfen. Neues Feld für CEffectDamage: Damage Type Modder können die Zielfilter für Schadenstyp in den Spieldaten ändern. Benutzer können alle Schadens- und Flächenschadenseffekte im Spiel konfigurieren, indem sie Zielfilter für Schadenstypen verwenden. Es kann außerdem bestimmen, ob bestimmte Schadenseffekte bestimmten Zielen jemals Schaden zufügen können. Wenn beispielsweise in allen Schadenstypen „Verbündete“ als Ziele ausgefiltert werden, können Benutzer problemlos festlegen, dass alle Waffen im Spiel Verbündeten keinen Flächenschaden mehr zufügen. Das ist bei der Entwicklung eines Co-op-Mods nützlich, weil er auf mehreren anderen Mods aufgebaut werden müsste und Waffen und Zauber in diesen anderen Mods unterschiedliche Effekte für Beschuss durch eigene Einheiten verwenden. Wahrscheinlichkeit für Verfehlen, Blocken und Umlenken von Effekten Die Verhaltensstruktur für Schadensreaktion wurde erweitert und kann jetzt mehr als nur einfache Schadensreaktionen verarbeiten. Wahrscheinlichkeit für Verfehlen Neue Kennzeichnung für CWeapon: NeverMiss Standardmäßig behalten Waffen ihr altes Verhalten bei. Angriffsmodifikatoren können zusätzlich einem Waffeneffektbaum die Eigenschaft NeverMiss hinzufügen. Wenn in einem Waffeneffektbaum festgelegt ist, dass eine Waffe verfehlen kann, wird die Wahrscheinlichkeit für Verfehlen beim Abfeuern der Waffe beim Angreifer und beim Verteidiger überprüft. Danach wird gekennzeichnet, ob der Effekt basierend auf in der Reaktionsstruktur festgelegten Validatoren und Wahrscheinlichkeiten sein Ziel verfehlt. Bodeneinheiten, die Ziele auf höheren Klippenstufen angreifen, können außerdem eine höhere Wahrscheinlichkeit für Verfehlen haben. Diese kann in den Spieldaten modifiziert werden. Wenn der Effektbaum einer Waffe als „Verfehlt“ gekennzeichnet wurde, führt die Waffe keinen Trefferschaden und keine Orb-Effekte aus. Wenn eine Waffe verfehlt, sendet sie ein Akteurwaffenereignis mit „Verfehlt“ als Unterbezeichnung. Auf diese Weise können Modder entscheiden, ob sie dieses Ereignis erfassen möchten, um den schwebenden Text „Verfehlt!“ zu erstellen, oder ob die Einheit einen Ausweicheffekt anzeigen sollte. Chance für Blocken Neues Feld für CEffect: CanBeBlocked Bestimmt, ob der Effekt blockiert werden kann. Ist standardmäßig auf „Aus“ festgelegt. Wenn ein Effekt ausgeführt wird, fragt das Spiel die Reaktionsstruktur der getroffenen Einheit ab und überprüft ihre Chance für Blocken und alle Validatoren. Wenn der Effekt geblockt wird, wird er abgebrochen und nicht ausgeführt. Der Effekt sendet dann ein Effektakteurereignis mit Geblockt als Unterbezeichnung, sodass Benutzer dementsprechende Akteure festlegen können. Dieses Feature ist bei der Entwicklung von Verhaltensformen nützlich, die Zauber blockieren können. Chance für Umlenken Neue Kennzeichnung für CEffect: ValidateImpactDeflection Bestimmt, ob der Effekt umgelenkt werden kann. Ist standardmäßig auf „Aus“ festgelegt. Umlenkung ist beinahe identisch zur Wahrscheinlichkeit für Blocken, mit der Ausnahme, dass der Effekt, der aufgetreten wäre, dupliziert und zurück zum Caster gesendet wird. Der umgelenkte Effekt tauscht die Eigenschaften des Casters und des Ziels und wird als Schuss der ursprünglichen Zieleinheit auf die ursprüngliche Caster-Einheit gewertet. Die Einstellung für Schadensbonus im umgelenkten Effektbaum verwendet weiterhin die Schadensboni des ursprünglichen Casters. Ein weiterer Unterschied zwischen Umlenkung und Blocken besteht darin, dass Effektbäume eine Umlenkung jeweils nur einmal evaluieren. Wenn ein Effekt die Umlenkungsüberprüfung einmal bestanden hat, überprüft der restliche Effektbaum die Chance auf Umlenkung nicht erneut, auch wenn es nachfolgende Effekte im Effektbaum gibt, für die die Kennzeichnung ValidateImpactDeflection aktiv ist. Änderungen am Metamorphosesystem von Einheiten EIN/AUS für Metamorphose/Metamorphose rückgängig machen Neue Kennzeichnung für CAbilMorph: Toggle Neues Feld für CAbilMorph: InforArrayUnmorph Wenn EIN/AUS aktiviert ist, können Metamorphosefähigkeiten verwendet werden, um zwischen zwei unterschiedlichen Arten von Einheitentypenketten hin- und herzuwechseln. Neuer Befehlsindex für CAbilMorph: Unmorph. Wenn bei einer ein-/ausschaltbaren Metamorphosefähigkeit die Einheit die Metamorphose bereits durchlaufen hat, kann für die Fähigkeit weiterhin ein Befehl ausgeführt werden, der die Metamorphose rückgängig macht. Dadurch beginnt die Einheit den Metamorphosevorgang, der im Feld InforArrayUnmorph definiert wurde. In den meisten Fällen sollte das Feld InforArrayUnmorph so festgelegt sein, dass sein letzter Einheitentyp sein Einheitentyp im normalen Zustand ist. Auf diese Weise wird die Einheit mit dem Befehl Unmorph zurück zu ihrem normalen Zustand gewandelt. Neues Feld für CabilMorph: ValidatorArrayUnmorph Überprüft, ob eine Einheit nach der Metamorphose den Befehl Unmorph verwenden kann. Neue Kennzeichnung für CabilMorph: AutoUnmorph Bestimmt, ob die Einheit nach der Metamorphose wenn möglich automatisch versucht, die Metamorphose rückgängig zu machen. Neue Felder für CabilMorph: BehaviorOn/BehaviorOff Wenn festgelegt, wendet diese Fähigkeit den Stärkungseffekt BehaviorOn auf die Einheit an, wenn sie sich in ihrem Zustand nach der Metamorphose befindet. Sie wendet den Stärkungseffekt BehaviorOff an, wenn sich die Einheit in ihrem normalen Zustand befindet. Diese beiden Felder funktionieren nur, wenn die Metamorphosefähigkeit als „EIN/AUS“ gekennzeichnet wurde. Auch wenn eine Einheit direkt als der Einheitentyp nach der Metamorphose erstellt wurde, betrachten Metamorphosefähigkeiten die Einheit weiterhin so, als hätte sie den Metamorphoseprozess durchlaufen. Sie wenden die relevanten Verhaltensformen an und ermöglichen es ihr, den Befehl Unmorph zu verwenden. Tech-Anzahl für Metamorphose Neue Kennzeichnung für CAbilMorph: ProvideSourceUnitTech Wenn aktiviert, überträgt CAbilMorph den Einheitentyp der Quelleinheit auf die Einheit, zu der sie die Metamorphose durchlaufen hat. Die endgültige Einheit erbt automatisch die Einheitenverknüpfung der Quelleinheit als ihren Tech-Alias. Diese Eigenschaft wird durch die gesamte Metamorphosekette vererbt. z. B. Rathaus -> Burg -> Schloss Ein Schloss würde sowohl als Burg als auch als Rathaus gewertet werden. Sogar ein direkt erstelltes Schloss würde sowohl als Burg als auch als Rathaus gewertet werden, auch wenn es nicht direkt aus einem von beiden erzeugt wurde. Warum fügen wir also nicht einfach Rathaus und Burg zum Alias des Schlosses hinzu (indem wir sie dem Tech-Alias-Feld des Schlosses hinzufügen)? Wir wählen diesen indirekteren Weg, weil ProvideSourceUnitTech nur in Kraft tritt, wenn sich die Einheit in ihrem abgeschlossenen Zustand befindet. Nur dann gilt sie in der Tech-Anzahl als Quelleinheit. Würden wir das Feld TechAlias verwenden, würde das Alias in jedem Status existieren, auch wenn die Einheit gerade gemorpht wird (Status InProgress). Wenn ihr in diesem Fall eine Burg zu einem Schloss morpht, würdet ihr euch in einem ungünstigen dazwischenliegenden Status befinden: Weil ihr gleichzeitig über eine abgeschlossene Burg und ein Schloss „InProgress“ verfügt, würde das Zählsystem fälschlicherweise denken, ihr verfügt über eine Burg „InProgress“. Unterstützung für „Bewegen und dann morphen“ Neue Kennzeichnungen für CAbilMorph: RequireAcquiredTarget, RequireAcquiredTargetUnmorph Neue Felder für CAbilMorph: Range, TargetSorts Wenn diese Felder festgelegt sind, wird eine Einheit ihren Autocast-Radius absuchen, versuchen, ein Ziel in Reichweite zu finden, das dem Validator entspricht, und sich dann zu diesem Ziel bewegen. Die Einheit beginnt dann mit der Metamorphose, sobald sie die Zieleinheit erreicht. Das Feld Range gibt die größte Entfernung an, aus der die Caster-Einheit mit dem Metamorphoseprozess beginnen kann. Entlastung von Ressourcen bei Einheiten Neue Einheitenkennzeichnung: NeverThink Normalerweise durchläuft jede Einheit im Spiel in jedem Spielzyklus (0,0625 Spielsekunden) Wegfindung, Scannen nach Gegnern, Erfassen von Fähigkeiten und viele andere logische Überprüfungen. Durch diese Kennzeichnung durchlaufen Einheiten nicht mehr diese Überprüfungen, was auf benutzerdefinierten Karten die Leistung verbessern könnte. Einheiten mit NeverThink können mit Ausnahme von Ressourcenverhaltensformen keine Verhaltensformen und Fähigkeiten haben. Weitere allgemeine Änderungen an Einheiten Unit Max Speed Neues Feld für CUnit: SpeedMaximum Legt die maximale Geschwindigkeit fest, die eine Einheit erreichen kann, Geschwindigkeitsboni mit einberechnet. Neues Verhaltensfeld: MoveSpeedBaseMaximumBonus Ändert die maximale Geschwindigkeit einer Einheit. Neuer Monstertyp für CUnit: Warcraft Das Mob-Feld einer Einheit verfügt jetzt über die Auswahlmöglichkeit „Warcraft“ für Monstertypen. So können Auslöser zwischen Einheiten aus Warcraft und StarCraft unterscheiden. Neue Felder für CUnit: LifeRegenRateNight, EnergyRegenRateNight, ShieldRegenRateNight Können verwendet werden, damit Einheiten der Nachtelfen sich ohne eine Verhaltensform für jede Einheit in der Nacht regenerieren können. Neues Feld für CUnit: BuildTime Ein weiterer Ort, um Bauzeit auf Einheitendaten zu speichern, wodurch Bauzeiten in CAbilBuild, CAbilTrain und CAbilMorph konfiguriert werden können. Neue Kennzeichnung für CAbilBuild und CAbilTrain: IgnoreUnitBuildTime Wenn inaktiv, wird die Bauzeit einer Einheit zur Bauzeit der Fähigkeit hinzugefügt. Neue Datenlistenkennzeichnung für CAbilMorph für jede Phase jeder Sektion: UseBuildTimeArray Für jede Phase mit dieser Kennzeichnung wird die Bauzeit der Einheit zur Dauer der jeweiligen Phase hinzugezählt. Neuer Validator: CValidatorUnitCompareAbilStage Ermöglicht Benutzern, eine Fähigkeitsstufe von CAbilEffect zu validieren. Wenn das Fähigkeitsfeld auf „Nicht vorhanden“ festgelegt ist, wird die Fähigkeitsstufe der gerade gewirkten Fähigkeit validiert. Dadurch können Benutzer jetzt überprüfen, ob eine Einheit mit der aktuell gewirkten Fähigkeit kanalisiert. Neue Zielfilter: Powerup: Wahr, wenn der Feldwert von CUnit_PowerupEffect gültig ist. PowerupOrItem: Ein Powerup oder ein Gegenstand. HeroUnit: Einheiten mit der Kennzeichnung Held. Dies unterscheidet sich vom Attribut „Heroisch“. Neues Feld für CUnit: Unit Level Wenn auf >0 festgelegt, zeigt der Tooltip einer ausgewählten Einheit diese Stufe unter dem Namen der Einheit an. Dieses Feld kann zur Zielsortierung oder zum Validieren verwendet werden. Es kann außerdem in Akkumulatoren eingesetzt werden. Verhalten von Ursprungsgebäuden mit Addons Neues Feld für CUnit: ParentBehaviorLink Wenn ein Addon mit einem Ursprungsgebäude verbunden ist, wird das Verhalten von ParentBehaviorLink auf das Ursprungsgebäude angewendet. Der Caster dieses Verhaltens ist ein Addon, nicht das Ursprungsgebäude. Dadurch kann das Verhalten von ParentBehaviorLink das Ursprungsgebäude basierend auf dem Status des Addons kontrollieren. Metamorphosefähigkeiten können dieses Verhalten validieren und eine Fehlermeldung ausgeben, wenn das Ursprungsgebäude einen Befehl zum Abheben erhalten hat, während das angefügte Addon gerade forscht. CUnit_LifeDamageGain kann jetzt upgegradet werden. CValidatorUnitState wurde stark verbessert und kann jetzt anstatt 1 Einheitenstatus bis zu 100 verschiedene überprüfen. Zum Beispiel: Idle, Jumping, Highlighted, ArmorDisabled, Revivable, Dying, ArmySelect usw. Neuer Validator für Teststatus – Waffentyp: CValidatorUnitTestWeaponType Dadurch können Benutzer überprüfen, ob eine Einheit über einen Nah- oder Fernkampfangriff verfügt. Verfügt über das Feld „Aktivierung benötigt“, um zu bestimmen, ob die Überprüfung deaktivierte Waffen ignorieren sollte. In unseren Beispielmods haben alle Nahkampfhelden aus Warcraft III versteckte Luftabwehrangriffe, die nur mit Orbs freigeschaltet werden können. Durch diese Änderung kann für diese Nahkampfhelden, wie beispielsweise den Bergkönig, festgelegt werden, dass sie nicht über einen Fernkampfangriff verfügen. Weitere Änderungen am Fähigkeitensystem Schaltflächen für Fähigkeiten automatisch generieren Damit Fähigkeiten problemlos auf alle Einheiten angewendet werden können, verfügen jetzt alle Schaltflächen über eine Eigenschaft, mit der Modder die Position ihrer Standardschaltfläche und der Untermenü-ID auf dem Befehlsfeld festlegen können. Bei allen Fähigkeiten können Modder festlegen, ob ein beliebiger Fähigkeitenbefehl automatisch Schaltflächen für Fähigkeiten generieren wird, sodass die Fähigkeit sofort funktioniert, wenn sie einer Einheit hinzugefügt wird. Benutzer müssen diese Schaltflächen und Symbole im Befehlsfeld von Einheiten nicht mehr manuell festlegen. Auslöser-APIs können in Laufzeit Fähigkeiten zu Einheiten hinzufügen und von ihnen entfernen Neue Aktionen für Auslöser-APIs: Unit Add Ability, Unit Remove Ability Einfachere Konfiguration von Stufen Die meisten Fähigkeitstypen verfügen jetzt über das Feld Levels, das direkt die Maximalstufe einer Fähigkeit festlegen kann. In Kombination mit dem Akkumulatorsystem müssen Modder in Zukunft nicht mehr 1.000 Gruppen von Fähigkeiten erstellen, wenn Fähigkeiten über 1.000 Stufen verfügen. Das Feld Levels kann auch aufgewertet werden, sodass Modder die maximalen Fähigkeitsstufen bei Laufzeit ändern können. Wenn das Feld Levels auf den Standardwert 0 festgelegt ist, greift das System für Fähigkeitsstufen auf die vorherige Funktionsweise zurück. Neues Feld für CCharge: TimeDelay Funktioniert für alle Aufladungen von Fähigkeiten/Gegenständen/Verhaltensformen. Funktioniert ähnlich wie TimeStart, betrifft aber nur die erste Aufladung der Fähigkeit, des Gegenstands oder der Verhaltensform. Wenn TimeDelay = 0 ist, wird das Aufladungssystem wie zuvor funktionieren. Wenn TimeDelay >0 ist, wird TimeStart ignoriert. Wenn die Fähigkeit beginnt, Aufladungen zu sammeln, verwendet die Regenerationszeit der ersten Aufladung den Wert von TimeDelay. Alle weiteren Aufladungen verwenden den Wert von TimeUse. Neue Kennzeichnung: IgnoreTimeDelay. Mit dieser Kennzeichnung können Fähigkeiten das in der Einheit festgelegte TimeDelay ignorieren und stattdessen die eigenen Einstellungen der Fähigkeit verwenden. Die Katalogersetzung unterstützt jetzt Item Abilities. Die Ersetzung basiert nicht auf dem Besitzer des Gegenstands, sondern auf dem Benutzer des Gegenstands. Dadurch können unterschiedliche Spieler denselben Gegenstand mit unterschiedlichen Effekten verwenden. Beispielsweise können Modder verschiedene Einheiten erstellen, wenn ein Gegenstand basierend auf der Spezies des Spielers verwendet wird. SEffectParamsShared hat jetzt ein Mitglied aus m_level, das die Stufe der Fähigkeit speichert, die im Effektbaum begonnen hat. Effektbäume können dies als Schnappschuss verwenden, um damit in Verbindung stehende Stufendaten abzurufen. Dadurch behält der Effektbaum weiterhin die alte Stufe der Fähigkeit in Erinnerung, auch wenn sich die Stufe der Fähigkeit nach Beginn des Effektbaums ändert. Akkumulatoren können außerdem diese Daten als Fähigkeitsdaten verwenden. CEffectCreateUnit_SpawnUnit kann jetzt konfiguriert werden, um abhängig von der Stufe des Effektbaums unterschiedliche Einheitentypen zu erstellen. CAbilBheavior kann jetzt unterschiedliche Validatoren für Auto Toggle On und Auto Toggle Off festlegen, anstatt nur einen Validator für Autocast zu verwenden. Neue Fähigkeitenkategorien und Verhaltenskategorien Es wurden mehrere neue Kategorien für Fähigkeiten und Stärkungseffekte hinzugefügt. Verhaltensformen von Stärkungseffekten können jetzt je nach Kategorie Fähigkeiten aktivieren/deaktivieren. Es wurden weitere Voreinstellungen zur Liste der Verhaltenskategorien des Auslöser-Editors hinzugefügt. Sie entspricht jetzt der Liste der Verhaltenskategorien im Daten-Editor.