[FAQ] Bewegungs- und Animationsgeschwindigkeiten Teil 2

Inhaltsverzeichnis

Erster Teil

Vorwort
Einflussfaktoren
Bewegungsgeschwindigkeit
Animationsgeschwindigkeit


Zweiter Teil



Dritter Teil

Sammlung der Breakpoints
Animationsspezifische Werte
WSM-Tabelle
Daten der Sequenzanimationen

Angriffe

Allgemeines

Wie auch die Zauber haben Angriffe den Zweck Gegner zu schädigen und bestehen damit aus mehr als einer graphischen Ausgabe. Sie beinhalten eine Aktion, zum Beispiel das Treffen eines Gegners oder das Erzeugen eines Geschosses. Um das Aktionstick - den Zeitpunkt des Auslösens der Aktion - zu berechnen wird ebenfalls das bereits bekannte System angewandt, welches sich in diesem Fall wie auch schon bei den Zaubern auf das in der animdata.txt markierte FrameDataActionFlag stützt.

Die Angriffsanimationen sind weitaus komplexer als jene, die wir bisher behandelt haben. Da Angriffe in einem solchem Spiel eine wichtigere Rolle spielen, gibt es eine große Vielfalt an einflussreichen Faktoren. Weiters gibt es einige Fertigkeiten, welche ein anderes als das bisher bekannte System zur Berechnung der Geschwindigkeit anwenden. Dazu gehört die Gruppe der Rollbackfertigkeiten (Drachen-Kralle, Eifer, Streuen, Widersetzen, Wut), die generelle Verwandlung in einen Werwolf/Werbären sowie die Fertigkeiten "Babaren-Wut" und "Wirbelwind". Letztere hat überhaupt keine Ähnlichkeit mehr mit dem allgemeinen Berechnungssystem, sondern wird über eine eigene Programmroutine gesteuert.

Bei den Angriffen finden sich auch sehr viele Sequenzen, weil es dank dieser möglich wird, zwei verschiedene Animationen zu verbinden. Darauf basiert zum Beispiel "Ansturm" (Lauf- und Angriffsanimation) oder "Raserei" (links- und rechtshändiger Angriff). Diese Sequenzen erhalten nun allerdings einen Malus auf die Angriffsgeschwindigkeit, doch darauf werde ich später noch genauer eingehen.

Für einen Angriff verwendet man im Regelfall eine Waffe, welche neben eventuell vorhandenem IAS selbst auch Einfluss auf die Geschwindigkeit hat. Jeder Grundwaffe (Phasenklinge, Legendärer Hammer, ...) ist ein gewisser Wert - der Weapon Speed Modifier, kurz WSM genannt - zugewiesen, welcher direkt auf die Acceleration wirkt. Manche sprechen auch von der "Grundgeschwindigkeit" der Waffe, doch da der WSM nur einen von vielen Einflussfaktoren darstellt, ist dieser Ausdruck etwas unglücklich gewählt. Da der WSM innerhalb der Formel subtrahiert wird, bedeutet ein möglichst kleiner Wert eine Erhöhung der Angriffsgeschwindigkeit. Auf D2Wissen.de sind allerdings die Vorzeichen vertauscht, sodass die Waffen durch einen hohen WSM beschleunigt werden.


Animationslänge und Aktionstick

AT = {(Hitshift*FrameDataActionFlag)/[(AnimationSpeed*Acceleration/100)]}
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1

Wie man anhand der Formeln erkennen kann, handelt es sich bei der Acceleration um einen Prozentwert. Dieser muss daher über einen Grundwert verfügen, der dann durch bestimmte Boni und Mali verändert werden kann. Bei der Angriffsgeschwindigkeit gibt es dabei mehrere beeinflussende Faktoren:

Acceleration = Baserate + EIAS + SIAS - WSM (+ ColdEffekt)

Baserate ... Der Grundwert der Beschleunigung verwendet für Angriffe einen Wert von 100.
EIAS ... Sie wird intern aus der IAS berechnet. Dabei wird die so genannte "dimishing returns" Formel (siehe unten) angewandt, die einen sinkenden Grenznutzen aufweist. Anders ausgedrückt braucht man mit steigendem Wert immer mehr IAS um noch eine weitere Änderung der EIAS zu bewirken.

EIAS = [120*IAS/(120 + IAS)]

SIAS ... Die Summe aller Boni und Mali zur Angriffsgeschwindigkeit, die wir von verschiedensten Fertigkeiten (zum Beispiel Fanatismus oder Altern) erhalten. Auch die Gegnerverlangsamung gewisser Gegenstände wird hier verrechnet.
WSM ... Der Weapon Speed Modifier ist ein waffenabhängiger Wert zur Steuerung der Geschwindigkeit. Da er nicht die "dimishing returns" Formel durchläuft, kann er die Geschwindigkeit entscheidend beeinflussen.
ColdEffekt ... Kälteangriffe verfügen meist über eine Wirkzeit, während dieser die Geschwindigkeiten der betroffenen Einheit beeinflusst werden. Während Spieler hier einen konstanten Wert von 50 besitzen, ist jeder Monsterklasse in der MonStats.txt für jeden Schwierigkeitsgrad ein eigener Wert zugewiesen.


StartingFrame

Bisher sind wir immer davon ausgegangen, dass unsere Animation mit dem Frame 00, also der Counterstellung 0 beginnt. Dieses Startingframe, welches den Beginn der Animation kennzeichnet, ist für alle Charaktere und alle Waffengattungen in der D2Common.dll festgehalten und im Regelfall das erste Frame, sprich jenes mit der Bezeichnung "FrameData00". Für die Angriffsanimationen (exklusive Wurfangriffen) mit den Charakterklassen "Amazone" und "Zauberin" kann das StartingFrame allerdings je nach verwendeter Waffenart auch einen anderen Wert annehmen. Dies bedeutet, dass die Animation verkürzt und damit deren Dauer verringert wird.
Die Werte sind für Zauberinen und Amazonen ident, daher gebe ich sie nur einmal an. Alle anderen Charklassen haben immer ein StartingFrame von 0.

Damit müssen wir unsere Formel noch weiter modifizieren, indem wir das StartingFrame von den FramesPerDirection abziehen. Damit erhalten wir die Zahl der wirklich verwendeten Frames und die Formeln sind korrekt:

AT = {(Hitshift*(FramesPerDirection - Startingframe))/[(AnimationSpeed*Acceleration/100)]}
FPA = {(Hitshift*(FramesPerDirection - Startingframe))/[AnimationSpeed*Acceleration/100]} - 1

Acceleration = Baserate + [120*IAS/(120 + IAS)] + SIAS - WSM (+ ColdEffekt)


Auszulesende Werte

Nun benötigen wir wiederum die Werte für FrameDataActionFlag, FramesPerDirektion und AnimationSpeed. Hier wird die Auflistung schon umfangreicher, weil mehrere Animationen für den Angriff genutzt werden können:

~ Die Anordnung der Werte sowie die Animationsbezeichnungen sollten bereits klar sein. Das kleine "x" in den obigen Bezeichnungen ist ein Platzhalter, dort können alle möglichen Zeichen eingesetzt werden. Die Bezeichnung "HTx" meint beispielsweise die Waffenklassen "HT1" und "HT2". Der Platzhalter ist jedoch nicht auf Zahlen beschränkt, er kann auch Buchstaben ersetzen.
~ Jene A2-Animationen, bei denen keine Werte eingetragen sind, verwenden die Werte der zugehörigen A1-Animation. Bei allen nicht aufgeführten A2-Animationen sind die Werte sogar für alle Charaktere mit den zugehörigen A1-Animationen ident.
~ Der Barbarensöldner vollführt mit einem normalen Angriff zwei Schläge, sodass er auch zwei FrameDataActionFlag benötigt. Diese sind in obiger Tabelle durch einen Slash getrennt.


Animationsverwendung

Unsere bisherigen Aktionen (Block, Treffererholung und Zauber) haben, mit Ausnahme von Sequenzen, stets nur eine Animation verwendet. Bei den Angriffen jedoch stehen verschiedene Animationen zur Auswahl. Daher folgt nun eine Auflistung, welche Animation von welchen Angriffen/Fertigkeiten genutzt wird. Diese Angriffe sind dabei der Übersichtlichkeit halber in die verschiedenen Charakterklassen eingeteilt:

A1:
normaler Angriff
"Bogen und Armbrust"-Fertigkeiten, Energieschlag, Kettenblitzschlag, Geladener Schlag, Widersetzen
Tigerschlag, Kobraschlag, Phönixschlag
Hieb, Lähmen, Konzentrieren, Amok
Barbarenwut, Zerfleischen, Feuerklauen, Wut
Giftdolch
Opfer, Eifer, Rache, Bekehrung

A2:
normaler Angriff

KK:
Drachen-Kralle, Drachen-Schwanz

S1:
(Ausweichen, Meiden, Entrinnen)
Schildschlag

S2:
Stationärfallen, Feuerstoß, Schocknetz, Klingenwächter

S3:
Sekundärschlag des Barbaren
Hunger, Tollwut

S4:
Sekundärschlag der Assassine
Sekundärwurf des Barbaren

TH:
Wurf
Giftwurfspieß, Blitzschlag, Pestwurfspieß, Blitzendes Unheil


Sequenzen

Viele Angriffe verwenden nicht eine komplette Animation, sondern sind aus einzelnen Frames einer oder mehreren Animationen zusammengesetzt. Beispiele dafür sind "Ansturm", welche neben dem Angriff auch Frames der RN-Animation nutzt oder "Raserei", welche für den Erst- und Zweitschlag Teile unterschiedlicher Animationen (A1 und S3) nutzt. Über die von Charakteren verwendeten Sequenzen gibt es keine Informationen in der animdata.d2, sondern man muss sie aus der D2Common.dll auslesen, was ungleich schwerer ist. Für die Sequenzen der Monster (zu denen auch die Söldner zählen) gibt es eine eigene Regelung, denn deren Sequenzdaten sind aus der MonSeq.txt auszulesen. Die Zuordnung der Sequenzen zu den einzelnen Fertigkeiten erfolgt in der Skills.txt. Einerseits haben Sequenzen in der Spalte "anim" das Kürzel "SQ" eingetragen und andererseits enthält die Spalte "seqnum" den Index der jeweils verwendeten Animation.
Aus Platzgründen füge ich die Informationen bezüglich der von Charakteren verwendeten Sequenzen nicht hier ein, sondern verweise an dieser Stelle nur auf die Auflistung im letzten Teil dieser FAQ. Zumeist ist jede Sequenz nur einer bestimmten Fertigkeit zugewiesen, sodass die dortigen Bezeichnungen klar sein sollten. Daher erspare ich es mir alle Fertigkeiten mit der verwendeten Sequenz hier anzugeben und weise stattdessen nur darauf hin, dass die Sequenz Nummer 16 (von mir als "Charger" bezeichnet) für die Fertigkeiten "Feuerfäuste", "Donnerklauen", "Eisklingen" und "Drachen-Klaue" verwendet wird.

Für die Berechnung der Animationsdauern ist zu berücksichtigen, dass beinahe die bekannte Formel gilt, das letzte Tick in diesem Fall jedoch nicht wegfällt. Weiters haben Charaktere - im Gegensatz zu Söldnern und Monstern - für Angriffs-Sequenzen einen Malus von 30 auf die Acceleration.

AT = {(Hitshift*FramesPerDirection)/[(AnimationSpeed*(Baserate - 30 + EIAS + SIAS - WSM)/100)]}
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*(Baserate - 30 + EIAS + SIAS - WSM)/100]}


Zusammenfassung

AT = {(256*(FrameDataActionFlag - StartingFrame))/[(AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100)]}
FPA = {(256*(FramesPerDirection - StartingFrame))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]} - 1
EIAS = [120*IAS/(120 + IAS)]

Für Spieler-Sequenzen:

AT = {(256*FrameDataActionFlag)/[(AnimationSpeed*(70 + EIAS + SIAS - WSM (+ ColdEffekt))/100)]}
FPA = {(256*FramesPerDirection)/[AnimationSpeed*(70 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}
EIAS = [120*IAS/(120 + IAS)]

FramesPerDirection ... Die Anzahl an Einzelbildern der Animation, abhängig von Charakterklasse und Waffentyp.
StartingFrame ... Jenes Frame, mit dem die Animation beginnt. Ist für die normale Angriffsanimation von Amazonen und Zauberinnen für bestimmte Waffen größer als 0.
AnimationSpeed ... Der Grundwert des Counter-Anstiegswertes, wird ebenso durch die Animation bestimmt.
SIAS ... Die Summe aller Fertigkeitsboni und -mali zur Angriffsgeschwindigkeit, inklusive dem Malus der Gegnerverlangsamung.
WSM ... Die Geschwindigkeitsmodifikation durch den Grundtyp der Waffe.
ColdEffekt ... Geschwindigkeitsmalus durch Kältedauer, der Wert beträgt für Charaktere -50.

Dual-Waffen Modus

Grundlagen und Definitionen

Der Barbar und die Assassine haben die Möglichkeit zwei Waffen zur gleichen Zeit anzulegen, wodurch sie auch zwei WSM erhalten. In einem solchen Fall wird nicht mit den normalen WSM gerechnet, sondern aus beiden Werten werden zwei neue WSM errechnet. Bevor wir allerdings zur Berechnung dieses Wertes kommen, erkläre ich noch die Grundlagen für die Benutzung zweier Waffen.




Wir haben im Inventar zwei Waffenslots, links und rechts jeweils einen. Legen wir eine Waffe in einen der beiden Slots, so wird diese von unserem Charakter angelegt und erscheint in der rechten Hand des Charakters. Zwischen den Waffenslots und den Händen des Charakters gibt es allerdings keine Verbindung. Bei der Entscheidung welche Waffe in welcher Hand des Charakters abgebildet wird, spielt nur die Anlegereihenfolge eine Rolle.

Die zuerst angelegte Waffe - man spricht von der Primärwaffe - wird immer in der rechten Hand des Charakters angelegt. Die Sekundärwaffe, welche zuletzt angelegt wird, landet dann natürlich in der linken Hand des Charakters.

Wir können uns daher jederzeit aussuchen, in welchem Waffenslot wir unsere Primärwaffe tragen und es gibt im Regelfall keine Verbindung zwischen den beiden Händen des Charakters und den Waffenslots. Allerdings gibt es auch hier eine Ausnahme. In bestimmten Situationen (Aufsammeln der eigenen Leiche, automatischer Waffenwechsel oder schwere Lags) werden unsere Gegenstände in einer vorgegebenen Reihenfolge vom Programm angelegt. In dieser Reihenfolge wird der linke Waffenslot vor dem Rechten überprüft, sodass in einem solchen Fall die Waffe im linken Waffenslot als neue Primärwaffe in der rechten Hand des Charakters angelegt wird. Die Position der Waffen innerhalb der Waffenslots ändert sich dabei natürlich nicht.




Manche Spieler sehen wegen der Anordnung der Slots einen fiktiven Charakter im Inventar, mit Blickrichtung aus dem Monitor hinaus. Daher bezeichnen sie den linken Waffenslot als rechte Hand bzw umgekehrt den rechten Waffenslot als linke Hand. Diese Definition hat allerdings nichts mit der graphischen Ausgabe des wirklichen Charakters zu tun, sondern ist nur eine andere Blickweise für die Benennung der Waffenslots. Ich halte diese Darstellung für zu umständlich (und generell merkwürdig) und werde sie deshalb nicht benutzen. Trotzdem sollte man sie kennen um Bescheid zu wissen, falls jemand anderes diese Darstellung verwendet.

Damit komme ich zur Definition der beiden Begriffe "Erstschlag" und "Zweitschlag". Wie der Name schon vermuten lässt, handelt es sich dabei um die Reihenfolge der Schläge. Allerdings geht es dabei nicht um den Schlag an sich, sondern um die Schlaganimation. Die Fertigkeit "Raserei" beispielsweise beinhaltet zwar zwei Schläge, doch diese sind beide in die selbe Animation eingebunden und damit hat "Raserei" keinen Zweitschlag. Daher ist die einzige Fertigkeit mit einem Zweitschlag der normale Angriff, denn dieser hat für jeden Schlag eine seperate Animation. Der Zweitschlag ist in diesem Fall natürlich der Schlag mit der Sekundärwaffe.

Beim Einsatz zweier Waffen wirken offensive Eigenschaften der Waffen nur für den Angriff mit der jeweiligen Waffe. Die Angriffsgeschwindigkeit bildet hier keine Ausnahme, daher kann das WIAS beider Waffen nicht einfach addiert werden. Das Spiel unterscheidet hier zwischen den Angriffsanimationen, weswegen das WIAS der Primärwaffe nur auf den Primärschlag und jenes der Sekundärwaffe nur auf den kaum verwendeten Zweitschlag wirkt.


Berechnung des WSM

Da wir nun die Grundlagen geklärt haben, können wir mit der Berechnung fortfahren. Wie ich schon erwähnte, muss der WSM bei gleichzeitiger Benutzung zweier Waffen neu berechnet werden. Dabei müssen wir zwischen Erst- und Zweitschlag unterscheiden und auch die Position der Waffen in den Waffenslots spielt dabei eine Rolle.

Primärwaffe im linken Waffenslot

Wir legen unsere Primärwaffe in den linken Waffenslot, die Sekundärwaffe danach in den Rechten. Für unseren Erstschlag erhalten wir somit folgende Formel:

WSM = (WSM_links + WSM_rechts)/2

Kurz gesagt, einfach die Mittelung beider WSM. Für unseren Zweitschlag sieht es allerdings anders aus:

WSM = (WSM_links + WSM_rechts)/2 + WSM_rechts - WSM_links

Hier fließen additiv zum Mittelwert noch die beiden WSM mitein. Durch geschickte Waffenwahl kann somit ein sehr guter WSM erreicht werden, wodurch man sich einiges an IAS ersparen kann.
Allerdings können wir davon nicht wirklich profitieren, da wir nur beim normalen Angriff mit zwei Waffen einen Zweitschlag ausführen. Der Grund aus dem ich es trotzdem erwähne, wird nun im nächsten Abschnitt beim Ausrüsten der Primärwaffe im rechten Waffenslot ersichtlich.


Primärwaffe im rechten Waffenslot

Diesmal wird unsere Primärwaffe im rechten Slot angelegt, die Sekundärwaffe anschließend im Linken. Damit werden die beiden Formeln aus dem vorherigem Abschnitt vertauscht, die Berechnung für unseren Erstschlag lautet demnach:

WSM = (WSM_links + WSM_rechts)/2 + WSM_rechts - WSM_links

Damit sind auch für den Erstschlag sehr gute Werte erreichbar. Für den kaum verwendeten Zweitschlag erhalten wir wiederum die einfache Mittelung:

WSM = (WSM_links + WSM_rechts)/2


Bei diesen Formeln darf man nicht vergessen, dass der WSM in der Berechnung abgezogen wird und unsere Animation damit bei geringerem WSM schneller ist.

Das Anlegen der Primärwaffe im rechten Waffenslot erfolgt im einfachsten Fall durch einen Doppelklick auf den linken Waffenslot. Die darin liegende Waffe wird für einen Moment entfernt, sodass die Waffe im rechten Waffenslot zur Primärwaffe wird. Sollte man sich entscheiden diese Möglichkeit zu nutzen um den WSM aufzubessern, so sollte man nicht auf das Umrüsten nach dem Waffentausch oder dem Aufsammeln der Leiche vergessen.


Beispiele

1) Wir spielen einen Barbaren und legen zuerst eine Berserkeraxt im linken Waffenslot und anschließend eine Phasenklinge im rechten Waffenslot an. Wir verwenden die Fertigkeit "Raserei" und müssen daher mit folgendem WSM rechnen:

linker Waffenslot: Berserkeraxt => WSM-links = 0
rechter Waffenslot: Phasenklinge => WSM-rechts = -30

Verwendung von Raserei => Erstschlag
Primärwaffe links angelegt => einfache Mittelung beim Erstschlag

WSM = (WSM_links + WSM_rechts)/2
WSM = (0 + (-30))/2
WSM = -15


2) Unsere Assassine legt ihre Primärwaffe - ihre Runenklauen - in den rechten Waffenslot und verwendet als Sekundärwaffe eine Kriegsfaust. Als Verfechterin des Individualismus tritt sie den Mächten den Bösen nur mit ihrem normalen Angriff entgegen.

rechter Waffenslot: Runenklauen => WSM_rechts = -30
linker Waffenslot: Kriegsfaust => WSM_links = 10

Verwendung des normalen Angriffes => Erst- und Zweitschlag
Primärwaffe rechts angelegt => erweiterte Formel für Erstschlag und Mittelung für den Zweitschlag

Erstschlag:

WSM = (WSM_links + WSM_rechts)/2 + WSM_rechts - WSM_links
WSM = (10 + (-30))/2 + (-30) - 10
WSM = -10 - 40
WSM = -50

Zweitschlag:

WSM = (WSM_links + WSM_rechts)/2
WSM = (10 + (-30))/2
WSM = -10


Zusammenfassung

Waffenslot links/rechts: Waffenslot im Inventar
Hand links/rechts: Hände des Charakters; rechts Primärwaffe, links Sekundärwaffe

IAS der Primärwaffe zählt nur auf den Erstschlag, jenes der Sekundärwaffe nur für den Zweitschlag

Erstschlag der Primärwaffe im linken Slot: WSM = (WSM_links + WSM_rechts)/2
Erstschlag der Primärwaffe im rechten Slot: WSM = (WSM_links + WSM_rechts)/2 + WSM_rechts - WSM_links

Für verwandelte Charaktere gilt hier allerdings eine Ausnahmeregelung, welche im entsprechenden Kapitel näher erläutert wird.

Auslösung von Fertigkeiten während des Angriffs

Mit dem Erscheinen der Erweiterung "Lord of Destruction" wurden unter anderem die ctc-Fertigkeiten (chance to cast) eingeführt. Während bestimmter Aktionen (Angriff, Treffer, Sterben,...) besteht durch diese Eigenschaft nun die Chance, eine vordefinierte Fertigkeit auszulösen. Die Grundlagen bezüglich Auslösung sowie die Gegenstände mit dieser Eigenschaft können hier nachgelesen werden, wir beschäftigen uns nun mit deren Auswirkungen auf die Angriffsgeschwindigkeit.

Die relevanten Auslöser sind jene, welche durch unseren Angriff aktiviert werden - sprich "auf Angriff" und "auf Schlag" ("bei Kill" können wir vernachlässigen). Diese Fertigkeiten werden im Aktionstick ausgelöst, sobald der Gegner getroffen wird. Da wir bereits eine Animation mitsammt Zeitpunkt der Auslösung haben, ist eine weitere Animation eigens für die ctc-Fertigkeit natürlich nicht nötig. Somit erfolgt keine zweite Animation und der Angriff bzw. die Angriffsreihe wird auch nicht unterbrochen. Eine Beeinflussung der Angriffsgeschwindigkeit erfolgt daher einzig und allein durch ein eventuelles Cast Delay der ausgelösten Fertigkeit. Dabei können wir praktischerweise alle Fertigkeiten gleichermaßen betrachten, weil das Cast Delay in einem solchen Fall erneut bei 12 Ticks begrenzt wird. Für die Dauer der Verzögerung wird bloß das manuelle Auslösen einer Fertigkeit unterbunden, die ausgelöste Fertigkeit selbst wird jedoch nicht von Seiten des Spielers ausgelöst und unterliegt daher nicht der Verzögerung. In einer Schlagserie kann der Zauber vor Ablauf der Verzögerung also neu ausgelöst werden, setzt damit allerdings auch wieder das Cast Delay neu.

Wie bereits erwähnt, wird das Cast Delay nun auf 12 Ticks begrenzt. Da dieses jedoch schon während dem abschließenden Animationsteil kleiner wird, brauchen wir eine eigene Formel, um die effektive Verzögerung zu berechnen. Relevant ist dabei, dass der Counter in diesem Fall zu Beginn des Aktionsticks zu zählen beginnt, sodass unsere Formel folgendermaßen lautet:

CD_eff = CD - {(256*FramesPerDirection)/Counter-Anstiegswert} + {(256*FramesDataActionFlag)/Counter-Anstiegswert}

Genau genommen gilt dies nur für einen Angriff, welcher selbst kein Cast Delay besitzt. Falls unser eigener Angriff ein Cast Delay hat und durch eine solche Eigenschaft eine weitere Fertigkeit mit Cast Delay auslöst, so wird unser ursprünglicher Angriff durch sein eigenes Cast Delay verzögert, während alle anderen Angriffe durch das getriggerte Cast Delay gestoppt werden. Allerdings ist dieser Fall nicht alzu relevant, weshalb ich ihn hier nur kurz erwähne.

Rollback

Verschiedene Fertigkeiten (zum Beispiel "Eifer" oder "Wut") beinhalten mehrere Schläge pro Animation, wobei jeder Schlag die selbe Animation verwendet, welche an einer bestimmten Stelle abgebrochen wird. Man spricht dabei von einem Rollback, einem Zurücksetzen der Animation auf ein vorhergehendes Frame. Um zu wissen auf welches Frames zurückgesprungen wird, braucht man den Wert "SkillRollback". Diesen findet man für manche Fertigkeiten in der Skills.txt, doch der dort angegebene Wert dient nur der graphischen Ausgabe des Angriffs. Die für die Animationslänge relevanten Werte sind hardcoded und lauten:

Eifer, Wut, Drachen-Kralle: 100%
Streuen: 50%
Widersetzen: 60%

Diese Werte (es handelt sich dabei nicht um Chancen) werden nun vom Grundwert, welcher bei 100 liegt, abgezogen. Wir erhalten damit den Wert "Rollback":

Eifer, Wut, Drachen-Kralle: 0%
Streuen: 50%
Widersetzen: 40%

Nun gibt es eine Programmroutine, welche bei jedem Schlag - ausgenommen dem Endschlag - durchlaufen wird. Die Routine wird beim Aktionstick gestartet und bezieht sich auf jenes Frame, welches zu diesem Zeitpunkt abgespielt wird (zumeist auf das FrameDataActionFlag). Dieses wird zur Ermittelung des Rücksprungframes mit dem Wert "Rollback" multipliziert:

Rücksprungframe = [AktionsFrame*Rollback/100]

Das Ergebniss muss natürlich ganzzahlig sein und wird daher abgerundet. Um für die vorherige Berechnung das dargestellte Frame aus dem Counter-Wert zu ermitteln, mussten wir den Counter durch 256 dividieren, weil es eben 256 mögliche Counterstellungen pro Frame gibt. Nachdem wir nun das Rücksprungframe kennen, multiplizieren wir es zum Ausgleich wieder mit 256 und erhalten damit erneut den Counter-Wert, mit dem wir ab dem nächstem Tick wie gewohnt fortfahren. Ein Rücksprungframe von 03 bedeuten somit, dass die ersten 3 Frames übersprungen werden und die neue Animation mit dem Anfang des vierten Frames beim Counterwert 768 beginnt.

Um den Rollback etwas ausführlicher zu beschreiben, unterteile ich ihn nun zuerst nach dem Rollback-Wert. Bei einem Wert von 100% (betroffen sind Eifer, Wut und Drachen-Kralle) haben wir einen kompletten Rollback, der wesentlich einfacher zu verstehen ist. Hat der Rollback einen anderen Wert, so wird er komplizierter, weil auch die Vorgeschichte eine Rolle spielt.


kompletter Rollback

Der komplette Rollback definiert sich dadurch, dass immer auf das erste Frame zurückgesprungen wird und wir damit die Vorgeschichte nicht beachten müssen. Dazu muss unser Rollback-Wert natürlich 0% betragen, was einen SkillRollback von 100% bedeutet, welchen die Fertigkeiten Eifer, Wut und Drachen-Kralle besitzen.

Der Rollback wird ausgelöst, sobald der Counter-Aktionswert erreicht/überschritten wird, also sobald das FrameDataActionFlag oder ein höheres Frame abgespielt wird. Er bezieht sich auf genau dieses Frame, sodass bei hohem Counter-Anstiegswert das aktuelle Frame nicht das FrameDataActionFlag sein muss. Die Rollback-Routine lässt sich in folgender Formel mathematisch anschreiben:

Rücksprungframe = [CurrentFrame*Rollback/100]

CurrentFrame ... Das momentan abgespielte Frame, bei Rollback-Auslösung oftmals ident mit dem FrameDataActionFlag
Rollback ... Der vom Skill vorgegebene Wert, der das Rücksprungframe maßgeblich bestimmt

Wir gehen beim kompletten Rollback von einem "Rollback" mit 0% aus, sodass das Rücksprungframe unabhängig vom CurrentFrame (also der Vorgeschichte) immer das erste, also das Frame 00 ist. Damit sind alle Folgeschläge gleich lang, weil alle an der selben Stelle beginnen.
Falls unser StartingFrame bei 0 liegt, beginnt auch der Erstschlag bei Frame 00 und hat damit ebenfalls die Länge eines Folgeschlages. Bei einem StartingFrame > 0 ist unsere Animation etwas kürzer und der Erstschlag wird damit schneller ausgeführt als die Folgeschläge.
Nach den Folgeschlägen, also vor Beginn des Endschlages, fallen wir durch den letzten Rollback wieder auf das Frame 00 zurück und für den Endschlag gibt es keinen Rollback mehr. Damit wird die volle Animation durchlaufen und der Endschlag entspricht somit einem normalen Angriff. Das StartingFrame gilt natürlich nur für den Animationsstart und hat mit dem Rollback nichts zu tun, sodass wir auch bei einem StartingFrame von 2 nach dem Rollback bei Frame 00 landen.

Wie bei den normalen Angriffen können wir auch hier die Angriffsdauern über den internen Ablauf mittels Counter bestimmen. Dazu gehe ich im folgenden Beispiel von diesen Werten aus:

StartingFrame = 02
FrameDataActionFlag = 04
FramesPerDirection = 7
Acceleration = 150
AnimationSpeed = 256

Counter-Anstiegswert = [AnimationSpeed*Acceleration/100] = 384
Counter-Endwert = Hitshift*FramesPerDirection = 1792
Counter-Aktionswert = HitShift*FrameDataAcionFlag = 1024

Außerdem rechne ich mit nur einem Folgeschlag um den Platzverbrauch zu minimieren. Beim kompletten Rollback spielt das allerdings keine Rolle, weil alle Folgeschläge gleich lang sein müssen.

Tick 1:
StartingFrame = 2 => Startwert des Counters = 2*256 = 512
Counter wird um 384 erhöht und beträgt damit 896.
Counterstellung 896 bedeutet Abspielen von Frame 03
Counter-Aktionswert weder erreicht noch überschritten, daher kein Abbruch des Erstschlages

Tick 2:
Counter wird um 384 erhöht und beträgt damit 1280.
Counterstellung 1280 bedeutet Abspielen von Frame 05
Counter-Aktionswert wurde überschritten, daher wird das Rücksprungframe errechnet, welches hier natürlich immer Frame 00 ist
Das FrameDataActionFlag löst unseren Angriff aus, der Erstschlag endet nun.

Tick 3:
Wir starten dank des kompletten Rollbacks wieder bei Frame 00 und damit bei Counterstellung 0*256 = 0
Counter wird um 384 erhöht und beträgt damit 384.
Counterstellung 384 bedeutet Abspielen von Frame 01
Counter-Aktionswert weder erreicht noch überschritten, daher kein Abbruch des Folgeschlages

Tick 4:
Counter wird um 384 erhöht und beträgt damit 768.
Counterstellung 768 bedeutet Abspielen von Frame 03
Counter-Aktionswert weder erreicht noch überschritten, daher kein Abbruch des Folgeschlages

Tick 5:
Counter wird um 384 erhöht und beträgt damit 1152.
Counterstellung 1152 bedeutet Abspielen von Frame 04
Counter-Aktionswert wurde erreicht, daher wird das Rücksprungframe errechnet, welches hier natürlich immer Frame 00 ist
Das FrameDataActionFlag löst unseren Angriff aus, der Folgeschlag endet nun.

Tick 6:
Wir starten dank des kompletten Rollbacks wieder bei Frame 00 und damit bei Counterstellung 0*256 = 0
Counter wird um 384 erhöht und beträgt damit 384.
Counterstellung 384 bedeutet Abspielen von Frame 01
Counter-Endwert weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 7:
Counter wird um 384 erhöht und beträgt damit 768.
Counterstellung 768 bedeutet Abspielen von Frame 03
Counter-Endwert weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 8:
Counter wird um 384 erhöht und beträgt damit 1152.
Counterstellung 1152 bedeutet Abspielen von Frame 04
FrameDataActionFlag wurde erreicht, daher erfolgt nun unser Angriff
Counter-Endwert weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 9:
Counter wird um 384 erhöht und beträgt damit 1536.
Counterstellung 1536 bedeutet Abspielen von Frame 06
Counter-Endwert weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 10:
Counter wird um 384 erhöht und beträgt damit 1920.
Counter-Endwert (1792) wurde überschritten, daher sofortiger Abbruch des Endschlages
Start der nächsten Animation noch in diesem Tick, sodass es nicht mehr zum Endschlag zählt

Wir erhalten damit eine Angriffsreihe von 2/3/4 Ticks für Erstschlag/Folgeschläge/Endschlag. Damit wirkt sich das StartingFrame durch eine Verkürzung des Erstschlages von 3 auf 2 Ticks aus und durch das Auslaufen der Animation beim Endschlag dauert dieser 1 Tick länger als die Folgeschläge.

Da wir uns diese Arbeit natürlich nicht für alle möglichen Werte machen wollen, brauchen wir eine Umsetzung dieses Ablaufes auf eine Formel - also jeweils eine für Erstschlag, Folgeschläge und Endschlag.


Erstschlag

Der Erstschlag endet zu dem Zeitpunkt, an welchem wir unseren Gegner wirklich treffen. Dafür haben wir bereits eine Formel aufgestellt und müssen bloß noch ein eventuell vorhandenes StartingFrame berücksichtigen:

FPA = {(Hitshift*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*Acceleration/100]}

Folgeschläge

Die Folgeschläge arbeiten nach dem selben Prinzip wie der Erstschlag, nur spielt hier das StartingFrame keine Rolle, weil der Animationsstart nun durch den Rollback vorgegeben wird.

FPA = {(Hitshift*FrameDataActionFlag)/[AnimationSpeed*Acceleration/100]}

Endschlag

Der Endschlag startet beim kompletten Rollback mit dem Frame 00 und ist (unter Vernachlässigung des StartingFrames) eigentlich ein normaler Angriff, sodass wir die bereits bekannte Formel verwenden können:

FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1


Zusammenfassung

Erstschlag = {(256*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}

Folgeschläge = {(256*FrameDataActionFlag)/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}

Endschlag = {(256*FramesPerDirection)/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]} - 1

FramesPerDirection ... Die Anzahl einzelner Frames, aus der eine Animation besteht.
FrameDataActionFlag ... Jenes Frame bei dem die in der Animation enthaltene Aktion ausgeführt wird.
StartingFrame ... Dies ist das Frame, bei dem unsere Animation beginnt. Es liegt bei allen Charakterklassen außer den Amazonen und Zauberinen bei 0.
AnimationSpeed ... Sozusagen der Grundwert des Counter-Anstiegswerts, der bestmmt wie schnell eine Animation prozentuell gesehen abgespielt wird.
EIAS ... Wird über die "dimishing returns"-Formel aus der IAS errechnet
SIAS ... Sämtliche Boni und Mali zur Angriffsgeschwindigkeit von Fertigkeiten, inklusive der Gegnerverlangsamung diverser Gegenstände.
WSM ... Ein waffentypabhängiger Wert zur Steuerung der Angriffsgeschwindigkeit.


allgemeiner Rollback

Bisher sind wir von einem Rollback mit 0% und dem daraus resultierendem kompletten Rücksetzen ausgegangen. Allerdings gibt es auch Fertigkeiten, welche einen Rollback von 50% (Streuen) bzw 40% (Widersetzen) aufweisen. Diese sind etwas schwerer zu verstehen als der komplette Rollback, weil auch die Vorgeschichte nun eine Rolle spielt und wir mehr Möglichkeiten haben, da die Folgeschläge nicht gleich lang sein müssen.

Auch hier wird zuerst der Rollback aus dem SkillRollback errechnet und natürlich gilt auch die Rollback-Routine weiterhin:

Rücksprungframe = [CurrentFrame*Rollback/100]

CurrentFrame ... Das momentan abgespielte Frame, bei Rollback-Auslösung oftmals ident mit dem FrameDataActionFlag
Rollback ... Der vom Skill vorgegebene Wert, der das Rücksprungframe maßgeblich bestimmt

Die Schrittweite unserer Frames ist unser Hitshift von 256, es gibt also für jedes Frame 256 Counterstellungen. Wenn wir nun einen Counter-Anstiegswert > 256 haben, kann es sein, dass wir ein Frame überspringen (zb durch die Erhöhung vom Ende eines Frames zum Anfang des übernachsten Frames kommen). Nun könnte es sich dabei zum Beispiel um das FrameDataActionFlag handelt, welches somit nicht abgespielt wird. Trotzdem wird der Angriff ausgeführt und die Rollback-Routine durchlaufen, weil das FrameDataActionFlag überschritten wurde. Je nach Counter-Anstiegswert kann es nun sein, dass wir bei den Folgeschlägen abwechselnd beim FrameDataActionFlag und beim nachfolgenden Schlag beim Frame nach diesem landen. Falls wir nun durch die Verrechnung mit dem Rollback dabei 2 unterschiedliche Rücksprungframes für die Folgeschläge erhalten, sind die Dauern der Folgeschläge nicht ident, sondern abwechselnd um 1 Tick verschoben (zB 4/4/3/4/3/13).

Außerdem kann auch das StartingFrame eine Unregelmäßigkeit in den Folgeschlägen auslösen. Das StartingFrame bewirkt für den Erstschlag eine Verschiebung des Wertes im Counter um 1*256 bzw 2*256. Dank dieser Verschiebung erreiche ich das FrameDataActionFlag beim Erstschlag schneller und bei bestimmtem Counter-Anstiegswert kann es vorkommen, dass ich das FrameDataActionFlag überspringe und der Rollback damit erst auf das nächste Frame wirkt. Sollte sich nun durch den Rollback-Wert ein anderes Rücksprungframe ergeben als es beim FrameDataActionFlag der Fall gewesen wäre, so fängt der erste Folgeschlag bei einem späterem Frame an und endet daher früher. Wenn der Folgeschlag nun mit dem FrameDataActionFlag endet (der Erstschlag tat dies ja nicht), starten alle weiteren Folgeschläge bei geringerem Frame und brauchen daher 1 Tick länger als der erste (zB 4/2/3/3/3/11)

Damit können wir zusammenfassen, dass es für die Folgeschläge beim allgemeinen Rollback 3 mögliche Muster gibt:

5/5/5/5 ... Alle Folgeschläge sind gleich lang

4/5/5/5 ... Bei einem Startingframe > 0 kann der erste Folgeschlag schneller sein

5/4/5/4 bzw 4/5/4/5 ... Die Folgeschläge können abwechselnd zwischen 2 Dauern springen

Im letzten Fall wirken sich die Folgeschlage natürlich auch auf den Endschlag aus. Je nachdem ob die Angriffsreihe eine gerade oder eine ungerade Anzahl an Schlägen beinhaltet, enden die Folgeschläge mit einem anderem Wert (4 oder 5 Ticks in unserem Beispiel). Daher kann es in Abhängigkeit der Angriffe (gerade oder ungerade Anzahl) zu unterschiedlichen Längen des Endschlages kommen (zB 12 Ticks wenn der letzte Folgeschlag 5 Ticks lang war und 13 Ticks, sofern der letzte Folgeschlag nur 4 Ticks lang war).

Auch den allgemeinen Rollback rechne ich noch Schritt für Schritt über den Counter durch, wobei ich folgende Angaben verwende:

StartingFrame = 02
FrameDataActionFlag = 05
FramesPerDirection = 7
Acceleration = 140
AnimationSpeed = 256

SkillRollback = 50%
Rollback = 100 - SkillRollback = 50%

Counter-Anstiegswert = [AnimationSpeed*Acceleration/100] = 384
Counter-Endwert = Hitshift*FramesPerDirection = 1792
Counter-Aktionswert = Hitshift*FrameDataActionFlag = 1280

Da unsere Folgeschläge bei diesem Rollback nicht unbedingt gleich lang sein müssen, rechne ich nun mit 3 Folgeschlägen, damit man das vorhandene Muster erkennen kann.

Tick 1:
StartingFrame = 02 => Startwert des Counters = 2*256 = 512
Counter wird um 358 erhöht und beträgt damit 870.
Counterstellung 870 bedeutet Abspielen von Frame 03
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des Erstschlages

Tick 2:
Counter wird um 358 erhöht und beträgt damit 1228.
Counterstellung 1228 bedeutet Abspielen von Frame 04
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des Erstschlages

Tick 3:
Counter wird um 358 erhöht und beträgt damit 1586.
Counterstellung 1586 bedeutet Abspielen von Frame 06
Counter-Aktionswert (1280) wurde überschritten, daher wird das Rücksprungframe errechnet
Rücksprungframe = [CurrentFrame*Rollback/100] = [06*50/100] = 03

Tick 4:
Wir starten dank des Rollbacks wieder bei Frame 03 und damit bei Counterstellung 3*256 = 768
Counter wird um 384 erhöht und beträgt damit 1126.
Counterstellung 1126 bedeutet Abspielen von Frame 04
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des ersten Folgeschlages

Tick 5:
Counter wird um 358 erhöht und beträgt damit 1484.
Counterstellung 1484 bedeutet Abspielen von Frame 05
Counter-Aktionswert (1280) wurde erreicht, daher wird das Rücksprungframe errechnet
Rücksprungframe = [CurrentFrame*Rollback/100] = [05*50/100] = 02

Tick 6:
Wir starten dank des Rollbacks wieder bei Frame 02 und damit bei Counterstellung 2*256 = 512
Counter wird um 384 erhöht und beträgt damit 870.
Counterstellung 870 bedeutet Abspielen von Frame 03
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des zweiten Folgeschlages

Tick 7:
Counter wird um 358 erhöht und beträgt damit 1228.
Counterstellung 1228 bedeutet Abspielen von Frame 04
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des zweiten Folgeschlages

Tick 8:
Counter wird um 358 erhöht und beträgt damit 1586.
Counterstellung 1586 bedeutet Abspielen von Frame 06
Counter-Aktionswert (1280) wurde überschritten, daher wird das Rücksprungframe errechnet
Rücksprungframe = [CurrentFrame*Rollback/100] = [06*50/100] = 03

Tick 9:
Wir starten dank des Rollbacks wieder bei Frame 03 und damit bei Counterstellung 3*256 = 768
Counter wird um 384 erhöht und beträgt damit 1126.
Counterstellung 1126 bedeutet Abspielen von Frame 04
Counter-Aktionswert (1280) weder erreicht noch überschritten, daher kein Abbruch des dritten Folgeschlages

Tick 10:
Counter wird um 358 erhöht und beträgt damit 1484.
Counterstellung 1484 bedeutet Abspielen von Frame 05
Counter-Aktionswert (1280) wurde erreicht, daher wird das Rücksprungframe errechnet
Rücksprungframe = [CurrentFrame*Rollback/100] = [05*50/100] = 02

Tick 11:
Wir starten dank des Rollbacks wieder bei Frame 02 und damit bei Counterstellung 2*256 = 512
Counter wird um 384 erhöht und beträgt damit 870.
Counterstellung 870 bedeutet Abspielen von Frame 03
Counter-Endwert (1792) weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 12:
Counter wird um 358 erhöht und beträgt damit 1228.
Counterstellung 1228 bedeutet Abspielen von Frame 04
Counter-Endwert (1792) weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 13:
Counter wird um 358 erhöht und beträgt damit 1586.
Counterstellung 1586 bedeutet Abspielen von Frame 06
Counter-Aktionswert (1280) wurde überschritten, daher wird unser Angriff ausgeführt
Counter-Endwert (1792) weder erreicht noch überschritten, daher kein Abbruch des Endschlages

Tick 14:
Counter wird um 358 erhöht und beträgt damit 1944.
Counter-Endwert (1792) wurde überschritten, daher sofortiger Abbruch des Endschlages
Beginn der nächsten Animation in diesem Tick, welches somit nicht mehr zu unserer Animation zählt

Unsere Angriffereihe, bestehend aus Erstschlag, drei Folgeschlägen und Endschlag, hat somit eine Dauer von 3/2/3/2/3. Unsere Folgeschläge wechseln sich mit den Werten 2 und 3 ab und wirken sich damit auch auf den Endschlag aus. Bei gerader Anzahl an Folgeschlägen würde sich in diesem Beispiel der Endschlag ändern und wir erhielten eine Dauer von 3/2/3/2/3/2.

Auch hier wollen wir natürlich eine Formel haben um die Berechnung zu vereinfachen. Diese lautet in diesem Fall ähnlich wie jene für den kompletten Rollback, muss jedoch noch durch das Rücksprungframe ergänzt werden.


Erstschlag

Der Erstschlag endet mit dem ersten Rollback und wird von diesem somit nicht beeinflusst. Damit gilt hier die selbe Formel wie beim kompletten Rollback:

FPA = {(Hitshift*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*Acceleration/100]}

Folgeschläge

Diesmal beginnt unser Folgeschlag nicht beim Frame 00, sondern beim Rücksprungframe, welches durch den vorherigen Schlag bestimmt wurde. Das Rücksprungframe gibt damit an, um wie viele Frames unsere Animation verkürzt wird, sodass wir diese Zahl einfach vom FrameDataActionFlag abziehen können:

FPA = {(Hitshift*(FrameDataActionFlag - Rollbackframe))/[AnimationSpeed*Acceleration/100]}

Nun brauchen wir noch das Rollbackframe, welches durch den vorhergehenden Schlag bestimmt wird. Damit brauchen wir die Unterscheidung des vorherigen Schlages zwischen Erstschlag und Folgeschlag. Für den ersten Folgeschlag brauchen wir Informationen über den Erstschlag und das Rollbackframe berechnet sich aus:

RollbackFrame = [[(Hitshift*StartingFrame + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]

Für alle weiteren Folgeschläge brauchen wir allerdings Informationen über den vorhergehenden Folgeschlag, sodass die Formel folgenermaßen lautet:

RollbackFrame = [[(Hitshift*Last_Rollbackframe + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]

Endschlag

Auch der Endschlag startet natürlich beim Rollbackframe des letzten Folgeschlages, ist aber sonst ident mit dem Ablauf eines normalen Angriffes. Damit müssen wir auch hier unsere Formel nur ein wenig modifizieren:

FPA = {(Hitshift*(FramesPerDirection - Rollbackframe))/[AnimationSpeed*Acceleration/100]} - 1

Für das Rollbackframe haben wir gerade beide Formeln aufgestellt und auch hier müssen wir unterschieden. Falls unsere Animation aus nur zwei Schlägen besteht, fallen die Folgeschläge weg und der dem Endschlag vorrausgehende Schlag ist der Erstschlag. Damit brauchen wir diese Formel:

RollbackFrame = [[(Hitshift*StartingFrame + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]

Bei einer Animation mit mehr als zwei Schlägen haben wir immer mindestens einen Folgeschlag und damit einen Rollback zwischen Erst- und Endschlag, sodass die zweite Formel zur Anwendung kommt:

RollbackFrame = [[(Hitshift*Last_Rollbackframe + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]


Zusammenfassung

Erstschlag = {(256*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}

Folgeschlag = {(256*(FrameDataActionFlag - Rollbackframe))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}

Endschlag = {(256*(FramesPerDirection - Rollbackframe))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]} - 1

Rollbackframe = [[(256*Last_BeginningFrame + [AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]*Last_FPA)/256]*(100 - SkillRollback)/100]

FramesPerDirection ... Die Anzahl der Frames, aus der unsere Animation besteht.
FrameDataActionFlag ... Jenes Frame, bei dem unsere Aktion wirklich ausgeführt wird.
StartingFrame ... Das Frame, mit welchem unsere Animation beginnt.
AnimationSpeed ... Der animationsabhängige Grundwert des Counter-Anstiegswertes.
EIAS ... Wird über die "dimishing returns"-Formel aus dem IAS errechnet.
SIAS ... DIe Summe sämtlicher Boni und Mali zur Angriffsgeschwindigkeit von Fertigkeiten, inklusive dem Malus der Gegnerverlangsamung.
WSM ... Ein waffenabhängiger Wert zur Steuerung der Angriffsgeschwindigkeit.
ColdEffekt ... Sollten wir von einem Kälteangriff getroffen worden sein, so erhalten wir als Spieler für die Dauer der Kälte einen Malus von 50.
Last_BeginningFrame... Falls der vorhergehende Angriff der Erstschlag war, ist dieser Wert das StartingFrame. Andernfalls ist dies das Rücksprungframe das vorhergehenden Angriffes.
Last_FPA... Die Dauer des vorhergehenden Angriffes in Ticks.
SkillRollback... Der Rollback-Wert der verwendeten Fertigkeit.


Beispiele

Zum Abschluss dieses Unterkapitels rechne ich noch je ein Beispiel für die beiden Arten des Rollbacks. Dazu ziehe ich gleich zwei praktische Beispiele heran:

kompletter Rollback

Wir spielen einen Paladin mit dem Angriff "Eifer" und haben die Aura "Fanatismus" aktiv, die uns 35 SIAS liefert. Wir kämpfen mit "Trauer" in einer Phasenklinge und bekommen zu den 35 IAS des Runenwortes noch 40 IAS durch unser restliches Equip. Daraus resultieren folgende Werte:

FramesPerDirection = 15
Startingframe = 0
FrameDataActionFlag = 07
AnimationSpeed = 256

SIAS = 35
EIAS = [120*75/(120+75)] = 46
WSM = -30


Erstschlag = {(256*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}
Erstschlag = {(256*(7 - 0))/[256*(100 + 46 + 35 + 30)/100]}
Erstschlag = {(256*7)/[256*175/100]}
Erstschlag = 4 Ticks

Folgeschläge = {(256*FrameDataActionFlag)/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]}
Folgeschläge = {(256*7)/[256*175/100]}
Folgeschläge = 4 Ticks

Endschlag = {(256*FramesPerDirection)/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]} - 1
Endschlag = {(256*15)/[256*175/100]} - 1
Endschlag = 8 Ticks

Unser Paladin erhält damit eine Geschwindigkeit von 4/4/8 ist damit - weil der Maximalwert der Acceleration bei 175 schon erreicht wurde - bei seiner Maximalgeschwindigkeit.


allgemeiner Rollback

Unsere Amazone verwendet die Fertigkeit "Streuen" auf Fertigkeitslevel 10 gegen einen einzelnen Gegner und bekommt neben den 40 IAS ihres Windmacht-Bogens noch 50 IAS von der restlichen Ausrüstung. Damit erhalten wir nun folgende Werte:

Angriffe = 2 + Fertigkeitslevel/4 = 4

FramesPerDirection = 14
Startingframe = 0
FrameDataActionFlag = 06
AnimationSpeed = 256

EIAS = [120*90/(120+90)] = 51
WSM = 10


Erstschlag = {(Hitshift*(FrameDataActionFlag - StartingFrame))/[AnimationSpeed*(Baserate + EIAS + SIAS - WSM (+ ColdEffekt))/100]}
Erstschlag = {(256*(6 - 0))/[256*(100 + 51 - 10)/100]}
Erstschlag = 5 Ticks

Rollbackframe_1 = [[(Hitshift*StartingFrame + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]
Rollbackframe_1 = [[(256*0 + [256*141/100]*5)/256]*50/100]
Rollbackframe_1 = 3

Folgeschlag_1 = {(Hitshift*(FrameDataActionFlag - Rollbackframe_1))/[AnimationSpeed*(Baserate + EIAS + SIAS - WSM (+ ColdEffekt))/100]}
Folgeschlag_1 = {(256*(6 - 3))/[256*(100 + 51 - 10)/100]}
Folgeschlag_1 = 3 Ticks

Rollbackframe_2 = [[(Hitshift*Rollbackframe_1 + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]
Rollbackframe_2 = [[(256*3 + [256*141/100]*3)/256]*50/100]
Rollbackframe_2 = 3

Folgeschlag_2 = {(Hitshift*(FrameDataActionFlag - Rollbackframe_2))/[AnimationSpeed*(Baserate + EIAS + SIAS - WSM)/100]}
Folgeschlag_2 = {(256*(6 - 3))/[256*(100 + 51 - 10)/100]}
Folgeschlag_2 = 3 Ticks

Rollbackframe_3 = [[(Hitshift*Rollbackframe_2 + [AnimationSpeed*Acceleration/100]*Last_FPA)/256]*Rollback/100]
Rollbackframe_3 = [[(256*3 + [256*141/100]*3)/256]*50/100]
Rollbackframe_3 = 3

Endschlag = {(Hitshift*(FramesPerDirection - Rollbackframe_3))/[AnimationSpeed*Acceleration/100]}-1
Endschlag = {(256*(14 - 3))/[256*141/100]} - 1
Endschlag = 7 Ticks

Unsere Angriffsreihe hat damit eine Dauer von 5/3/3/7. Da die beiden Folgeschläge die selbe Dauer haben, setzt sich diese auch konstant bei allen weiteren Folgeschlägen (auf höherem Fertigkeitlevel gibt es mehr Angriffe pro Serie) fort.

Verwandlung

Bei den Verwandlungen müssen wir zuerst zwischen vier Arten unterschieden:

~ Beim Anlegen des Kompletten "Trang Ouls" Sets erhalten wir den Zustand "monsterset". Die Monsterklasse deren Erscheinungsbild wir dabei annehmen ist in der States.txt festgelegt. Im unveränderten Spiel ist dies jene Klasse mit dem Index 135, die Klasse "vampire5" oder auch "Die Verbannten".

~ Auch die Fertigkeit Delirium des gleichnamigen Runenwortes ermöglicht uns die Verwandlung. Dabei erhalten wir den Status "delerium" und im unveränderten Spiel das Aussehen der Monsterklasse mit dem Index 212 - des "untoten Rattenmannes", der im Spiel jedoch sonst nicht verwendet wird.

~ Die letzten beiden Zustände - "wolf" (Index 430) und "bear" (Index 431) erhalten wir durch den Einsatz der Fertigkeiten "Werwolf" bzw "Werbär". Neben dem Druiden, welcher diese Fertigkeiten erlernen kann, stehen sie dank der Gegenstände Wolfsgeheul und Bestie auch dem Barbaren (Werwolf) bzw allen Charakterklassen (Werbär) zur Verfügung.

Für die ersten beiden Zustände - die Verwandlung in Vampir und untoten Rattenmann - können wir das bereits bekannte System anwenden und verwenden dabei einfach die Werte der jeweiligen Erscheinungsform. Für die Verwandlung in einen Werwolf oder einen Werbären müssen wir bei der Ermittelung der Angriffsgeschwindigkeit ein anderes System anwenden, welches ich nun erklären werde:

FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1

Der interne Ablauf über den Counter und damit auch die Grundformel bleiben unverändert (man darf nur nicht vergessen, dass sich die spezifischen Werte nun nun auf die Werform und nicht die Charakterklasse beziehen), aber die AnimationSpeed ist nicht mehr animationsabhängig, sondern wird über eine eigene Formel errechnet:

AnimationSpeed = [Hitshift*NeutralFrames/Delay]

NeutralFrames ... Dies ist die Summe aller Frames der NU-Animation unserer Werform, welche für unsere Standanimation außerhalb der Stadt angewandt wird.

Nun fehlt uns noch der Wert für "Delay", der uns zu unserer letzten Formel führt:

Delay = [Hitshift*CharFrames/[(Baserate + WIAS - WSM)*CharSpeed/100]]

CharFrames ... Dies ist nun der FramesPerDirection-Wert, den unsere Charakterklasse im unverwandelten Zustand hätte.
CharSpeed ... Dies ist die AnimationSpeed des unverwandelten Charakters.

Da die Zweihandschwerter von Barbaren sowohl einhändig, als auch zweihändig geführt werden können, sind allen Waffen zwei Waffenklassen zugewiesen. Einen Unterschied zwischen diesen Klassen gibt es allerdings nur bei den Zweihandschwertern, weil sie einhändig geführt in die Klasse 1hs und zweihändig geführt in die Klasse 2hs fallen. Die Delay-Formel verwendet nun jene Spalte der Weapons.txt, in welcher auch Zweihandschwerter der Klasse 1hs angehören. Das bedeutet, dass alle Zweihandschwerter für die Geschwindigkeitsberechnung als einhändige Schwungwaffen gelten.


Auswirkungen

Nun stellt sich natürlich die Frage nach den Auswirkungen dieses neuen Systems, weshalb wir nun einen verwandelten mit einem unverwandelten Charakter vergleichen.
Im unverwandelten Zustand ist die AnimationSpeed konstant und liegt zumeist bei 256. IAS von der Waffe und der Restausrüstung sind gleichberechtigt, sodass auch eine langsame Waffe über die Ausrüstung oder eine Fertigkeit auf annehmbare Geschwindigkeit gebracht werden kann.
Nach der Verwandlung wird die AnimationSpeed bekanntlich neu berechnet und sinkt dabei für langsame Waffen recht stark ab. Bei geringem WIAS sinkt daher die Angriffsgeschwindigkeit im Vergleich zum unverwandelten Charakter. Um die neu berechnete AnimationSpeed und damit auch die Angriffsgeschwindigkeit auf einen guten Wert zu bringen, können wir nur das WIAS erhöhen, bzw den WSM senken. Das IAS der restlichen Ausrüstung und das SIAS gewisser Fertigkeiten gelten zwar weiterhin, werden allerdings durch die Acceleration begrenzt und liefern ohne ausreichend WIAS keine gute Angriffsgeschwindigkeit. Die Werformen sind daher auf viel WIAS angewiesen um eine gute Angriffsgeschwindigkeit zu erreichen, weil dieses zusammen mit dem WSM zweifach in der Berechnung wirkt und über die AnimationSpeed nicht begrenzt wird. Eine Waffe, welche nur wenig oder kein IAS liefert, ist in Werform unbrauchbar, da sie nicht wie beim unverwandelten Charakter über die Ausrüstung oder eine Fertigkeit beschleunigt werden kann.

Aus den obigen Formeln erkennt man auch den großen Vorteil der Werformen. Die Acceleration ist zwar bei 175 begrenzt, aber die Werformen erhalten ihre Geschwindigkeit überwiegend über die AnimationSpeed. Diese ist nun nicht begrenzt, sodass bei sehr hohem WIAS bzw niedrigem WSM auch sehr kurze Angriffsdauern möglich sind. Die Assassine könnte in Gestalt eines Werbären beispielsweise eine Angriffsdauer von bloß 3 Ticks erreichen, was dem unverwandelten Charakter aufgrund der Begrenzung unmöglich ist.

Für Barbar und Assassine gibt es noch weitere Auswirkungen, sofern diese zwei Waffen zugleich benutzen. Im unverwandelten Zustand würden die Charaktere beim Standardangriff die S3 beziehungsweise die S4 Animation für den Zweitschlag nutzen. Selbiges gilt auch nach der Verwandlung, hier kommen ebenfalls S3 und S4 Animation der Werform zur Anwendung. Allerdings war dies offenbar nicht geplant, denn beide dieser Sekundärangriffe teilen keinerlei Schaden aus. Daher ist beispielsweise von einer Werbär-Assassine mit zwei Klauen abzuraten, da dieser nur der Standardangriff zur Verfügung steht und daher jeder zweite Schlag wirkungslos wäre.
Weiters unterliegt auch der WSM in diesem Fall einer Sonderregelung. Die bereits bekannten Regeln zur Berechnung des WSM im Dual-Waffen-Modus gilt hier ausschließlich auf die Grundformel als Teil der Acceleration, nicht jedoch auf den WSM der Delay-Formel. In letzterer wird stattdessen für den Erstschlag stets der WSM der Primärwaffe und für den (wirkungslosen) Zweitschlag der WSM der Sekundärwaffe verwendet. Der WSM-Trick kann daher nicht wirklich angewandt werden, da er auf den wichtigen Teil der Formel keine Wirkung hat.


Zusammenfassung

FPA = {(256*FramesPerDirection)/[AnimationSpeed*(100 + EIAS + SIAS - WSM (+ ColdEffekt))/100]} - 1
AnimationSpeed = [256*NeutralFrames/Delay]
Delay = [256*CharFrames/[(100 + WIAS - WSM)*CharSpeed/100]]

FramesPerDirection ... Die Summe aller Frames unserer verwendeten Angriffsanimation der Werform.
NeutralFrames ... Summe der Frames unserer neutralen Animation (verwendung während des Stehens).
CharFrames ... Die Summe aller Frames der Angriffsanimation, welche wir im unverwandelten Zustand einsetzten würden (mit Ausnahme bei Zweihandschwertern).
CharSpeed ... Dies ist die AnimationSpeed der Angriffsanimation, welche der unverwandelte Charakter verwenden würde.
WIAS ... Sämtliches IAS auf unserer Waffe oder Waffensockelung
WSM ... Ein waffenabhängiger Wert zur Steuerung der Angriffsgeschwindigkeit. Er geht mit negativem Vorzeichen in die Formel ein, sodass ein kleiner Wert eine höhere Geschwindigkeit bedeutet.
ColdEffekt ... Wenn wir durch einen Kälteangriff eingefroren werden, erhalten wir als Spieler einen Malus von 50 auf die Acceleration.

normaler Angriff

Der Primärschlag des normalen Angriffes verwendet zwei Animationen abwechselnd, nämlich die A1 und die A2 (welche sonst von keiner anderen Fertigkeit verwendet wird). Meistens brauchen wir zwischen diesen beiden Animationen jedoch nicht zu unterschieden, weil ihre Werte oftmals ident sind. In wenigen Fällen ist nur das FrameDataActionFlag geringfügig verschoben, aber der einzige relevante Unterschied besteht beim Paladin (PAA22HS hat 19 Frames statt 18) und der Assassine (AIA2HTX hat 12 Frames statt 11). Sollten wir uns also die Geschwindigkeit dieses Angriffs berechnen wollen, brauchen wir den Mittelwert beider Animationen.

Nutzen wir den normalen Angriff mit zwei Waffen zur gleichen Zeit, so bekommt unsere Sekundärwaffe ebenfalls eine eigene Animation. Dies bedeutet einerseits, dass wir auch hier einen eigenen WSM benötigen (Zusammensetzung siehe oben) und andererseits, dass wir den Sekundärschlag durch IAS der Sekundärwaffe beschleunigen können. Die beiden Charakterklassen mit der Fähigkeit zwei Waffen auszurüsten sind die Assassine mit ihren Klauen (verwendet Animation S4) und der Barbar (verwendet Animation S3). Wollen wir uns nun unsere Angriffsgeschwindigkeit berechnen, müssen wir wiederum Erstschlag (gemittelt aus A1 und A2) und Zweitschlag mitteln, sodass eine Assassine zum Beispiel eine durchschnittliche Dauer von 7,75 Ticks erreichen kann.


Ansturm

Ansturm verwendet eine Sequenz, um Fortbewegung (RN) und Angriff (A1) zu verbinden. Diese Bewegung kann dabei nicht umgangen werden, denn bei zu geringem Abstand zum Gegner, wird statt dem Ansturm bloß ein normaler Angriff ausgeführt. Die Besonderheit an diesem Angriff ist nun, dass die Dauer des Schlages nicht beeinflussbar ist, weder durch erhöhte Angriffsgeschwindigkeit, noch durch beliebige Mali oder ähnlichem. Um die Geschwindigkeit zu erhöhen, sollte man daher seine Bewegungsgeschwindigkeit durch Fertigkeiten erhöhen, damit zumindest die Bewegung als Teil des Angriffes beschleunigt wird.

Da der reine Angriff 7 Frames umfasst und nicht beschleunigt oder verlangsamt werden kann, ist zu vermuten, dass der Angriff 6 Ticks dauert. Eine gesicherte Aussage darüber wäre allerdings nur möglich, wenn man Bewegung und Angriff trennt, sodass die Angriffsdauer alleine messbar ist. Zumal die Sequenzen allerdings hardcoded sind, wäre dies mit einigem Aufwand verbunden, welcher sich eigentlich nicht wirklich lohnt.

Wirbelwind

Wirbelwind verwendet ein komplett eigenes System zur Berechnung der Angriffsgeschwindigkeit. Die Animation spielt dabei keine Rolle, sie zeigt nur an, dass wir gerade Wirbelwind verwenden. Der Angriff verwendet eine eigene Programmroutine, weilche in jedem Tick des Angriffes durchlaufen wird. Für Spieler im Erweiterungmodus "LoD" bewirkt diese Routine folgendes:

Für die ersten beiden Angriffe spielt die Geschwindigkeit der Waffe noch keine Rolle. Der erste Angriff erfolgt selbst mit der langsamsten Waffe in Tick 4, wobei in diesem Fall selbst bei zweihändigem Angriff nur ein Schlag ausgeführt wird. Nach diesem Angriff wird eine Angriffsverzögerung von 4 Ticks gesetzt, welche den nächstmöglichen Angriffszeitpunkt bestimmt. In den folgenden Ticks wird nun die momentane Zeit mit der Zeit des nächstmöglichen Angriffes verglichen. Erst in Tick 8 ist die Verzögerung abgelaufen und ein neuer Angriff ist möglich. Dieser zweite Angriff ist ebenfalls noch von der Waffengeschwindigkeit unabhängig, wird aber bei beidhändigem Angriff wie alle weiteren Schläge mit beiden Waffen zugleich ausgeführt.
Kurz gesagt, haben wir hier zwei Freischläge bei Tick 4 und 8, welche unabhängig von unserer Waffe sind. Bei langsamen Waffen ist es daher praktisch kurze Angriffe auszuführen, um öfter diese schnellen Freischläge zu erhalten.

Nach diesem zweiten Angriff wird wiederum eine Verzögerungszeit gesetzt, doch diesmal ist die Dauer der Verzögerung von der Geschwindigkeit der Waffe abhängig. Dafür wird die Delay-Formel verwendet, welche wir bereits bei der Verwandlung kennen gelernt haben:

Delay = [256*CharFrames/[(Baserate + WIAS - WSM)*CharSpeed/100]]

CharFrames ... Die Summe der Frames des normalen Angriffs für unsere Kombination aus Charakter und Waffenart.
Baserate ... Unser Grundwert, welcher auch hier wieder bei 100 liegt.
WIAS ... Sämtliches auf der Waffe enthaltenes IAS
WSM ... Ein waffenabhängiger Wert zur Steuerung der Angriffsgeschwindigkeit
CharSpeed ... Aus der animdata.txt auszulesener Wert der A1-Animation

Zweihandschwerter (siehe auch nächstes Kapitel) verwenden dabei für CharFrames und CharSpeed die selben Werte wie Einhandschwerter. Daher sind auch Zweihandschwerter ebenso schnell wie einhändige Schwungwaffen.

Um nun aus diesem Delay die Verzögerung zu bestimmen, gibt es eine Reihe von Breakpoints:

Delay => Verzögerung

00-11 => 4
12-14 => 6
15-17 => 8
18-19 => 10
20-22 => 12
23-25 => 14
26+ => 16

Falls wir allerdings keine Waffe angelegt haben, liegt unsere Verzögerung automatisch bei 10.

Nun wird beginnend beim Tick 8 über die Verzögerung berechnet, wann wir wieder angreifen können und dieser Zeitpunkt wird mit der aktuellen Zeit verglichen. Falls wir beim Durchlaufen der Routine wieder angreifen dürfen, wird ein Angriffsversuch ausgeführt. Der Zeitpunkt des nächsten Angriffes wird berechnet, sobald die alte Verzögerung vorüber ist. Da wir jedes Tick abfragen, fällt dies zwangsläufig immer mit dem Angriff zusammen. Somit bedeutet eine Verzögerung von 6 Ticks einfach, dass wir alle 6 Ticks angreifen (Freischläge ausgenommen).
In 1.10 war dies leicht anders, da damals nur alle 4 Ticks abgefragt wurde und eine Verzögerung von 6 Ticks damit einen Schlagabstand von abwechselnd 4 und 8 Ticks (somit im Mittel ebenfalls 6 Ticks) bewirkt hatte.
Im folgenden Beispiel mit einer Verzögerung von 6 werde ich aus Platzgründen einfach nur jedes zweite Tick anschreiben, denn bei ungeraden Ticks kann sowieo keine Aktion durchgeführt werden:

Tick 4
Erster Freischlag wird ausgeführt
Konstante Verzögerung (4) auf die aktuelle Zeit (4) addiert, sodass wir erst ab Tick 8 wieder angreifen können

Tick 6
Verzögerung noch nicht abgelaufen => kein Angriff möglich

Tick 8
Verzögerung ist beendet => zweiter Freischlag wird ausgeführt
Berechnete Verzögerung (6) auf aktuelle Zeit (8) addieren, sodass wir erst ab Tick 14 wieder angreifen können

Tick 10
Vergleich: aktuelle Zeit (10) >= nächste Angriffszeit (14)?
Vergleich negativ => kein Angriff

Tick 12
Vergleich: aktuelle Zeit (12) >= nächste Angriffszeit (14)?
Vergleich negativ => kein Angriff

Tick 14
Vergleich: aktuelle Zeit (14) >= nächste Angriffszeit (14)?
Vergleich positiv => Angriff wird ausgeführt
Berechnete Verzögerung (6) auf aktuelle Zeit (14) addieren, sodass wir erst ab Tick 20 wieder angreifen können


Zweihändiges Wirbeln

Hier bieten sich uns zwei Möglichkeiten an. Einerseits das Wirbeln mit einer Zweihandwaffe und andererseits die Benutzung von zwei Einhandwaffen.

Zweihandwaffen sind im allgemeinen langsamer, haben zum Ausgleich dafür allerdings einen höheren Schaden als eine Einhandwaffe. Der Grund für diese Differenz in der Geschwindigkeit liegt natürlich darin, dass die Angriffsanimation mit Zweihandwaffen mehr Frames beinhaltet und damit wird zum Abspielen mehr Zeit benötigt. Die Animation wird, wie wir bereits wissen, durch Charakter und Waffentyp bestimmt. Der Waffentyp ist dabei für jede Waffe in der Weapons.txt eingetragen, wobei es hierfür 2 Spalten gibt. Sollten wir eine Waffe zweihändig führen, wird der Wert der Spalte "2handedwclass" verwendet, während im einhändigen Gebrauch die Spalte "wclass" verwendet wird. Jedes Zweihandschwert hat daher - weil es von Barbaren auch einhändig getragen werden kann - in "2handedwclass" den Eintrag "2hs" und in der Spalte "wclass" den Eintrag 1hs. Wirbelwind liest nun immer die Spalte "wclass" aus, weshalb jedes Zweihandschwert im Zweihandgebrauch (also keine zwei Zweihandschwerter einhändig geführt) seinen Zweihand-Schaden erhält, aber über die selbe Geschwindigkeit wie eine Einhandwaffe verfügt. Wenn wir uns nun die möglichen Waffentypen ansehen, müssen wir nur noch einerseits zwischen Einhandwaffen und sämtlichen Schwertern und andererseits zwischen allen anderen Zweihandwaffen unterschieden, weil letztere nicht einhändig geführt werden können.

Wirbelwind kann ebenso mit zwei Einhandwaffen ausgeführt werden, wobei auch hier ein paar besondere Regeln gelten. Wenn Wirbelwind mit zwei Waffen ausgeführt wird, so wird zu den Angriffszeitpunkten (ausgenommen beim ersten Freischlag) auch mit beiden Waffen angegriffen. Die ursprüngliche Maximalgeschwindigkeit von 4 Ticks/Angriff kann daher durch zwei Einhandwaffen auf 2 Ticks/Angriff erhöht werden.
Weiter oben habe ich bereits die Berechnungen des WSM für die gleichzeitige Benutzung zweier Waffen erklärt, doch diese gilt hier nicht. Stattdessen wird für jede der beiden Waffen eine eigene Verzögerung errechnet und es gilt immer die Verzögerung der aktuellen Waffe, welche nach jedem Angriffsversuch gewechselt wird. Den genauen Ablauf werde ich nun schrittweise erklären:

Start des Angriffes bei Tick 0
Berechung der Delays und daraus resultierend der Angriffsverzögerungen beider Waffen

erster Freischlag bei Tick 4
Angriffsversuch mit der Primärwaffe
Wechsel auf Sekundärwaffe

zweiter Freischlag bei Tick 8
Angriffsversuch mit der Sekundärwaffe
Wechsel auf Primärwaffe
Angriffsversuch mit der Primärwaffe
Wechsel auf Sekundärwaffe
nächsten Angriffszeitpunkt über Verzögerung der aktuellen Waffe (= Sekundärwaffe) errechnen

nächster Schlag zu errechnetem Zeitpunkt
Angriffsversuch mit der Sekundärwaffe
Wechsel auf Primärwaffe
Angriffsversuch mit der Primärwaffe
Wechsel auf Sekundärwaffe
nächsten Angriffszeitpunkt über Verzögerung der aktuellen Waffe (= Sekundärwaffe) errechnen


Bisher war für die Geschwindigkeit somit immer die Sekundärwaffe ausschlaggebend, weil wir natürlich bei der Primärwaffe beginnen und beim ersten Schlag nur einen Waffenwechsel haben, während sich alle weiteren Waffenwechsel aufheben. Allerdings sind wir bisher davon ausgegangen, dass sämtliche Angriffe auch wirklich ausgeführt werden. Sollte während des ersten Schlages allerdings kein Gegner innerhalb der Angriffsreichweite (welche übrigens bei 5 Subtiles begrenzt wird) der ersten Waffe sein, so wird nach dem ersten Schlag kein Angriffsversuch mit der zweiten Waffe mehr durchgeführt. Damit erfolgt nur noch ein Waffenwechsel und für den nächsten Angriffsversuch zählt auch die Verzögerung der Primärwaffe:

nächster Schlag zu errechnetem Zeitpunkt
Angriffsversuch mit der Sekundärwaffe
kein Gegner innerhalb der Waffenreichweite
Wechsel auf Primärwaffe
nächsten Angriffszeitpunkt über Verzögerung der aktuellen Waffe (= Primärwaffe) errechnen


Breakpoints

Bei der verwendung von zwei Einhandwaffen müssen diese Dauern natürlich noch halbiert werden, da immer zwei Angriffe gleichzeitig ausgeführt werden.


Classic-Modus und wirbelnde Monster

Der obige Ablauf gilt wie gesagt nur für Charaktere im Erweiterungsmodus, denn im Classic-Modus galten für Wirbelwind noch andere Regeln. Dort spielt nämlich die Geschwindigkeit der Waffe keine Rolle und es wird standartmäßig alle 4 Ticks angegriffen.

Auch Talic beherrscht den Wirbelwind-Angriff, wobei dessen Attacke ebenso abgeändert ist. Auch für ihn spielt die Geschwindigkeit der Waffe keine Rolle, sondern er hat einfach alle 4 Ticks eine Chance von 50% auf einen Angriff.

Barbarenwut

Wirkungsweise und formale Berechnung

Dieser Angriff kann in Gestalt eines Werwolfes von Druiden und dank des Barbarenhelms "Wolfsgeheul" auch von Barbaren genutzt werden. Früher wurde Barbarenwut mit der Geschwindigkeit eines normalen Schlages ausgeführt, doch mit dem Erscheinen des Patches 1.10 wurde dieser Angriff auf eine recht undurchsichtige Weise beschleunigt.
Der Angriff verwendet weiterhin die A1-Animation und liefert auch kein SIAS, sodass man sich die Änderung vorerst nicht erklären konnte. TheDragoon entwickelte eine Näherungsformel, die für den relevanten Geschwindigkeitsbereich ziehmlich gut zutraf und verwendete diese auch in seinem Speedcalc auf Werform Central. Er rechnete dabei mit einem FramesPerDirection von 11,5 und zog am Formelende ein weiteres Tick ab. Die Breakpoints werden bei Verwandlung in Wolf/Bär hauptsächlich durch das Delay bewirkt, auf welches sich die FramesPerDirection nicht auswirkt. Aus all diesen durch das Delay theoretisch ermöglichten Breakpoints werden durch die FramesPerDirection allerdings bestimmte Breakpoints ausgewählt und für den realistischen Geschwindigkeitsbereich stimmten die Breakpoints bei einem FramesPerDirection von 11,5 zufälligerweise ziehmlich gut überein. Dabei ist jedoch klar, dass Barbarenwut bei Verwendung der A1 eine FramesPerDirection von 13 hat und ebenso, dass die Anzahl der von einer Animation verwendeten Einzelbilder ganzzahlig sein muss. Daher sehen wir uns nun die genaue Wirkungsweise dieses Angriffes an.

Bei der Angriffsgeschwindigkeit von Barbarenwut spielt es eine Rolle, ob wir den Gegner wirklich treffen. Sollte dies nicht der Fall sein, so entspricht die Dauer des Schlages jener eines normalen Angriffes. Nur falls wir dem Gegner mit Barbarenwut Schaden zufügen (also Verteidigung und Block überwinden), erhalten wir einen Geschwindigkeitsbonus. Die Angriffsgeschwindigkeit dieses Angriffes ist somit in gewissem Maße durch die Trefferchance beeinflussbar.
Zu Beginn dieser FAQ, bin ich auf die Grundlagen der Animationsberechnung eingegangen und eben jene werden nun benötigt. Vor dem Start einer Animation werden bestimmte Werte aus den Spieldateien ausgelesen und berechnet, sodass der Counter-Anstiegswert und der Counter-Endwert errechnet werden können, deren Verhältniss die Länge einer jeden Animation bestimmt.

Counter-Endwert = Hitshift*FramesPerDirection
Counter-Anstiegswert = [AnimationSpeed*Acceleration/100]

Bisher waren diese Werte konstant, sie wurden nach ihrer Berechnung nicht verändert. Eine Beeinflussung der Geschwindigkeit geschah bislang (abgesehen vom zweitem Sonderfall "Wirbelwind") nur durch Änderung der Acceleration (über SIAS, welches in Wandelform allerdings stark an Bedeutung verliert), einer Änderung der Animation (um die FramesPerDirection zu senken) oder über einen Rollback, bei dem wiederum kein Einzelschlag möglich wäre. Barbarenwut stellt in dieser Hinsicht einen Sonderfall dar, denn dieser Angriff steigert den zuvor errechneten Counter-Anstiegswert. Beim Aktionstick wird zuerst abgefragt, ob unser Angriff den Gegner trifft. Sollte dies der Fall sein, so wird der Counter-Anstiegswert verdoppelt, wodurch der abschließende Teil der Animation (jener Teil zwischen tatsächlichem Schlag und Animationsende) schneller abläuft.

Diese Veränderung werde ich wie üblich in einem Beispiel verdeutlichen:

FramesPerDirection = 13
FrameDataActionFlag = 07
CharFrames = 19
NeutralFrames = 9
WSM = -10
WIAS = 50
Acceleration = 175
CharSpeed = 256

Delay = [256*CharFrames/[(100 + WIAS - WSM)*CharSpeed/100]] = 11
AnimationSpeed = [256*NeutralFrames/Delay] = 209

Counter-Anstiegswert = [AnimationSpeed*Acceleration/100] = 365
Counter-Endwert = Hitshift*FramesPerDirection = 3328
Counter-Aktionswert = Hitshift*FramesDataActionFlag = 1792

Nachdem wir nun alle relevanten Werte kennen, lassen wir die Animation wie gewohnt Tick für Tick ablaufen.

Tick 1:
Counter wird um 365 erhöht und beträgt damit 365.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 365 bedeutet Abspielen von Frame 01
Counter ist kleiner als 1792, daher keine Änderung

Tick 2:
Counter wird um 365 erhöht und beträgt damit 730.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 730 bedeutet Abspielen von Frame 02
Counter ist kleiner als 1792, daher keine Änderung

Tick 3:
Counter wird um 365 erhöht und beträgt damit 1095.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 1095 bedeutet Abspielen von Frame 04
Counter-Aktionswert wurde nicht erreicht, daher keine Änderung

Tick 4:
Counter wird um 365 erhöht und beträgt damit 1460.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 1460 bedeutet Abspielen von Frame 05
Counter-Aktionswert wurde nicht erreicht, daher keine Änderung

Tick 5:
Counter wird um 365 erhöht und beträgt damit 1825.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 1825 bedeutet Abspielen von Frame 07
Counter-Aktionswert wurde überschritten, daher Verdoppelung des Counter-Anstiegswertes

Tick 6:
Counter wird um 730 erhöht und beträgt damit 2555.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 2555 bedeutet Abspielen von Frame 09
Counter-Aktionswert wurde überschritten, daher Verdoppelung des Counter-Anstiegswertes

Tick 7:
Counter wird um 730 erhöht und beträgt damit 3286.
Counter ist kleiner als 3328, daher kein Abbruch der Animation
Counterstellung 3286 bedeutet Abspielen von Frame 12

Tick 8:
Counter wird um 730 erhöht und beträgt damit 4010.
Counter ist größer als 3328, daher sofortiger Abbruch der Animation

Unser Angriff hat somit eine Länge von 7 Ticks. Im Vergleich dazu würde ein normaler Angriff 9 Ticks benötigen. Dieser Unterschied nimmt allerdings mit wachsender Geschwindigkeit ab, weil die Differenz zwischen Counter-Endwert und Counter-Aktionswert geringer wird. Sollte diese Differenz sogar gleich oder kleiner dem Counter-Anstiegswert sein, so profitieren wir nicht mehr von der Verdoppelung, weil auch ohne Verdoppelung nach dem kritischem Frame kein weiteres Frame mehr abgespielt wird. Barbarenwut hätte in diesem Fall wieder die gleiche Dauer wie ein normaler Schlag, doch die dazu benötigten Werte an WSM und/oder WIAS können im ungemoddeten Spiel nicht erreicht werden.

Da wir das verwendete System nun kennen, wandeln wir es zur leichteren Berechnung wiederum in eine Formel um.


Herleitung der Formel:

Der Übersichtlichkeit halber spalten wir die Formel in zwei Teile, in die einleitende und die abschließende Animation. Das kritische Tick, welches eigentlich zwischen beiden eben genannten Animationsteilen liegt, zählen wir dabei noch zur einleitenden Animation. Diese verwendet somit nur den berechneten Counter-Anstiegswert und die abschließende Animation nur den verdoppelten Wert. Die Formel für den ersten Teil dieses Angriffes ist somit schon bekannt, es ist jene zur Ermittelung des kritischen Ticks.

FPA_1 = {(Hitshift*FramesDataActionFlag)/[(AnimationSpeed*Acceleration/100)]}

Beim ersten Animationsteil war der Ausgangswert des Counters bekannt, denn das StartingFrame von 0 ergibt natürlich einen anfänglichen Counterwert von 0. Der zweite Animationsteil startet allerdings an unbekannter Stelle, weshalb wir zur Berechnung den momentanen Counterwert wissen müssen. Da wir wissen, wie oft der Counter schon erhöht wurde, können wir uns den Counterwert auch berechnen und ziehen ihn vom Counter-Endwert ab:

Counter-Differenz = Hitshift*FramesPerDirection - [AnimationSpeed*Acceleration/100]*FPA_1

Diese Formel berechnet uns für alle möglichen Werte die noch zurückzulegende Differenz zwischen aktuellem Counterwert und Counter-Endwert. Daher können wir auch hier die bereits bekannte Formel verwenden, wobei wir den Counter-Endwert durch die neu errechnete Counter-Differenz ersetzen und unseren Counter-Anstiegswert verdoppeln:

FPA_2 = {Counter-Differenz/(2*[AnimationSpeed*Acceleration/100])} - 1

Nachdem wir nun beide Animationsteil berechnet haben, müssen wir sie bloß noch addieren:

FPA = FPA_1 + FPA_2


Zusammenfassung:

FPA_1 = {(256*7)/[(AnimationSpeed*Acceleration/100)]}
FPA_2 = {(256*13 - [AnimationSpeed*Acceleration/100]*FPA_1)/(2*[AnimationSpeed*Acceleration/100])} - 1
FPA = FPA_1 + FPA_2

AnimationSpeed ... Charakterabhängiger Wert, der in Wandelform eigens berechnet wird und durch WIAS und WSM gesteigert werden kann.
Acceleration ... Die Acceleration umfasst sämtliche Boni und Mali zur Angriffsgeschwindigkeit und liegt hier im Regelfall beim Grenzwert von 175.


Breakpoints

Söldner

Bei den Söldnern gibt es bezüglich der Animationsgeschwindigkeiten ein paar Abweichungen, auf welche ich hier noch kurz eingehen möchte.

Wenn man ein beliebiges Monster näher betrachtet, wird einem auffallen, dass dieses zwischen allen Aktionen eine Pause einlegt. Die Länge dieser Unterbrechung wird dabei durch den Wert "aidel" in der MonStats.txt gesteuert. Die Daten der Söldner sind nun ebenso in der MonStats.txt eingetragen und da die Söldner ebenfalls vom Spiel gesteuert werden müssen, ist auch für diese ein geringes aidel von 1 eingetragen. Dies bedeutet, dass die Söldner zwischen allen Aktionen eine Zwangspause von 2 Ticks einlegen. Wenn wir nun rechnerisch eine Angriffsdauer von 4 Ticks ermitteln, so bedeutet dies aufgrund der Verzögerung bloß 4,2 Angriffe pro Sekunde.

Weiters möchte ich nochmals gezielt darauf hinweisen, dass man bei der Berechnung von Sequenzen zwischen Charakteren und Söldnern/Monstern unterscheiden muss. Der Angriffsmalus von 30, welchen wir bereits kennen gelernt haben, gilt ausschließlich für Charaktere und wird daher bei Söldnern nicht verrechnet. Unter den Söldnern verwendet übrigens bloß die Stadtwache eine Sequenz und deren Daten können der MonSeq.txt entnommen werden.

Abschließend möchte ich noch zum Barbarensöldner ein paar Worte sagen, da dieser gewissermaßen eine Ausnahme bildet. Wie obiger Tabelle zu entnehmen ist, enthält die A1-Animation dieses Söldners zwei FrameDataActionFlags und somit auch zwei Angriffe. Dies gilt allerdings nur für den normalen Angriff des Söldners, nicht jedoch für seine Fertigkeiten "Hieb" und "Lähmen", obwohl diese die gleiche Animation verwenden würden. Bei der Berechnung der mittleren Angriffsgeschwindigkeit, müssen daher die Geschwindigkeit der Fertigkeiten und jene des normalen Angriffes bedacht werden, wobei auf höherem Level zumeist eine der Fertigkeiten ausgelöst wird.