TitanSeal
Champion
- Registriert
- 5 Juli 2004
- Beiträge
- 7.993
- Punkte Reaktionen
- 7
Animationen
Begriffserklärung
Das Spiel bietet verschiedene Eigenschaften um gewisse Animationen - zum Beispiel Angriffe oder Blockvorgänge - oder Bewegungen zu beschleunigen. Dieser Effekt verläuft jedoch nicht linear mit dem Anstieg der jeweiligen Eigenschaft, sondern es gibt bestimmte Stufen (auch "Breakpoints" genannt) bei denen eine Verbesserung eintritt (der Grund dafür ist unter anderem in dieser FAQ nachzulesen). Diese Eigenschaften sind unter folgenden Abkürzungen bekannt:
IAS = schnellere Angriffsgeschwindigkeit (Increased Attack Speed)
FCR = schnellere Zauberrate (Faster Cast Rate)
FBR = schnellere Abblockrate (Faster Block Rate)
FHR = schnellere Erholungsrate (Faster Hit Recovery)
FRW = schnelleres Gehen/Rennen (Faster Run / Walk)
Diese Eigenschaften werden spielintern jedoch nicht zur Berechnung herangezogen, denn sie werden zuerst in Effektivwerte umgerechnet. Die Abkürzung dieses Effektivwertes lautet damit je nach Eigenschaft klarerweise EIAS, EFCR, EFBR, EFHR bzw EFRW.
Um Speicherplatz einzusparen rechnet das Spiel intern ausschließlich mit Integer-Werten. Das bedeutet, dass sämtliche Werte nur ganzzahlig abgespeichert werden können. Sämtliche Nachkommastellen werden daher einfach abgeschnitten, was bei positiven Werten einem Abrunden bzw bei negativen Werten einem Aufrunden gleichkommt. In einer Formel kennzeichnet man die Art der Rundung oftmals durch die Verwendung unterschiedlicher Klammern:
[...] = Wert innerhalb der Klammern wird abgerundet
{...} = Wert innerhalb der Klammern wird aufgerundet
In bestimmten Formeln kann der zu rundende Wert sowohl negative als auch positive Werte annehmen, wodurch die Art der Rundung vom betreffenden Wert abhängig ist. Diese Möglichkeit sollte stets bedacht werden, vom gedankenlosen Anwenden einer Formel ist stets abzuraten.
Zwei zusammenhängende Begriffe, die oftmals in dieser FAQ verwendet werden, sind "Frame" und "Tick". Filme und Animationen bestehen aus Einzelbildern, welche so schnell abgespielt werden, dass die Bildfolge aufgrund der Trägheit unserer Augen als Bewegung wahrgenommen wird. Ein solches Einzelbild wird dabei als "Frame" bezeichnet. Die Spielmechanik spielt pro Sekunde 25 solcher Frames ab, um die Illusion einer Bewegung hervorzurufen. Der zeitliche Abstand zwischen der Ausgabe zweier Frames beträgt damit 0,04 Sekunden und auch diese Zeiteinheit wird oftmals als "Frame" bezeichnet, da Blizzard diese Bezeichnung in den Spieldateien verwendet. Diese Benennung ist jedoch äußerst unpraktisch, weil damit für ein Standbild und diese Zeiteinheit der selbe Begriff verwendet wird, was bei der detailierten Betrachtung der Animationen zu Komplikationen führt. Damit man beides unterscheiden kann, hat man für diese Zeiteinheit von 0,04 Sekunden die Bezeichnung "Tick" eingeführt.
Animationsablauf und formale Berechnung
Zu Beginn dieses Threads möchte ich erklären, wie eine Animation programmintern abläuft:
Das Programm ermittelt die Art der nächsten Animation und holt sich alle für die Berechnungen benötigten Werte aus diversen Spieldateien. Anschließend werden der Counter-Endwert und der Counter-Anstiegswert nach folgenden Formeln berechnet:
Counter-Endwert = Hitshift*FramesPerDirection
Counter-Anstiegswert = AnimationSpeed*Acceleration/100
Hitshift ... Das Ergebniss eines jeden Rechenschrittes wird als Integer-Wert (ganzzahliger Wert) abgespeichert, weshalb alle Nachkomastellen entfallen (entspricht für positive Werte einem Abrunden). Wir verwenden hier somit Divisionen mit ganzen Werten und damit werden die möglichen Abstufungen unseres Ergebnisses zu groß (zB 20, 10, 6, ... für die Divisionen 20/1, 20/2, 20/3, ...). Aus diesem Grund verwenden wir diesen Faktor in Dividend und Divisor, welcher für die Berechnung der Animationslängen einen Wert von 256 aufweist. Dadurch werden uns feinere Abstufungen ermöglicht (zB 20, 19, 18, ... für die Divisionen 5120/256, 5120/269, 5120/284, ...). Wie bereits erwähnt, muss das Hitshift auf beiden Seiten des Bruches auftreten, damit es sich anschließend wieder hinauskürzt. Im Divisor (Counter-Anstiegswert) ist das Hitshift auf den ersten Blick nicht erkennbar, weil es bereits in der AnimationSpeed inkludiert ist. Auch hier ist somit eine Feinabstimmung möglich, es gibt nun 256 Abstufungen mehr als zuvor.
FramesPerDirection ... Dies ist die Anzahl an Frames, aus der eine bestimmte Animation besteht. Der Wert wird somit klarerweise über die verwendete Animation bestimmt, sodass der Spieler keinen Einfluss darauf hat. Je mehr Frames eine bestimmte Animation besitzt, desto mehr Frames müssen abgespielt werden und desto länger dauert die Animation.
AnimationSpeed ... Dies ist der Grundwert der Geschwindigkeit, mit der eine Animation abgespielt wird. Der Standartwert liegt bei einem Frame pro Tick, wobei auch andere Werte möglich sind. Zwischen den Werten "1" und "2" der AnimationSpeed, gibt es eine Änderung von 100% und die Anschreibung als Integer-Wert lässt keine Zwischenstufen zu. Daher ist hier das Hitshift inkludiert, sodass wir zwischen den Werten 1 (=256) und 2 (=512) 256 Abstufungen erhalten und die Animationsdauern besser steuerbar sind.
Acceleration ... Dies ist ein Prozentwert und steuert die (positive wie negative) Beschleunigung der Animation. Dieser Wert ist für den Anwender einer bestimmten Animation die einzige Möglichkeit die Animationsdauer zu beeinflussen, alle anderen Werte sind vorgegeben. Je nach Art der verwendeten Animation fließen hier verschiedenste Werte in diese Berechnung ein. Die Grenzen dieses Wertes liegen bei 15 und 175. Um die Erklärung einfach und allgemein zu halten, werde ich vorerst bei diesem Begriff bleiben und die Zusammensetzung in den jeweiligen Teilbereichen erläutern.
Da das Spiel außschließlich Integer-Werte speichern kann, werden Counter-Endwert (der allerdings onehin nur ganzzahlig sein kann) und Counter-Anstiegswert abgerundet. Bei letzterem ist noch zu erwähnen, dass die Multiplikation vor der Division stattfindet, sodass auch nur der endgültige Wert gerundet werden muss. Nun sind die Berechnungen abgeschlossen und wir kommen zum nächsten Teil des Animationsablaufes.
Jede Animation besteht aus einer bestimmten Anzahl an Frames und die Summe all dieser bildet den FramesPerDirection-Wert. Welches Frame zu welchem Tick abgespielt wird, entscheidet nun die aktuelle Stellung des Counters. Die Anzahl der möglichen Counterstellungen entspricht natürlich dem Counter-Endwert und so teilen wir diese Zahl durch die Anzahl der Frames unserer Animation. Dies werde ich anhand eines Beispiels verdeutlichen und nehme dafür FramesPerDirection mit 5, AnimationSpeed mit 256 und Acceleration mit 100 an:
Counter-Endwert = Hitshift*FramesPerDirection = 256*5 = 1280
Counter-Anstiegswert = AnimationSpeed*Acceleration/100 = 256*100/100 = 256
Wir haben somit 1280 verschiedene Counterstellungen (von 0 bis 1279) und teilen diese auf 5 Frames auf. Somit hat jedes Frame genau 1280/5 = 256 Counterstellungen. Diese Zahl entspricht natürlich immer dem Hitshift, denn dessen Aufgabe war es schließlich die Anzahl der möglichen Counter-Stellungen pro Frame zu erhöhen. Dies sortieren wir nun anhand der Stellung des Counters:
Counter = 0000-0255 => Bild 00 wird dargestellt
Counter = 0256-0511 => Bild 01 wird dargestellt
Counter = 0512-0767 => Bild 02 wird dargestellt
Counter = 0768-1023 => Bild 03 wird dargestellt
Counter = 1023-1279 => Bild 04 wird dargestellt
Diese Tabelle könnten wir uns eigentlich auch ersparen, denn das darzustellende Frame lässt sich auch einfacher ermitteln. Wir müssen bloß unseren aktuellen Counter-Wert durch unser Hitshift dividieren und schneiden vom Ergebniss die Nachkomastellen ab. Damit erhalten wir ebenfalls für jeden Counter-Wert das abzuspielende Frame (zb [500/256] = [1,95] = 1 => Frame 01 wird dargestellt).
Da wir bei 0 beginnen, ist die Counterstellung 1280 kein Teil dieser Animation mehr. Sobald der Counter den Wert 1279 überschreitet, endet die aktuelle Animation und die nächste startet noch im selben Tick. Daher dürfen wir das Tick bei dem der Counter-Endwert erreicht bzw überschritten wird nicht mehr zu unserer ersten Animation zählen.
Jetzt starten wir unsere Animation, welche Tick für Tick abläuft. Am Anfang eines jeden Ticks wird der Counter um den errechneten Counter-Anstiegswert erhöht und anschließend abgefragt, ob der Counter-Endwert schon erreicht oder überschritten wurde (selbiges gilt auch für das FrameDataActionFlag, bei dem die Aktion wirklich durchgeführt wird). Ist dies nicht der Fall, wird ein Bild der Animation dargestellt. Sollte der Counter-Endwert jedoch schon erreicht/überschritten sein, endet die Animation. Die neue Animation (es läuft natürlich immer eine Animation nach der anderen ab) beginnt nun bei eben jenem Tick.
Die Animationen lassen sich in zwei Gruppen unterteilen. Einerseits können sie eine Art "Strafe" sein, weil sie eigentlich nichts bewirken aber Zeit beanspruchen. Dies ist zum Beispiel beim Blocken der Fall. Indem wir blocken, lösen wir die Blockanimation aus, doch diese bringt uns keinen Nutzen mehr, sondern hindert uns bloß daran weitere Aktionen in dieser Zeit auszuführen. Diese Animationen werden also durch eine Aktion ausgelöst, bewirken selbst allerdings keine.
Andererseits gibt es auch Animationen, die eine Aktion bewirken. Ein Beispiel dafür wäre die Angriffsanimation, den irgendwann zwischen Animationsstart und Animationsende (zum so genannten "kritischen Tick") wird der tatsächliche Angriff ausgeführt bzw ein Geschoss zum Angriff generiert. Diese Animationen brauchen eine Kennzeichnung, damit das Programm weiß, wann die Aktion auszulösen ist. Dazu gibt es in der animdata.d2 eine Auflistung der Frames von 000 bis 143 und der Zeitpunkt an dem die Aktion ausgelöst werden soll, ist für jede Animation in einer dieser Spalten durch einen Eintrag gekennzeichnet. Das gekennzeichnete Frame bezeichnet man als FrameDataActionFlag und wird in manchen Formeln benötigt. Dabei muss man allerdings berücksichtigen, dass wir den programminternen Ablauf durch diese Formeln nachvollziehen und somit die selben Regeln anwenden müssen. Für das Programm ist das erste Frame jenes mit der Bezeichnung 00, sodass wir bei der Angabe des FrameDataActionFlags ebenfalls die Bezeichnung (Bezeichnung bei 00 beginnend) und nicht die Reihenfolge in der Animation (Zählung bei 01 beginnend) verwenden müssen. Genauer werde ich darauf noch in den entsprechenden Teilbereichen (Zauber und Angriffe) eingehen.
Soweit zur Theorie, nun ein kurzes Beispiel zum leichteren Verständniss des Ablaufes:
FramesPerDirection = 3
AnimationSpeed = 256
Acceleration = 60
Counter-Endwert = Hitshift*FramesPerDirection = 256*3 = 768
Counter-Anstiegswert = AnimationSpeed*Acceleration/100 = 256*60/100 = 153
Counter = 000-255 => Bild 00 wird dargestellt
Counter = 256-511 => Bild 01 wird dargestellt
Counter = 512-767 => Bild 02 wird dargestellt
Tick 1:
Counter ist 0
Counter wird erhöht auf 153
Ist der Counter >= 768? Nein => kein Abbruch
[153/256] = 0 => Bild 00 abspielen
Tick 2:
Counter ist 153
Counter wird erhöht auf 306
Ist der Counter >= 768? Nein => kein Abbruch
[306/256] = 1 => Bild 01 abspielen
Tick 3:
Counter ist 306
Counter wird erhöht auf 459
Ist der Counter >= 768? Nein => kein Abbruch
[459/256] = 1 => Bild 01 abspielen
Tick 4:
Counter ist 459
Counter wird erhöht auf 612
Ist der Counter >= 768? Nein => kein Abbruch
[612/256] = 2 => Bild 02 abspielen
Tick 5:
Counter ist 612
Counter wird erhöht auf 765
Ist der Counter >= 768? Nein => kein Abbruch
[765/256] = 2 => Bild 02 abspielen
Tick 6:
Counter ist 765
Counter wird erhöht auf 918
Ist der Counter >= 768? Ja => Animation abbrechen, augenblicklicher Start der nächsten Animation
Dieses Tick zählt somit nicht mehr zu unserer Animation
Da das letzte Tick nicht mehr zur aktuellen Animation zählt, umfasst unsere Animation eine Dauer von 5 Ticks.
Diese Werte gelten für die Blockanimation eines Paladins ohne Heiligem Schild, der über 11 FBR verfügt. Ein Blick in diverse Tabellen bestätigt unser Ergebniss: eine Dauer von 5 Ticks. Außerdem fällt uns noch etwas auf, wenn wir Tick 5 betrachten. Die Differenz zwischen dem aktuellen Counterwert und dem Counter-Endwert beträgt nur "3", sodass auch schon die kleinstmögliche Erhöhung des Counter-Anstiegswertes die Animation weiter verkürzen würde. Wir stehen damit direkt vor einem Breakpoint, welche ich weiter unten noch behandeln werde.
Natürlich ist dieser interne Ablauf für uns nicht alzu relevant, denn die Ermittlung der Animationsdauer beansprucht mit dieser Methode zu viel Zeit. Daher wandeln wir den obigen Ablauf nun in eine Formel um.
Herleitung der Formel
Wie weiter oben schön ersichtlich ist, gibt uns die Dauer in Ticks an, wie oft wir den Counter um den Counter-Anstiegswert erhöhen mussten um den Counter-Endwert zu erreichen bzw zu überschreiten. Damit enspricht das Grundgerüst unserer Formel natürlich einer Division, weil wir zur Ermittlung der Dauer den Counter-Endwert durch den Counter-Anstiegswert dividieren müssen.
FPA = Counter-Endwert/Counter-Anstiegswert
Nun müssen wir beim Ergebniss dieser Division zwischen zwei Möglichkeiten unterschieden. Ist das Ergebniss eine ganze Zahl, so waren Counter-Endwert und Counter-Anstiegswert im letzten Tick ident. Damit zählt das letzte Tick nicht mehr, weil die Animation in diesem Tick abgebrochen wird. Somit müssen wir am Ende der Formel noch ein Tick abziehen.
Ist die Division allerdings nicht ganzzahlig (zB 3,5), so müssen wir den Wert aufrunden, denn nach drei Ticks ist der Counter-Endwert noch nicht erreicht, 3,5 Ticks sind nicht möglich und erst nach dem viertem Tick haben wir den Counter-Endwert überschritten. Auch in diesem Fall zählt das letzte Tick nicht mehr zur aktuellen Animation und wird damit ebenfalls am Ende abgezogen.
Im ersten Fall haben wir bereits eine ganze Zahl, sodass das Aufrunden nichts verändert und wir beide Fälle in einer Formel zusammenfassen können. Dabei setze ich diesmal gleich die Zusammensetzungen für Counter-Endwert und Counter-Anstiegswert ein:
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1
Oftmals bekommt man zu hören, dass das erste Frame einer Animation ident mit dem Letztem sei und deshalb nicht angezeigt werde, woraus das "-1" in der Formel resultiere. Dies stimmt allerdings nicht. Die beiden Frames sind unterschiedlich; wie ich oben veranschaulicht habe werden sie beide angezeigt und den Grund für die "-1" am Formelende habe ich ebenfalls erklärt.
Zum Vergleich der Formel mit dem internem Ablauf rechnen wir das vorherige Beispiel nochmal:
FramesPerDirection = 3
AnimationSpeed = 256
Acceleration = 60
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1
FPA = {(256*3)/[256*60/100]} - 1
FPA = {(768)/[153,6]} - 1
FPA = {(768)/[153,6]} - 1
FPA = {(768)/153} - 1
FPA = {5,02} - 1
FPA = 6 - 1
FPA = 5
Auch hier sehen wir wieder, dass wir kurz vor dem nächstem Breakpoint stehen und die Dauer von 5 Ticks deckt sich mit der vorherigen schritteweisen Berechnung, sodass unsere Formel richtig hergeleitet wurde.
Nun müssen wir nur noch die Zusammensetzung des Acceleration-Wertes wissen. Diese hängt allerdings von der verwendeten Animation ab, setzt sich jedoch immer zumindest aus einem Grundwert (ohne Grundwert hätte ein Malus keinen Effekt, sofern kein Bonus vorhanden ist oder dieser bereits negiert wurde) und einem Effektivwert zusammen. Zur Wahrung der Übersichtlichkeit werde ich diesen Teil der Formel in den jeweiligen Teilbereichen behandeln und nun mit der Ermittelung der Breakpoints fortfahren.
Breakpoints
Nun können wir uns für bestimmte Werte unsere Animationsgeschwindigkeit berechnen. Unser Interresse beruht allerdings hauptsächlich auf den Breakpoints, mit der reinen Berechnung mit vordefinierten Werten können wir nur wenig anfangen. Leider können wir hierfür allerdings keine Formel verwenden, da die explizite Anschreibung des Effektivwertes an dem Runden der Werte scheitert. Somit berechnen wir uns (zb in Excel) für jeden möglichen Acceleration-Wert die Anzahl der verwendeten Frames und notieren uns, bei welchem Wert wir den Sprung auf die nächstkürzere Animation schaffen. Je nach verwendeter Animation kann man sich dann berechnen, welche Eigenschaften man noch erhöhen kann, um den nächsten Breakpoint zu erreichen. Ein Beispiel für eine solche Berechnung:
Insgesammt dreimal anklicken, dann wird das Bild lesbar.
Rechts werden unsere Werte eingegeben und durch schrittweise Berechnung sehen wir, bei welchen Werten sich die Animation verkürzt. Dabei lässt man sich em besten gleich den Effektivwert umrechnen und kann den Wert somit einfach ablesen. Man muss bloß darauf achten den Grundwert (Teil der Acceleration) richtig anzugeben und keine Werte zu verwenden, die das Maximum von 175 überschreiten.
Animationsarten
Grundsätzlich kann man zwischen zwei Animationsarten unterscheiden. Die gewöhnliche Animation haben wir soeben mitsammt Ablauf und Formel kennengelernt. Diese Animationen können leicht eingesehen werden, weil die grundlegenden Werte softcoded sind. Das bedeutet, dass sie vom Spiel aus bestimmten Datein ausgelesen werden, welche für den Spieler leicht zugänglich sind und ausreichend Information enthalten. Für jede dieser Animationen gibt es eine Reihe von Frames, wobei der FramesPerDirection-Wert jeweils angibt, wie viele dieser Frames für eine jeweilige Animation wirklich verwendet werden.
Neben den bisher genannte Animationen gibt es auch die Sequenz-Animationen, welche von den bisher bekannten in mehreren Punkten abweichen. Den Sequenzen sind keine eigenen Frames zugewiesen, sondern sie bestehen aus vordefinierten Frames einer oder mehrerer Animationen. Von diesen Sequenzen sind leider nur jene softcoded, die von Monstern verwendet werden. Die Sequenzen der Spieler allerdings sind hardcoded, stecken also irgendwo an unbekannter Stelle in einer dll-Datei. Daher gibt es nur wenige, die diese Sequenzen ebenfalls auslesen können.
Die Formel für Sequenzen ist beinahe mit der bereits bekannten ident. Der einzige Unterschied besteht im Fehlen der "-1" am Formelende:
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]}
Sofern es sich bei einer Sequenz um einen Angriff (exklusive Zaubern) handelt, gibt es noch eine weitere Änderung, welche unsere SQ-Animation verlangsamt. Dies werde ich jedoch erst später im entsprechenden Teilbereich behandeln.
Auslesen der gebrauchten Werte
Wie bereits angesprochen, werden die Werte zu Anfang jeder Animation aus diversen Spieldateien ausgelesen. Dabei handelt es sich unter anderem um die Werte "FramesPerDirection" und "AnimationSpeed". Diese findet man in der animdata.d2, welche man aus der d2data.mpq extrahieren kann. Zum Extrahieren verwendet man das Programm "MPQView", welches im Mod-Starterkit auf der Mainpage enthalten ist. Um die Extrahierte animdata.d2 auslesen und verändern zu können, wandelt man sie mit dem Programm "Animdata_edit" in eine Textdatei um. Besagtes Programm findet man hier im PK in der Kategorie "Animation Editing".
Um sich dies zu ersparen, kann man auch diese Liste verwenden oder sich hier eine fertige und übersichtlichere animdata.txt herunterladen. Außerdem beinhalten die FAQtoids von librarian und ebenso meine FAQ die wesentlichsten Daten der Animationen.
Die Bezeichnungen dieser Animationen setzen sich aus 3 Teilen zusammen und verwenden das Schema CCAAWWW.
CC steht für "class" und gibt an, welche Spieleinheit diese Animation benutzt. Die wesentlichsten Kürzel lauten:
AI ... Assassine
AM ... Amazone
BA ... Barbar
DZ ... Druide
NE ... Nekromant
PA ... Paladin
SO ... Zauberin
40 ... Werwolf
TG ... Werbär
VA ... Vampir
FK ... Untoter Rattenmann
0A ... Barbarensöldner
GU ... Stadtwache
IW ... Eisenwolf
RG ... Rogue
Sollte man noch das Kürzel einer bestimmten Monsterart brauchen, findet man dieses in der Monstats.txt (muss man aus der Patch_D2.mpq extrahieren) in der Spalte "Code".
AA steht natürlich für "animation" und bezeichnet die Tätigkeit, bei welcher diese Animation verwendet wird. Die Kürzel lassen sich aus der PlrMode.txt auslesen und lauten:
A1 ... Angriff 1
A2 ... Angriff 2
KK ... Kick
TH ... Werfen
S1 ... Skill 1
S2 ... Skill 2
S3 ... Skill 3
S4 ... Skill 4
SC ... Zaubern
BL ... Blocken
GH ... Treffererholung
TN ... Neutral (in der Stadt stehen)
NU ... Neutral (außerhalb der Stadt stehen)
TW ... Gehen (in der Stadt)
WL ... Gehen (außerhalb der Stadt)
RN ... Rennen
DT ... Sterben
DD ... Leiche
SQ ... Sequenz
Die Sequenz ist dabei nur der Vollständigkeit halber angegeben, da sich diese bekanntlich aus Animationsteilen zusammensetzt und deren Daten somit nicht in der animdata.txt verzeichnet sind. Die Informationen über SQ-Animationen sind in der D2Common.dll verzeichnet, wobei der genaue Offset vom Patch abhängt.
WWW steht für "weapon class" und bezeichnet die verwendete Waffenart. Diese ist in der weapons.txt in der Spalte "wclass" bzw "2handedwclass" für jede Waffen-Grundklasse angegeben:
hth ... Faustkampf (keine Waffe)
ht1 ... eine Klaue
ht2 ... zwei Klauen
1hs ... einhändige Schwungwaffen (Schwerter, Äxte, Knüppel, Keulen, Szepter Hämmer, Wurfäxte)
2hs ... zweihändige Schwerter
1ht ... einhändige Stichwaffen (Dolche, Wurfspieße, Wurfmesser, Wurfelexiere)
2ht ... zweihändige Stichwaffen (Speere)
stf ... staves (Stangenwaffen sowie zweihändige Äxte, Hämmer und Stäbe)
bow ... Bögen
xbw ... Armbrüste
1ss ... zwei Schwungwaffen
1jt ... zwei Stichwaffen
1js ... links Stichwaffe, rechts Schwungwaffe
1st ... links Schwungwaffe, rechts Stichwaffe
Allerdings sind die Werte für ht1 und ht2 im ungemoddeten Spiel ident, sodass man nicht zu unterscheiden braucht.
Die letzten vier Animationen verwendet nur der Barbar, da keine andere Charakterklasse diese Waffen gleichzeitig tragen könnte. Glücklicherweise entfällt auch hier die Unterscheidung, denn die Werte der Animationen 1ss, 1jt, 1js und 1st sind (abgesehen von einer vernachlässigbaren Verschiebung des FrameDataActionFlags) gleich.
Damit hätten wir einmal die Grundlagen geklärt und ich werde nun mit den Anwendungen fortfahren. Aus Gründen der Übersichtlichkeit (zB leichteres Verlinken) bekommt dabei jede Animation einen eigenen Post. Außerdem habe ich dann genug Platz um zu jeder Animation alle weiteren nennenswerten Eigenschaften anzugeben. Für die reine Berechnung der Animationsdauer kann der erste Teil der folgenden Posts eventuell übersprungen werden.
Begriffserklärung
Das Spiel bietet verschiedene Eigenschaften um gewisse Animationen - zum Beispiel Angriffe oder Blockvorgänge - oder Bewegungen zu beschleunigen. Dieser Effekt verläuft jedoch nicht linear mit dem Anstieg der jeweiligen Eigenschaft, sondern es gibt bestimmte Stufen (auch "Breakpoints" genannt) bei denen eine Verbesserung eintritt (der Grund dafür ist unter anderem in dieser FAQ nachzulesen). Diese Eigenschaften sind unter folgenden Abkürzungen bekannt:
IAS = schnellere Angriffsgeschwindigkeit (Increased Attack Speed)
FCR = schnellere Zauberrate (Faster Cast Rate)
FBR = schnellere Abblockrate (Faster Block Rate)
FHR = schnellere Erholungsrate (Faster Hit Recovery)
FRW = schnelleres Gehen/Rennen (Faster Run / Walk)
Diese Eigenschaften werden spielintern jedoch nicht zur Berechnung herangezogen, denn sie werden zuerst in Effektivwerte umgerechnet. Die Abkürzung dieses Effektivwertes lautet damit je nach Eigenschaft klarerweise EIAS, EFCR, EFBR, EFHR bzw EFRW.
Um Speicherplatz einzusparen rechnet das Spiel intern ausschließlich mit Integer-Werten. Das bedeutet, dass sämtliche Werte nur ganzzahlig abgespeichert werden können. Sämtliche Nachkommastellen werden daher einfach abgeschnitten, was bei positiven Werten einem Abrunden bzw bei negativen Werten einem Aufrunden gleichkommt. In einer Formel kennzeichnet man die Art der Rundung oftmals durch die Verwendung unterschiedlicher Klammern:
[...] = Wert innerhalb der Klammern wird abgerundet
{...} = Wert innerhalb der Klammern wird aufgerundet
In bestimmten Formeln kann der zu rundende Wert sowohl negative als auch positive Werte annehmen, wodurch die Art der Rundung vom betreffenden Wert abhängig ist. Diese Möglichkeit sollte stets bedacht werden, vom gedankenlosen Anwenden einer Formel ist stets abzuraten.
Zwei zusammenhängende Begriffe, die oftmals in dieser FAQ verwendet werden, sind "Frame" und "Tick". Filme und Animationen bestehen aus Einzelbildern, welche so schnell abgespielt werden, dass die Bildfolge aufgrund der Trägheit unserer Augen als Bewegung wahrgenommen wird. Ein solches Einzelbild wird dabei als "Frame" bezeichnet. Die Spielmechanik spielt pro Sekunde 25 solcher Frames ab, um die Illusion einer Bewegung hervorzurufen. Der zeitliche Abstand zwischen der Ausgabe zweier Frames beträgt damit 0,04 Sekunden und auch diese Zeiteinheit wird oftmals als "Frame" bezeichnet, da Blizzard diese Bezeichnung in den Spieldateien verwendet. Diese Benennung ist jedoch äußerst unpraktisch, weil damit für ein Standbild und diese Zeiteinheit der selbe Begriff verwendet wird, was bei der detailierten Betrachtung der Animationen zu Komplikationen führt. Damit man beides unterscheiden kann, hat man für diese Zeiteinheit von 0,04 Sekunden die Bezeichnung "Tick" eingeführt.
Animationsablauf und formale Berechnung
Zu Beginn dieses Threads möchte ich erklären, wie eine Animation programmintern abläuft:
Das Programm ermittelt die Art der nächsten Animation und holt sich alle für die Berechnungen benötigten Werte aus diversen Spieldateien. Anschließend werden der Counter-Endwert und der Counter-Anstiegswert nach folgenden Formeln berechnet:
Counter-Endwert = Hitshift*FramesPerDirection
Counter-Anstiegswert = AnimationSpeed*Acceleration/100
Hitshift ... Das Ergebniss eines jeden Rechenschrittes wird als Integer-Wert (ganzzahliger Wert) abgespeichert, weshalb alle Nachkomastellen entfallen (entspricht für positive Werte einem Abrunden). Wir verwenden hier somit Divisionen mit ganzen Werten und damit werden die möglichen Abstufungen unseres Ergebnisses zu groß (zB 20, 10, 6, ... für die Divisionen 20/1, 20/2, 20/3, ...). Aus diesem Grund verwenden wir diesen Faktor in Dividend und Divisor, welcher für die Berechnung der Animationslängen einen Wert von 256 aufweist. Dadurch werden uns feinere Abstufungen ermöglicht (zB 20, 19, 18, ... für die Divisionen 5120/256, 5120/269, 5120/284, ...). Wie bereits erwähnt, muss das Hitshift auf beiden Seiten des Bruches auftreten, damit es sich anschließend wieder hinauskürzt. Im Divisor (Counter-Anstiegswert) ist das Hitshift auf den ersten Blick nicht erkennbar, weil es bereits in der AnimationSpeed inkludiert ist. Auch hier ist somit eine Feinabstimmung möglich, es gibt nun 256 Abstufungen mehr als zuvor.
FramesPerDirection ... Dies ist die Anzahl an Frames, aus der eine bestimmte Animation besteht. Der Wert wird somit klarerweise über die verwendete Animation bestimmt, sodass der Spieler keinen Einfluss darauf hat. Je mehr Frames eine bestimmte Animation besitzt, desto mehr Frames müssen abgespielt werden und desto länger dauert die Animation.
AnimationSpeed ... Dies ist der Grundwert der Geschwindigkeit, mit der eine Animation abgespielt wird. Der Standartwert liegt bei einem Frame pro Tick, wobei auch andere Werte möglich sind. Zwischen den Werten "1" und "2" der AnimationSpeed, gibt es eine Änderung von 100% und die Anschreibung als Integer-Wert lässt keine Zwischenstufen zu. Daher ist hier das Hitshift inkludiert, sodass wir zwischen den Werten 1 (=256) und 2 (=512) 256 Abstufungen erhalten und die Animationsdauern besser steuerbar sind.
Acceleration ... Dies ist ein Prozentwert und steuert die (positive wie negative) Beschleunigung der Animation. Dieser Wert ist für den Anwender einer bestimmten Animation die einzige Möglichkeit die Animationsdauer zu beeinflussen, alle anderen Werte sind vorgegeben. Je nach Art der verwendeten Animation fließen hier verschiedenste Werte in diese Berechnung ein. Die Grenzen dieses Wertes liegen bei 15 und 175. Um die Erklärung einfach und allgemein zu halten, werde ich vorerst bei diesem Begriff bleiben und die Zusammensetzung in den jeweiligen Teilbereichen erläutern.
Da das Spiel außschließlich Integer-Werte speichern kann, werden Counter-Endwert (der allerdings onehin nur ganzzahlig sein kann) und Counter-Anstiegswert abgerundet. Bei letzterem ist noch zu erwähnen, dass die Multiplikation vor der Division stattfindet, sodass auch nur der endgültige Wert gerundet werden muss. Nun sind die Berechnungen abgeschlossen und wir kommen zum nächsten Teil des Animationsablaufes.
Jede Animation besteht aus einer bestimmten Anzahl an Frames und die Summe all dieser bildet den FramesPerDirection-Wert. Welches Frame zu welchem Tick abgespielt wird, entscheidet nun die aktuelle Stellung des Counters. Die Anzahl der möglichen Counterstellungen entspricht natürlich dem Counter-Endwert und so teilen wir diese Zahl durch die Anzahl der Frames unserer Animation. Dies werde ich anhand eines Beispiels verdeutlichen und nehme dafür FramesPerDirection mit 5, AnimationSpeed mit 256 und Acceleration mit 100 an:
Counter-Endwert = Hitshift*FramesPerDirection = 256*5 = 1280
Counter-Anstiegswert = AnimationSpeed*Acceleration/100 = 256*100/100 = 256
Wir haben somit 1280 verschiedene Counterstellungen (von 0 bis 1279) und teilen diese auf 5 Frames auf. Somit hat jedes Frame genau 1280/5 = 256 Counterstellungen. Diese Zahl entspricht natürlich immer dem Hitshift, denn dessen Aufgabe war es schließlich die Anzahl der möglichen Counter-Stellungen pro Frame zu erhöhen. Dies sortieren wir nun anhand der Stellung des Counters:
Counter = 0000-0255 => Bild 00 wird dargestellt
Counter = 0256-0511 => Bild 01 wird dargestellt
Counter = 0512-0767 => Bild 02 wird dargestellt
Counter = 0768-1023 => Bild 03 wird dargestellt
Counter = 1023-1279 => Bild 04 wird dargestellt
Diese Tabelle könnten wir uns eigentlich auch ersparen, denn das darzustellende Frame lässt sich auch einfacher ermitteln. Wir müssen bloß unseren aktuellen Counter-Wert durch unser Hitshift dividieren und schneiden vom Ergebniss die Nachkomastellen ab. Damit erhalten wir ebenfalls für jeden Counter-Wert das abzuspielende Frame (zb [500/256] = [1,95] = 1 => Frame 01 wird dargestellt).
Da wir bei 0 beginnen, ist die Counterstellung 1280 kein Teil dieser Animation mehr. Sobald der Counter den Wert 1279 überschreitet, endet die aktuelle Animation und die nächste startet noch im selben Tick. Daher dürfen wir das Tick bei dem der Counter-Endwert erreicht bzw überschritten wird nicht mehr zu unserer ersten Animation zählen.
Jetzt starten wir unsere Animation, welche Tick für Tick abläuft. Am Anfang eines jeden Ticks wird der Counter um den errechneten Counter-Anstiegswert erhöht und anschließend abgefragt, ob der Counter-Endwert schon erreicht oder überschritten wurde (selbiges gilt auch für das FrameDataActionFlag, bei dem die Aktion wirklich durchgeführt wird). Ist dies nicht der Fall, wird ein Bild der Animation dargestellt. Sollte der Counter-Endwert jedoch schon erreicht/überschritten sein, endet die Animation. Die neue Animation (es läuft natürlich immer eine Animation nach der anderen ab) beginnt nun bei eben jenem Tick.
Die Animationen lassen sich in zwei Gruppen unterteilen. Einerseits können sie eine Art "Strafe" sein, weil sie eigentlich nichts bewirken aber Zeit beanspruchen. Dies ist zum Beispiel beim Blocken der Fall. Indem wir blocken, lösen wir die Blockanimation aus, doch diese bringt uns keinen Nutzen mehr, sondern hindert uns bloß daran weitere Aktionen in dieser Zeit auszuführen. Diese Animationen werden also durch eine Aktion ausgelöst, bewirken selbst allerdings keine.
Andererseits gibt es auch Animationen, die eine Aktion bewirken. Ein Beispiel dafür wäre die Angriffsanimation, den irgendwann zwischen Animationsstart und Animationsende (zum so genannten "kritischen Tick") wird der tatsächliche Angriff ausgeführt bzw ein Geschoss zum Angriff generiert. Diese Animationen brauchen eine Kennzeichnung, damit das Programm weiß, wann die Aktion auszulösen ist. Dazu gibt es in der animdata.d2 eine Auflistung der Frames von 000 bis 143 und der Zeitpunkt an dem die Aktion ausgelöst werden soll, ist für jede Animation in einer dieser Spalten durch einen Eintrag gekennzeichnet. Das gekennzeichnete Frame bezeichnet man als FrameDataActionFlag und wird in manchen Formeln benötigt. Dabei muss man allerdings berücksichtigen, dass wir den programminternen Ablauf durch diese Formeln nachvollziehen und somit die selben Regeln anwenden müssen. Für das Programm ist das erste Frame jenes mit der Bezeichnung 00, sodass wir bei der Angabe des FrameDataActionFlags ebenfalls die Bezeichnung (Bezeichnung bei 00 beginnend) und nicht die Reihenfolge in der Animation (Zählung bei 01 beginnend) verwenden müssen. Genauer werde ich darauf noch in den entsprechenden Teilbereichen (Zauber und Angriffe) eingehen.
Soweit zur Theorie, nun ein kurzes Beispiel zum leichteren Verständniss des Ablaufes:
FramesPerDirection = 3
AnimationSpeed = 256
Acceleration = 60
Counter-Endwert = Hitshift*FramesPerDirection = 256*3 = 768
Counter-Anstiegswert = AnimationSpeed*Acceleration/100 = 256*60/100 = 153
Counter = 000-255 => Bild 00 wird dargestellt
Counter = 256-511 => Bild 01 wird dargestellt
Counter = 512-767 => Bild 02 wird dargestellt
Tick 1:
Counter ist 0
Counter wird erhöht auf 153
Ist der Counter >= 768? Nein => kein Abbruch
[153/256] = 0 => Bild 00 abspielen
Tick 2:
Counter ist 153
Counter wird erhöht auf 306
Ist der Counter >= 768? Nein => kein Abbruch
[306/256] = 1 => Bild 01 abspielen
Tick 3:
Counter ist 306
Counter wird erhöht auf 459
Ist der Counter >= 768? Nein => kein Abbruch
[459/256] = 1 => Bild 01 abspielen
Tick 4:
Counter ist 459
Counter wird erhöht auf 612
Ist der Counter >= 768? Nein => kein Abbruch
[612/256] = 2 => Bild 02 abspielen
Tick 5:
Counter ist 612
Counter wird erhöht auf 765
Ist der Counter >= 768? Nein => kein Abbruch
[765/256] = 2 => Bild 02 abspielen
Tick 6:
Counter ist 765
Counter wird erhöht auf 918
Ist der Counter >= 768? Ja => Animation abbrechen, augenblicklicher Start der nächsten Animation
Dieses Tick zählt somit nicht mehr zu unserer Animation
Da das letzte Tick nicht mehr zur aktuellen Animation zählt, umfasst unsere Animation eine Dauer von 5 Ticks.
Diese Werte gelten für die Blockanimation eines Paladins ohne Heiligem Schild, der über 11 FBR verfügt. Ein Blick in diverse Tabellen bestätigt unser Ergebniss: eine Dauer von 5 Ticks. Außerdem fällt uns noch etwas auf, wenn wir Tick 5 betrachten. Die Differenz zwischen dem aktuellen Counterwert und dem Counter-Endwert beträgt nur "3", sodass auch schon die kleinstmögliche Erhöhung des Counter-Anstiegswertes die Animation weiter verkürzen würde. Wir stehen damit direkt vor einem Breakpoint, welche ich weiter unten noch behandeln werde.
Natürlich ist dieser interne Ablauf für uns nicht alzu relevant, denn die Ermittlung der Animationsdauer beansprucht mit dieser Methode zu viel Zeit. Daher wandeln wir den obigen Ablauf nun in eine Formel um.
Herleitung der Formel
Wie weiter oben schön ersichtlich ist, gibt uns die Dauer in Ticks an, wie oft wir den Counter um den Counter-Anstiegswert erhöhen mussten um den Counter-Endwert zu erreichen bzw zu überschreiten. Damit enspricht das Grundgerüst unserer Formel natürlich einer Division, weil wir zur Ermittlung der Dauer den Counter-Endwert durch den Counter-Anstiegswert dividieren müssen.
FPA = Counter-Endwert/Counter-Anstiegswert
Nun müssen wir beim Ergebniss dieser Division zwischen zwei Möglichkeiten unterschieden. Ist das Ergebniss eine ganze Zahl, so waren Counter-Endwert und Counter-Anstiegswert im letzten Tick ident. Damit zählt das letzte Tick nicht mehr, weil die Animation in diesem Tick abgebrochen wird. Somit müssen wir am Ende der Formel noch ein Tick abziehen.
Ist die Division allerdings nicht ganzzahlig (zB 3,5), so müssen wir den Wert aufrunden, denn nach drei Ticks ist der Counter-Endwert noch nicht erreicht, 3,5 Ticks sind nicht möglich und erst nach dem viertem Tick haben wir den Counter-Endwert überschritten. Auch in diesem Fall zählt das letzte Tick nicht mehr zur aktuellen Animation und wird damit ebenfalls am Ende abgezogen.
Im ersten Fall haben wir bereits eine ganze Zahl, sodass das Aufrunden nichts verändert und wir beide Fälle in einer Formel zusammenfassen können. Dabei setze ich diesmal gleich die Zusammensetzungen für Counter-Endwert und Counter-Anstiegswert ein:
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1
Oftmals bekommt man zu hören, dass das erste Frame einer Animation ident mit dem Letztem sei und deshalb nicht angezeigt werde, woraus das "-1" in der Formel resultiere. Dies stimmt allerdings nicht. Die beiden Frames sind unterschiedlich; wie ich oben veranschaulicht habe werden sie beide angezeigt und den Grund für die "-1" am Formelende habe ich ebenfalls erklärt.
Zum Vergleich der Formel mit dem internem Ablauf rechnen wir das vorherige Beispiel nochmal:
FramesPerDirection = 3
AnimationSpeed = 256
Acceleration = 60
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]} - 1
FPA = {(256*3)/[256*60/100]} - 1
FPA = {(768)/[153,6]} - 1
FPA = {(768)/[153,6]} - 1
FPA = {(768)/153} - 1
FPA = {5,02} - 1
FPA = 6 - 1
FPA = 5
Auch hier sehen wir wieder, dass wir kurz vor dem nächstem Breakpoint stehen und die Dauer von 5 Ticks deckt sich mit der vorherigen schritteweisen Berechnung, sodass unsere Formel richtig hergeleitet wurde.
Nun müssen wir nur noch die Zusammensetzung des Acceleration-Wertes wissen. Diese hängt allerdings von der verwendeten Animation ab, setzt sich jedoch immer zumindest aus einem Grundwert (ohne Grundwert hätte ein Malus keinen Effekt, sofern kein Bonus vorhanden ist oder dieser bereits negiert wurde) und einem Effektivwert zusammen. Zur Wahrung der Übersichtlichkeit werde ich diesen Teil der Formel in den jeweiligen Teilbereichen behandeln und nun mit der Ermittelung der Breakpoints fortfahren.
Breakpoints
Nun können wir uns für bestimmte Werte unsere Animationsgeschwindigkeit berechnen. Unser Interresse beruht allerdings hauptsächlich auf den Breakpoints, mit der reinen Berechnung mit vordefinierten Werten können wir nur wenig anfangen. Leider können wir hierfür allerdings keine Formel verwenden, da die explizite Anschreibung des Effektivwertes an dem Runden der Werte scheitert. Somit berechnen wir uns (zb in Excel) für jeden möglichen Acceleration-Wert die Anzahl der verwendeten Frames und notieren uns, bei welchem Wert wir den Sprung auf die nächstkürzere Animation schaffen. Je nach verwendeter Animation kann man sich dann berechnen, welche Eigenschaften man noch erhöhen kann, um den nächsten Breakpoint zu erreichen. Ein Beispiel für eine solche Berechnung:
Insgesammt dreimal anklicken, dann wird das Bild lesbar.
Rechts werden unsere Werte eingegeben und durch schrittweise Berechnung sehen wir, bei welchen Werten sich die Animation verkürzt. Dabei lässt man sich em besten gleich den Effektivwert umrechnen und kann den Wert somit einfach ablesen. Man muss bloß darauf achten den Grundwert (Teil der Acceleration) richtig anzugeben und keine Werte zu verwenden, die das Maximum von 175 überschreiten.
Animationsarten
Grundsätzlich kann man zwischen zwei Animationsarten unterscheiden. Die gewöhnliche Animation haben wir soeben mitsammt Ablauf und Formel kennengelernt. Diese Animationen können leicht eingesehen werden, weil die grundlegenden Werte softcoded sind. Das bedeutet, dass sie vom Spiel aus bestimmten Datein ausgelesen werden, welche für den Spieler leicht zugänglich sind und ausreichend Information enthalten. Für jede dieser Animationen gibt es eine Reihe von Frames, wobei der FramesPerDirection-Wert jeweils angibt, wie viele dieser Frames für eine jeweilige Animation wirklich verwendet werden.
Neben den bisher genannte Animationen gibt es auch die Sequenz-Animationen, welche von den bisher bekannten in mehreren Punkten abweichen. Den Sequenzen sind keine eigenen Frames zugewiesen, sondern sie bestehen aus vordefinierten Frames einer oder mehrerer Animationen. Von diesen Sequenzen sind leider nur jene softcoded, die von Monstern verwendet werden. Die Sequenzen der Spieler allerdings sind hardcoded, stecken also irgendwo an unbekannter Stelle in einer dll-Datei. Daher gibt es nur wenige, die diese Sequenzen ebenfalls auslesen können.
Die Formel für Sequenzen ist beinahe mit der bereits bekannten ident. Der einzige Unterschied besteht im Fehlen der "-1" am Formelende:
FPA = {(Hitshift*FramesPerDirection)/[AnimationSpeed*Acceleration/100]}
Sofern es sich bei einer Sequenz um einen Angriff (exklusive Zaubern) handelt, gibt es noch eine weitere Änderung, welche unsere SQ-Animation verlangsamt. Dies werde ich jedoch erst später im entsprechenden Teilbereich behandeln.
Auslesen der gebrauchten Werte
Wie bereits angesprochen, werden die Werte zu Anfang jeder Animation aus diversen Spieldateien ausgelesen. Dabei handelt es sich unter anderem um die Werte "FramesPerDirection" und "AnimationSpeed". Diese findet man in der animdata.d2, welche man aus der d2data.mpq extrahieren kann. Zum Extrahieren verwendet man das Programm "MPQView", welches im Mod-Starterkit auf der Mainpage enthalten ist. Um die Extrahierte animdata.d2 auslesen und verändern zu können, wandelt man sie mit dem Programm "Animdata_edit" in eine Textdatei um. Besagtes Programm findet man hier im PK in der Kategorie "Animation Editing".
Um sich dies zu ersparen, kann man auch diese Liste verwenden oder sich hier eine fertige und übersichtlichere animdata.txt herunterladen. Außerdem beinhalten die FAQtoids von librarian und ebenso meine FAQ die wesentlichsten Daten der Animationen.
Die Bezeichnungen dieser Animationen setzen sich aus 3 Teilen zusammen und verwenden das Schema CCAAWWW.
CC steht für "class" und gibt an, welche Spieleinheit diese Animation benutzt. Die wesentlichsten Kürzel lauten:
AI ... Assassine
AM ... Amazone
BA ... Barbar
DZ ... Druide
NE ... Nekromant
PA ... Paladin
SO ... Zauberin
40 ... Werwolf
TG ... Werbär
VA ... Vampir
FK ... Untoter Rattenmann
0A ... Barbarensöldner
GU ... Stadtwache
IW ... Eisenwolf
RG ... Rogue
Sollte man noch das Kürzel einer bestimmten Monsterart brauchen, findet man dieses in der Monstats.txt (muss man aus der Patch_D2.mpq extrahieren) in der Spalte "Code".
AA steht natürlich für "animation" und bezeichnet die Tätigkeit, bei welcher diese Animation verwendet wird. Die Kürzel lassen sich aus der PlrMode.txt auslesen und lauten:
A1 ... Angriff 1
A2 ... Angriff 2
KK ... Kick
TH ... Werfen
S1 ... Skill 1
S2 ... Skill 2
S3 ... Skill 3
S4 ... Skill 4
SC ... Zaubern
BL ... Blocken
GH ... Treffererholung
TN ... Neutral (in der Stadt stehen)
NU ... Neutral (außerhalb der Stadt stehen)
TW ... Gehen (in der Stadt)
WL ... Gehen (außerhalb der Stadt)
RN ... Rennen
DT ... Sterben
DD ... Leiche
SQ ... Sequenz
Die Sequenz ist dabei nur der Vollständigkeit halber angegeben, da sich diese bekanntlich aus Animationsteilen zusammensetzt und deren Daten somit nicht in der animdata.txt verzeichnet sind. Die Informationen über SQ-Animationen sind in der D2Common.dll verzeichnet, wobei der genaue Offset vom Patch abhängt.
WWW steht für "weapon class" und bezeichnet die verwendete Waffenart. Diese ist in der weapons.txt in der Spalte "wclass" bzw "2handedwclass" für jede Waffen-Grundklasse angegeben:
hth ... Faustkampf (keine Waffe)
ht1 ... eine Klaue
ht2 ... zwei Klauen
1hs ... einhändige Schwungwaffen (Schwerter, Äxte, Knüppel, Keulen, Szepter Hämmer, Wurfäxte)
2hs ... zweihändige Schwerter
1ht ... einhändige Stichwaffen (Dolche, Wurfspieße, Wurfmesser, Wurfelexiere)
2ht ... zweihändige Stichwaffen (Speere)
stf ... staves (Stangenwaffen sowie zweihändige Äxte, Hämmer und Stäbe)
bow ... Bögen
xbw ... Armbrüste
1ss ... zwei Schwungwaffen
1jt ... zwei Stichwaffen
1js ... links Stichwaffe, rechts Schwungwaffe
1st ... links Schwungwaffe, rechts Stichwaffe
Allerdings sind die Werte für ht1 und ht2 im ungemoddeten Spiel ident, sodass man nicht zu unterscheiden braucht.
Die letzten vier Animationen verwendet nur der Barbar, da keine andere Charakterklasse diese Waffen gleichzeitig tragen könnte. Glücklicherweise entfällt auch hier die Unterscheidung, denn die Werte der Animationen 1ss, 1jt, 1js und 1st sind (abgesehen von einer vernachlässigbaren Verschiebung des FrameDataActionFlags) gleich.
Damit hätten wir einmal die Grundlagen geklärt und ich werde nun mit den Anwendungen fortfahren. Aus Gründen der Übersichtlichkeit (zB leichteres Verlinken) bekommt dabei jede Animation einen eigenen Post. Außerdem habe ich dann genug Platz um zu jeder Animation alle weiteren nennenswerten Eigenschaften anzugeben. Für die reine Berechnung der Animationsdauer kann der erste Teil der folgenden Posts eventuell übersprungen werden.
