Stolperhannes
Well-known member
- Registriert
- 5 April 2004
- Beiträge
- 1.502
- Punkte Reaktionen
- 0
Da das eine längere Geschichte wird, kübele ich den Text Stück für Stück ins Mod-Forum. Bis alles da ist kann noch dauern.
Mittlerweile habe ich ein paar Problemchen. Schaut einfach mal nach. Aktueller Stand 7 von 23 Seiten.
The Phrozen Keep Forum Index -> Knowledge Base -> File Guides -> File Guides (1.10-1.11x)
Skills.txt
Description by Nefarius
Author Nefarius
Date Fri May 11, 2007 4:37 pm
Type File Guide
Category File Guides (1.10-1.11x)
Views 2875
Skills.txt
SKILLS.TXT FILE GUIDE
by Nepharius
Skills.txt, war für eine lange Zeit (1.00 bis 1.09) eine ziemlich kleine Datei, in der man nur ein paar wenige Dinge ändern konnte (das war hauptsächlich begrenzt auf die Animationen, die benutzt wurden, die Parameter, die einen Skill durchlaufen und der Schaden, den ein Skill verursacht). Der Rest war komplett fest programmiert (hardcoded). Wie die Skills selbst arbeiten ist immer noch fest programmiert (die Skillfunktionen), aber alle anderen Aspekte ihres Verhaltens konn jetzt über skills.txt gesteuert werden, inklusive welche Skills welche Funktionen verwenden. Die Datei ist riesig, bei weitem die größte und komplizierteste in Diablo II. Sie enthält 256 Spalten. Das ist das Maximum, das MS Excel unterstützt. Der Zweck dieses Fileguides ist nicht einen 100% akurate Beschreibung jeder Spalte anzubieten, weil dies einfach unmöglich ist. (wie einige der Spalten benutzt werden, hängt zu allermeist von der Skillfunktion ab, die auf die entsprechende Spalte zugreift!). Ich will hier auch keine Formeln behandeln, Xeno schrieb bereits einen eindrucksvollen Guide über Formeln, die vom D2-Parser akzeptiert werden. Es gibt keinen Grund, dies hier zu wiederholen.
ALLGEMEINE SKILL EINSTELLUNGEN
skill: Der ID-Zeiger (ID pointer) wird als Bezug auf diesen Skill innerhalb von CharStats.txt, Missiles.txt and Monstats.txt und SkillDesc.txt verwendet. Er wird aber auch innerhalb von Skills.txt selbst verwendet. Dieser ID pointer kann auch innerhalb von AutoMagic, Gems, MagicPrefix, MagicSuffix, MonProp, QualityItems, Runes, SetItems, Sets und UniqueItems.txt verwendet werden. Wie dem auch sei, der Parser, der für diese Dateien verwendet wird ist verbugt und Skillnamen mit einer Leerstelle (space) scheitern öfter, als dass sie ordentlich funktionieren (Bloß weil Blizzard damit umgehen kann, glaube ja nicht, dass wir das können!). Ich empfehle dringend, die aktuellen ID-Nummern (ID numbers) statt der ID-Zeiger (ID pointer) in diesen Dateien zu verwenden. ACHTUNG: Benutze niemals den gleichen ID pointer doppelt oder mehrfach. Alle Skills mit gleichen Zeiger, außer dem ersten, werden ignoriert!
Id: Die aktuelle ID-Nummer (ID number) des Skills. Das ist die Stelle auf die der ID-Zeiger (ID pointer) tatsächlich zeigt. Es muss eine einzigartige Zahl sein. Das Spiel unterstützt 32767 Skills, aber wir werden sie im Zusammenhang mit Items nicht nutzen können bis wir ItemStatCost.txt modifiziert haben. Codierte Stats (encoded stats) ( xx% Chance eine Level xx Wirkung/Skill auf Aktion auszuführen (chance to cast level xxx yyy on zzz), und Ladungen (charges)) können nur IDs bis 1023 speichern und verwenden, ganz gleich was man tut. ACHTUNG: Einige IDs beziehen sich auf Programmcode (solche wie Auras, die von Bossen verwendet werden). Man sollte sich dies vor Augen führen, bevor man beginnt innerhalb der Datei Skills bunt durcheinander zu würfeln. Zumindest bis man weiß, was man da macht.
charclass: Beschreibt welcher Characterklasse dieser Skill zugeordnent ist. Dieser Eintrag steuert hauptsächlich aus welcher Grafikbibliothek (DC6 icon library) die Skillbilder(skill icons) ausgewählt werden und welche Boni dieser Skill bewirken wird. (+zu allen Amazonenfertigkeiten etc). ACHTUNG: Alle Charactere müssen die gleiche Anzahl von Skills haben, weil sonst nur die Klasse
mit der höchsten Anzahl Skills ein Spiel betreten kann. (Weil das Spiel darauf vorbereitet ist Dateien für jede Klasse mit xxx Skills zu speichern, werden Spielstände für Klassen mit weniger als xxx Skills als "defekt" behandelt. Um dieses Problem zu lösen, muß man nur eine Anzahl von Dummy-Skills für diese Klasse definieren. (Diese Dummy-Skills werden nicht im Skillbaum erscheinen oder auf eine sonstige Weise zu benutzen sein). Wenn man diese Spalte frei läßt, dann bedeutet das, dass dieser Skill nicht irgend einer/ nicht einer bestimmten Klasse zugeordnet ist. (< --- Anm. Keine Ahnung --- >)
skilldesc: Der ID pointer von SkillDesc.txt. Diese Datei steuert alle Benutzerschnittstelle bezogene Aspekte des Skills, wie z.B. welches Skillicon verwendet wird, der Text, der in der Skillbeschreibung angezeigt wird und ob bzw. wie Schaden und Angriffswert (damage and attack rating) im Characterbildschirm angezeigt wird. ACHTUNG: Benutze niemals zwei identische Einträge für den gleichen Skill, wenn sie der gleichen Characterklasse zugeordnet sind, außer natürlich, man mag Programmabstürze.
SERVER-SEITIGE SKILL FUNKTIONEN
Diese Funktionen waren ursprünglich auf im Programmcode fest codierte Tabellen während Patch 1.00-1.09 bezogen. Seit 1.10 sind diese Funktionen tabellenbezogen codiert (softcoded) und können nun durch editieren der Skills in skills.txt modifiziert werden. Hier sitzt das Herz und die Seele des Skills. Nahezu alles, dass einen Skill von einem anderen Skill unterscheidet, werden durch die jeweils verwendeten Funktionen gesteuert. Diese Funktionen sind aber nicht alleine darauf beschränkt: Immer dann wenn ein Skill verschiedene Zustände verwendet, immer dann wenn die Berechnungsspalten (calc columns) verwendet werden, immer dann wenn sich der Programmcode auf eine Variable (parameter) direkt bezieht, immer dann wenn ein Geschoss abgefeuert wird und wie ein Geschoss abgefeuert wird, genau dann sind sie im Einsatz und noch für denkbar vieles mehr.
srvstfunc: Server Start Funktion. Diese entscheidet welche Serverseitige Funktion ausgeführt wird, sobald man irgendwo rechtsklickt oder shift+linksklickt wenn der Skill einer Taste zugeordnet ist.
srvdofunc: Server Ende Funktion. Diese entscheidet welche Serverseitige Funktion ausgeführt wird, sobald die Server Start Funktion ihre Ausführung beendet hat. Es ist möglich, dass sie entweder andauernd aufgerufen wird solange der Mausknopf gedrückt ist, oder dass sie nur periodisch aufgerufen wird (Für Skills wie Paladin Auras und Klingenschild (blade shield)).
prgstack: Enthält eine logische Variable (Boolean), wird von Aufladeskills verwendet. Wahr (true) bedeutet, dass die einzelnen Ladungen auf dem Stapel gespeichert werden (Feuerfäuste (Fists of Fire),Donnerklauen (Claws of Thunder) und Eisklingen (Blades of Ice)). Falsch (false) bedeutet, dass jede neue Ladung die vorangegangene ersetzt. (Phönixschlag (Phoenix Strike etc)). Und tatsächlich, alle drei Ladungen von Phönixschlag (Phoenix Strike) können gleichzeitig vorkommen, sobald man prgstack auf true setzt.
srvprgfunc1: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 1 (durch die Benutzung eines finishing moves)ausgelöst wird.
srvprgfunc2: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 2 (durch die Benutzung eines finishing moves)ausgelöst wird.
srvprgfunc3: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 3 (durch die Benutzung eines finishing moves)ausgelöst wird.
prgcalc1: Berechnung, die von serverseitigen Funktionen bei Ladung 1 (charge number 1) verwendet wird (diese Spalte wird auch von Schocknetz (Shock Web) und Klingenwut (Blade Fury) verwendet. Die serverseitigen Skillfunktionen dieser Skills greifen darauf zu!).
prgcalc2: Berechnung, die von serverseitigen Funktionen bei Ladung 2 verwendet wird.
prgcalc3: Berechnung, die von serverseitigen Funktionen bei Ladung 3 verwendet wird.
prgdam: Bezieht sich auf die sehr fest programmierten progressiven Eigenschaften (stats).
1 wird im Zusammenhang mit PROGRESSIVE_DAMAGE verwendet,
2 wird im Zusammenhang mit PROGRESSIVE_STEAL verwendet,
3 wird im Zusammenhang mit dem nicht benutzten PROGRESSIVE_OTHER Eigenschaften(stat) und
4 wird im Zusammenhang mit PROGRESSIVE_ Eigenschaften (stats) verwendet.
Ich habe hier weiter recherchiert, aber das Hinzufügen von weiteren progressiven Eigenschaften (stats) erweitert die Liste der angesprungenen Funktionen! (Anm. Vermutlich im Programmcode)
(Original: I have yet to do research on this, but adding new progressive stats would involde (vermutlich Schreibfehler, involve?) expanding the list of functions linked to by this field! Übersetzungideen? Der Satz ist so ziemlich "geraten" geraten...)
SERVER-SEITIGE GESCHOSS EINSTELLUNGEN
Diese Spalten steuern die unterschiedlichsten Aspekte auf Serverseite wenn Geschosse durch einen Skill abgefeuert werden. Das ist vollkommen unabhängig davon was der Spieler (der client) auf seinem Bildschirm sieht. Diese clientseitigen Geschosseinstellungen müssen dazu passen. Das vermeidet sonderbares Verhalten des Programms und nebenbei dämliche Fragen von Benutzer (stupid questions
). Man muss sie jedoch nicht passend machen. Das hat keinen nachteiligen Effekt im Programmablauf. Nur: Das Geschoss wird auf dem Bildschirm nicht erscheinen oder zumindest nicht auf die Weise wie es sollte.
srvmissile: Das primäre Geschoss, das abgefeuert wird wenn die Server Start Funktion (srvstfunc) ausgeführt wird. Dieser Abschuß ist unabhängig davon ob überhaupt eine serverseitige Startfunktion mit einbezogen ist. (Das gilt auch wenn überhaupt keine Funktion ausgeführt wird: siehe Feuerball (fireball) and Feuerblitz (firebolt) als Beispiel).
decquant: Enthält eine logische Variable (Boolean), die steuert wann ein Skill den Stapel (siehe prgstack) oder Munition verringert und zwar jedes mal wenn die Start Funktion ausgeführt wird. (Sie ist für Streuen (strafe) deaktiviert (false), wird sie aktiviert (true), dann wird Streuen (strafe) genauso viele Pfeile verbrauchen wie man abfeuert).
lob: Enthält auch eine logische Variable (Boolean). Wenn sie auf wahr (true) gesetzt wird fliegt das Geschoss einen Lob (steil abgeschossen wie eine Granate mit hoher Flugbahn). Ein lobbendes Geschoss verschwindet (bzw. kollidiert mit dem Boden) an dem Ort wo man mit der Maus hingeklickt hat. Achtung: Ein lobbendes Geschoss (lobbed) scheint nur in einem Bogen zu fliegen. Deshalb wird das Geschoss allem Monster etc. weiterhin Schaden zufügen, als hätte es nicht die hohe Flugbahn. Damit sich ein passendes Verhalten des Geschosses mit hoher Flugbahn einstellt, muss das Geschoss geeignet modifiziert werden. (siehe den Missiles.txt Fileguide).
srvmissilea: Erstes sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
srvmissileb: Zweites sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
srvmissilec: Drittes sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
SERVER GESTEUERTE EINBLENDUNGEN (OVERLAYS)
srvoverlay: Einblendungen bzw. Überlagerungen werden normalerweise von clientseitigen Programmcode gesteuert. Davon abgesehen: Aktionsabhängige (mission-critical) Einblendungen werden von serverseitigen Programmcode behandelt. Das betrifft normalerweise die Einblendungen bei anvisierten Objekten. Sie werden im Verlauf der serverseitige Ende Funktion ausgeführt. Aktionsabhängige Einblendungen sind die, die von Nahkampfangriffe verwendet werden. Verschiedene Monster, die buffs??/Flüche (buffs??/curses) anwenden verwenden sie und Himmelsfaust (Fist of the Heavens) verwendet sie auch. (das sich abwärts bewegende Geschoss ist tatsächlich eine (Anm. serverseitige) Einblendung). Der Eintrag ist ein ID pointer von Overlays.txt. Wann und ob er genutzt wird ist von der benutzten serverseitigen Ende Funktion abhängig.
AURA / FLUCH / ANHALTENDE WIRKUNGEN BEZOGENE EINSTELLUNGEN
Diese Spalten müssen nicht notwendigerweise nur durch Auren/Flüche/Buff?? verwendet werden. Das Spiel verwendet diese Felder zum Beispiel auch für Skills, die irgend eine Art von Suchradius besitzen oder auch ein "AoE". (< -- "AoE". -- > Was ist das?)
aurafilter: Dies ist ein bitweiser Filter, welcher steuert was für eine Art von Einheit durch diesen Skill beeinflußt wird. Eine Diskussion darüber wie der aurafilter arbeitet kann hier gefunden werden (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?t=18470) Nicht alle Aurafilterwerte arbeiten in geeigneter Weise mit allen Skills zusammen. Das ist weitgehend abhängig davon, wie die serverseitigen Skillfunktionen nach potenziellen Zielen suchen! Aurafilter wird von den meisten zielsuchenden Skills verwendet.
Code:
0001000010110000011 - inner sight, taunt
0001100010110000011 - slow missiles
0001010010110000011 - lightning fury, conviction, tornado
0001000011110000011 - static field
0000000000000000011 - amplify damage, weaken, iron maiden, life tap, decrepify, lower resist [work on bosses]
0000000000000000010 - dim vision, terror, confuse, attract, grim ward [don't work on bosses]
0010010000000000011 - might, prayer, resist fire, thorns, defiance, resist cold, blessed aim, cleansing, resist lightning, concentration, vigor, fanaticism, salvation, defense curse, blood mana
0001010011110000011 - holy fire, holy shock, hurricane
1001010001010000011 - holy freeze
0001110011110000110 - sanctuary
0001010010110000111 - fist of the heavens
0000001000100000010 - redemption
1100000000000000000 - battle cry
0001110000000000011 - cloak of shadows
0001000001110000011 - mind blast, blade shield
0001000011100001011 - blades of ice
0010000000100000011 - spirit of barbs aura, heart of wolverine aura, oak sage aura
aurastate: Beschreibt die Auswirkungen (state), die dem Caster (Benutzer) der Aura / buff / Fluchs zugeordnet werden. Im Falle von Verzaubern (enchant) gelten die Auswirkungen für die Einheit, auf die der Skill angewendet wurde. Hier wird ein ID pointer von States.txt eingetragen. Achtung: Man sollte nicht versuchen, die gleiche Wirkung (state) aus state.txt auf mehr als einen Skill zu ermöglichen, wenn diese Skills beim gleichen Character oder Monster zum Einsatz kommen. Das Spiel benutzt eine Indextabelle um die verwendete Wirkung (state) zu bestimmen (und auf diese Weise bestimmen welche Wirkungen (stat) wechseln) die gerade bei einem Char/Monster (unit) aktiv ist. Eine Wirkung die gerade bei einem Char/Monster (unit) aktiv ist, kann nicht noch einmal hinzugefügt werden während die erste (gleiche) Wirkung noch aktiv ist. Folglicherweise werden zwei Skills mit der gleichen Wirkung niemals gleichzeitig zur Geltung kommen. Das heißt nicht, dass sie immer ein "übereinanderstapeln" (stacking) verhindern. Es heißt nur, dass man dann größte Erfahrung mit Störungen bzw. überhöhten Wirkungen (glitches) sammeln kann.
auratargetstate: Das sind die Auswirkungen, die dem Empfänger der Aura / buff / Fluches zugeordnet sind. Hier wird ein ID pointer von States.txt eingetragen. Achtung: Hier gelten die gleichen Aussagen über Mechanismen und Probleme wie bei aurastate.
auralencalc: Dieses Feld kann entweder eine Berechnung oder einen festen Wert (static value) beinhalten. Es steuert wie lange (in frames) die Effekte der Aura / buff / Fluchs anhalten. Echte Auren benutzen dieses Feld nicht, weil sie periodisch erneuert werden.
aurarangecalc: Dieses Feld kann entweder eine Berechnung oder einen festen Wert (static value) beinhalten. Er steuert die Größe des Gebietes (in subtiles) in welchen die Aura / buff / Fluch auf Char/Monster (unit) wirkt. Einige andere Skilltypen verwenden dieses Feld auch (wie Blitzendes Unheil (Lightning Fury)) um den Such- oder Schadensradius von den entsprechenden Skills ausgelösten Geschossen zu bestimmen.
aurastat1-6: Die Wirkung dieser Aura / buff / Fluches kann sich ändern. Es enthält ID pointer aus ItemStatCost.txt.
aurastatcalc1-6: Die Werte, die der fraglichen Wirkung (state) hinzugefügt oder abgezogen wird. Die in dieses Felder einzutragende Werte sind begrenzt auf Werte zwischen -2147483647 und +2147483647. Höhere oder niedrigere Werte führen zu einem überrollen der Zahl.
auraevent1-3: Diese Felder bestimmen welche Ereignisse (events) mit Aura / Fluch / buff reagieren sollten, wenn dieses Ereignis beim Caster (Benutzer) dieses Skills eintritt. Hier wird ein ID pointer aus Events.txt eingetragen.
auraeventfunc1-3: Diese Felder bestimmen die Funktionen, die ausgeführt werden, wenn das entsprechende Ereignis auftritt (wie oben beschrieben, Sie beziehen sich nur auf den caster des Skills alleine). Eine Liste der Ereignisfuktionen kann hier gefunden werden: (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?p=259558#259558)Achtung: Die große Mehrheit dieser Funktionen werden nicht richtig bearbeitet, wenn sie durch einen Skill aufgerufen wurden.
auratgtevent: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, ist dieses Feld ein Equivalent zu den auraevent Spalten. Jedoch für den Empfänger der Aura.
auratgteventfunc: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, ist dieses Feld ein Equivalent zu den auraeventfunc Spalten. Jedoch für den Empfänger der Aura.
PASSIVE SKILL EINSTELLUNGEN
Ob ein Skill wirklich passiv ist oder nicht, hängt davon ab ob die boolsche Variable Passive auf wahr (true) gesetzt wurde. Ansonsten ist die Wirkung dieser Spalten von den benutzten serverseitigen Funktionen abhängig. Sie können die Funktion von sekundären passiven Boni des Skills gewähren, als eine Erweiterung einer Aura / Fluchs / Buff oder einer beschworenen Kreatur zugefügt werden.
passivestate: The state used by the game to assign the stats and events related things granted by this passive to the unit. Dieses Feld ist ein ID Pointer auf States.txt. Achtung: Hier gelten die gleichen Aussagen über Mechanismen und Probleme wie bei aurastate.
passiveitype: Dieses Feld wird im Zusammenhang mit den pasiven Boni, der Waffenbeherrschungen (weapon masteries) verwendet. Es enthält einen ID pointer auf ItemTypes.txt. Dort wird dem Spiel mitgeteilt, welche Gegenstände (item types) vom korrespondierenden passiven Skillwirkung (passive stat)profitieren. Achtung: Dies arbeitet nicht mit Einträge (stats), die ursprunglich nicht Teil der Waffenbeherrschungen (weapon masteries) sind. Vergiss es! Die einzigsten Einträge (stats) mit denen es arbeitet ist passive_weaponblock und passive_mastery__, usw... Waffenbeherrschungen (weapon masteries) sind nicht in den Zeilen von Skills.txt fest codiert, dies ist nur ein sehr hartnäckiges Gerücht.
passivestat1-5: Diese Felder teilen dem Spiel mit welche Wirkungen diesem passiven Skill zugeordnet sind. Sie enthalten einen ID pointer auf ItemStatCost.txt.
passivecalc1-5: Diese Felder können entweder Berechnungen oder feste Werte beinhalten. Die Werte, die der zugeordneten Wirkung (state) hinzugefügt oder abgezogen wird. Die in dieses Felder einzutragende Werte sind begrenzt auf Werte zwischen -2147483647 und +2147483647. Höhere oder niedrigere Werte führen zu einem überrollen der Zahl.
passivevent: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, steuert dieses Feld welches Ereignis mit diesem passiven Skill reagiert.
passiveeventfunc: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, steuert dieses Feld welche Funktion auf das zugehörige Ereignis durchgeführt wird.
BESCHWÖRUNGSEINSTELLUNGEN
Spezielle Eigenschaften werden Beschorenen Kreaturen entweder über MonEquip.txt, MonProp.txt angehängt oder über die aurastat bzw. passivestat Spalten definiert.
summon: Dieses Feld bestimmt welches Monster durch diesen Skill beschworen wird. Es ist ein ID Pointer auf MonStats.txt.
pettype: Dieses Feld bestimmt in welcher Gruppe sich die beschorenen Kreatur befindet. Es steuert welches Bildchen am Bildschirm erscheint und ob die beschorene Kreatur zusammen mit anderen beschorenen Kreaturen existieren kann oder nicht. (genauso wie nur ein Golem existieren kann anstatt ein Golem von jedem Typ) Der Eintrag ist verknüpft(warping) mit dem Verhalten der Beschworenen und vielem mehr. Das ist ein ID Pointer auf PetTypes.txt.
petmax: Dieses Feld kann entweder Berechnungen oder einen festen Wert beinhalten welcher die Anzahl der beschorenen Kreaturen dieser Gruppe bestimmt, die der Spieler gleichzeitig beherrschen kann. Kein Eintrag hier bedeutet, das keine Grenzen gesetzt sind.
summode: Die Animation, die bei der beschwörung einer Kreatur abgespielt wird. Laßt euch sagen, wenn ihr einen Zombie beschwören wollt der aus dem Boden aufsteigt, dann solltet ihr hier S1 einsetzen .(Das ist die spezielle Animation eines Zombies). Normalerweise wird man NU, den neutralen Modus hier wählen, weil die meisten Kreaturen/Monster keine passende Animation besitzen.
sumskill1-5: Diese Felder steuern die Fähigkeiten, welche der beschworenen Kreatur zugeordnet werden. Das heißt nicht, dass diese Skills von der beschworenen Kreatur angewendet werden. Sie werden hauptsächtlich dafür genutzt um einen Synergiebonus der beschworenen Kreatur zu übergeben. (Beispielsweise zusätzlichen Schaden für Hydra). Immer wenn ein Beschworener aktiv ist, dann benutze beliebige dieser Skills abhängig von der künstlichen Intelligenz (AI) die benutzt wird. Man kann es vergessen die Necrobeschworene (Necropet) AI zu verwenden. Diese AI ist vollständig fest programmiert und benutzt diese Skills nicht, außer der Programmcode wird modifiziert. Die beste nutzbare AI ist die Schattenmeister(Shadowmaster) AI. Man sollte beachten, dass auf die von den Beschworenen verwendeten Skills auch in MonStats.txt verwiesen werden muß. Mehr zum geeigneten Verwendendes Schattenmeisterverhaltens (Shadowmaster AI) kann hier gefunden werden: (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?t=21049)
sumsk1-5calc: Dieses Feld kann entweder Berechnungen oder einen festen Wert beinhalten, welcher dem Spil mitteilt welcher Skilllevel (sLvl) dem entsprechenden Skill des Beschworenen zugeordnet ist.
sumumod: Dieses Fie Fuktion dieses Feldes ist außerordentlich(pretty neat). Es steuert welche Bossmodifikationen (boss modifiers) den beschworenen Kreaturen gewährt werden. Das bedeutet, das man seinen Beschworenen Eigenschaften wie Blitzverzaubert (Lightning Enchanted) oder Auraverzaubert(Aura Enchanted) = zufällige Aura zuordnen kann. Diese Spalte enthält ID-Nummern aus MonUMod.txt. Es existiert ein nur kleinerer Seiteneffekt. Weil die beschworenen Kreaturen keinen speziellen Boss haben (special boss seed) ist der Name, der beim darüberfahren mit der Maus mit der Funktion Wegschicken (unsummon) angezeigt wird "Mind Maw the Slasher".
sumoverlay: Dieses Feld steuert welche grafische Einblendung (overlay) gezeigt wird wenn die Kreatur beschworen wird (Dieses Overlay ist der beschworenen Kreatur zugeordnet und nicht dem Caster). Sie enthält einen ID-Pointer auf Overlays.txt.
TON UND BILDEINBLENDUNGSEINSTELLUNGEN
Ziemlich einleuchtend, das alle Spalten, die mit 'sound' enden, ID pointer auf
Sounds.txt beinhalten. Solche, die auf 'overlay' enden beinhalten ID pointer auf Overlays.txt.
stsuccessonly: Diese logische Variable steuert ob die zugeordneten sounds und Animnationen (overlays) weiter abgespielt werden wenn ein Angriff den Caster beim zaubern unterbricht. (Korrektur durch brappy)
Mittlerweile habe ich ein paar Problemchen. Schaut einfach mal nach. Aktueller Stand 7 von 23 Seiten.
The Phrozen Keep Forum Index -> Knowledge Base -> File Guides -> File Guides (1.10-1.11x)
Skills.txt
Description by Nefarius
Author Nefarius
Date Fri May 11, 2007 4:37 pm
Type File Guide
Category File Guides (1.10-1.11x)
Views 2875
Skills.txt
SKILLS.TXT FILE GUIDE
by Nepharius
Skills.txt, war für eine lange Zeit (1.00 bis 1.09) eine ziemlich kleine Datei, in der man nur ein paar wenige Dinge ändern konnte (das war hauptsächlich begrenzt auf die Animationen, die benutzt wurden, die Parameter, die einen Skill durchlaufen und der Schaden, den ein Skill verursacht). Der Rest war komplett fest programmiert (hardcoded). Wie die Skills selbst arbeiten ist immer noch fest programmiert (die Skillfunktionen), aber alle anderen Aspekte ihres Verhaltens konn jetzt über skills.txt gesteuert werden, inklusive welche Skills welche Funktionen verwenden. Die Datei ist riesig, bei weitem die größte und komplizierteste in Diablo II. Sie enthält 256 Spalten. Das ist das Maximum, das MS Excel unterstützt. Der Zweck dieses Fileguides ist nicht einen 100% akurate Beschreibung jeder Spalte anzubieten, weil dies einfach unmöglich ist. (wie einige der Spalten benutzt werden, hängt zu allermeist von der Skillfunktion ab, die auf die entsprechende Spalte zugreift!). Ich will hier auch keine Formeln behandeln, Xeno schrieb bereits einen eindrucksvollen Guide über Formeln, die vom D2-Parser akzeptiert werden. Es gibt keinen Grund, dies hier zu wiederholen.
ALLGEMEINE SKILL EINSTELLUNGEN
skill: Der ID-Zeiger (ID pointer) wird als Bezug auf diesen Skill innerhalb von CharStats.txt, Missiles.txt and Monstats.txt und SkillDesc.txt verwendet. Er wird aber auch innerhalb von Skills.txt selbst verwendet. Dieser ID pointer kann auch innerhalb von AutoMagic, Gems, MagicPrefix, MagicSuffix, MonProp, QualityItems, Runes, SetItems, Sets und UniqueItems.txt verwendet werden. Wie dem auch sei, der Parser, der für diese Dateien verwendet wird ist verbugt und Skillnamen mit einer Leerstelle (space) scheitern öfter, als dass sie ordentlich funktionieren (Bloß weil Blizzard damit umgehen kann, glaube ja nicht, dass wir das können!). Ich empfehle dringend, die aktuellen ID-Nummern (ID numbers) statt der ID-Zeiger (ID pointer) in diesen Dateien zu verwenden. ACHTUNG: Benutze niemals den gleichen ID pointer doppelt oder mehrfach. Alle Skills mit gleichen Zeiger, außer dem ersten, werden ignoriert!
Id: Die aktuelle ID-Nummer (ID number) des Skills. Das ist die Stelle auf die der ID-Zeiger (ID pointer) tatsächlich zeigt. Es muss eine einzigartige Zahl sein. Das Spiel unterstützt 32767 Skills, aber wir werden sie im Zusammenhang mit Items nicht nutzen können bis wir ItemStatCost.txt modifiziert haben. Codierte Stats (encoded stats) ( xx% Chance eine Level xx Wirkung/Skill auf Aktion auszuführen (chance to cast level xxx yyy on zzz), und Ladungen (charges)) können nur IDs bis 1023 speichern und verwenden, ganz gleich was man tut. ACHTUNG: Einige IDs beziehen sich auf Programmcode (solche wie Auras, die von Bossen verwendet werden). Man sollte sich dies vor Augen führen, bevor man beginnt innerhalb der Datei Skills bunt durcheinander zu würfeln. Zumindest bis man weiß, was man da macht.
charclass: Beschreibt welcher Characterklasse dieser Skill zugeordnent ist. Dieser Eintrag steuert hauptsächlich aus welcher Grafikbibliothek (DC6 icon library) die Skillbilder(skill icons) ausgewählt werden und welche Boni dieser Skill bewirken wird. (+zu allen Amazonenfertigkeiten etc). ACHTUNG: Alle Charactere müssen die gleiche Anzahl von Skills haben, weil sonst nur die Klasse
mit der höchsten Anzahl Skills ein Spiel betreten kann. (Weil das Spiel darauf vorbereitet ist Dateien für jede Klasse mit xxx Skills zu speichern, werden Spielstände für Klassen mit weniger als xxx Skills als "defekt" behandelt. Um dieses Problem zu lösen, muß man nur eine Anzahl von Dummy-Skills für diese Klasse definieren. (Diese Dummy-Skills werden nicht im Skillbaum erscheinen oder auf eine sonstige Weise zu benutzen sein). Wenn man diese Spalte frei läßt, dann bedeutet das, dass dieser Skill nicht irgend einer/ nicht einer bestimmten Klasse zugeordnet ist. (< --- Anm. Keine Ahnung --- >)skilldesc: Der ID pointer von SkillDesc.txt. Diese Datei steuert alle Benutzerschnittstelle bezogene Aspekte des Skills, wie z.B. welches Skillicon verwendet wird, der Text, der in der Skillbeschreibung angezeigt wird und ob bzw. wie Schaden und Angriffswert (damage and attack rating) im Characterbildschirm angezeigt wird. ACHTUNG: Benutze niemals zwei identische Einträge für den gleichen Skill, wenn sie der gleichen Characterklasse zugeordnet sind, außer natürlich, man mag Programmabstürze.
SERVER-SEITIGE SKILL FUNKTIONEN
Diese Funktionen waren ursprünglich auf im Programmcode fest codierte Tabellen während Patch 1.00-1.09 bezogen. Seit 1.10 sind diese Funktionen tabellenbezogen codiert (softcoded) und können nun durch editieren der Skills in skills.txt modifiziert werden. Hier sitzt das Herz und die Seele des Skills. Nahezu alles, dass einen Skill von einem anderen Skill unterscheidet, werden durch die jeweils verwendeten Funktionen gesteuert. Diese Funktionen sind aber nicht alleine darauf beschränkt: Immer dann wenn ein Skill verschiedene Zustände verwendet, immer dann wenn die Berechnungsspalten (calc columns) verwendet werden, immer dann wenn sich der Programmcode auf eine Variable (parameter) direkt bezieht, immer dann wenn ein Geschoss abgefeuert wird und wie ein Geschoss abgefeuert wird, genau dann sind sie im Einsatz und noch für denkbar vieles mehr.
srvstfunc: Server Start Funktion. Diese entscheidet welche Serverseitige Funktion ausgeführt wird, sobald man irgendwo rechtsklickt oder shift+linksklickt wenn der Skill einer Taste zugeordnet ist.
srvdofunc: Server Ende Funktion. Diese entscheidet welche Serverseitige Funktion ausgeführt wird, sobald die Server Start Funktion ihre Ausführung beendet hat. Es ist möglich, dass sie entweder andauernd aufgerufen wird solange der Mausknopf gedrückt ist, oder dass sie nur periodisch aufgerufen wird (Für Skills wie Paladin Auras und Klingenschild (blade shield)).
prgstack: Enthält eine logische Variable (Boolean), wird von Aufladeskills verwendet. Wahr (true) bedeutet, dass die einzelnen Ladungen auf dem Stapel gespeichert werden (Feuerfäuste (Fists of Fire),Donnerklauen (Claws of Thunder) und Eisklingen (Blades of Ice)). Falsch (false) bedeutet, dass jede neue Ladung die vorangegangene ersetzt. (Phönixschlag (Phoenix Strike etc)). Und tatsächlich, alle drei Ladungen von Phönixschlag (Phoenix Strike) können gleichzeitig vorkommen, sobald man prgstack auf true setzt.
srvprgfunc1: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 1 (durch die Benutzung eines finishing moves)ausgelöst wird.
srvprgfunc2: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 2 (durch die Benutzung eines finishing moves)ausgelöst wird.
srvprgfunc3: Serverseitige Funktion, welche ausgeführt wird, wenn Ladung 3 (durch die Benutzung eines finishing moves)ausgelöst wird.
prgcalc1: Berechnung, die von serverseitigen Funktionen bei Ladung 1 (charge number 1) verwendet wird (diese Spalte wird auch von Schocknetz (Shock Web) und Klingenwut (Blade Fury) verwendet. Die serverseitigen Skillfunktionen dieser Skills greifen darauf zu!).
prgcalc2: Berechnung, die von serverseitigen Funktionen bei Ladung 2 verwendet wird.
prgcalc3: Berechnung, die von serverseitigen Funktionen bei Ladung 3 verwendet wird.
prgdam: Bezieht sich auf die sehr fest programmierten progressiven Eigenschaften (stats).
1 wird im Zusammenhang mit PROGRESSIVE_DAMAGE verwendet,
2 wird im Zusammenhang mit PROGRESSIVE_STEAL verwendet,
3 wird im Zusammenhang mit dem nicht benutzten PROGRESSIVE_OTHER Eigenschaften(stat) und
4 wird im Zusammenhang mit PROGRESSIVE_ Eigenschaften (stats) verwendet.
Ich habe hier weiter recherchiert, aber das Hinzufügen von weiteren progressiven Eigenschaften (stats) erweitert die Liste der angesprungenen Funktionen! (Anm. Vermutlich im Programmcode)
(Original: I have yet to do research on this, but adding new progressive stats would involde (vermutlich Schreibfehler, involve?) expanding the list of functions linked to by this field! Übersetzungideen? Der Satz ist so ziemlich "geraten" geraten...)
SERVER-SEITIGE GESCHOSS EINSTELLUNGEN
Diese Spalten steuern die unterschiedlichsten Aspekte auf Serverseite wenn Geschosse durch einen Skill abgefeuert werden. Das ist vollkommen unabhängig davon was der Spieler (der client) auf seinem Bildschirm sieht. Diese clientseitigen Geschosseinstellungen müssen dazu passen. Das vermeidet sonderbares Verhalten des Programms und nebenbei dämliche Fragen von Benutzer (stupid questions
). Man muss sie jedoch nicht passend machen. Das hat keinen nachteiligen Effekt im Programmablauf. Nur: Das Geschoss wird auf dem Bildschirm nicht erscheinen oder zumindest nicht auf die Weise wie es sollte. srvmissile: Das primäre Geschoss, das abgefeuert wird wenn die Server Start Funktion (srvstfunc) ausgeführt wird. Dieser Abschuß ist unabhängig davon ob überhaupt eine serverseitige Startfunktion mit einbezogen ist. (Das gilt auch wenn überhaupt keine Funktion ausgeführt wird: siehe Feuerball (fireball) and Feuerblitz (firebolt) als Beispiel).
decquant: Enthält eine logische Variable (Boolean), die steuert wann ein Skill den Stapel (siehe prgstack) oder Munition verringert und zwar jedes mal wenn die Start Funktion ausgeführt wird. (Sie ist für Streuen (strafe) deaktiviert (false), wird sie aktiviert (true), dann wird Streuen (strafe) genauso viele Pfeile verbrauchen wie man abfeuert).
lob: Enthält auch eine logische Variable (Boolean). Wenn sie auf wahr (true) gesetzt wird fliegt das Geschoss einen Lob (steil abgeschossen wie eine Granate mit hoher Flugbahn). Ein lobbendes Geschoss verschwindet (bzw. kollidiert mit dem Boden) an dem Ort wo man mit der Maus hingeklickt hat. Achtung: Ein lobbendes Geschoss (lobbed) scheint nur in einem Bogen zu fliegen. Deshalb wird das Geschoss allem Monster etc. weiterhin Schaden zufügen, als hätte es nicht die hohe Flugbahn. Damit sich ein passendes Verhalten des Geschosses mit hoher Flugbahn einstellt, muss das Geschoss geeignet modifiziert werden. (siehe den Missiles.txt Fileguide).
srvmissilea: Erstes sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
srvmissileb: Zweites sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
srvmissilec: Drittes sekundäres serverseitiges Geschoss (wie und ob auf sie zugegriffen wird hängt von dem Skill verwendeten serverseitigen Funktionen ab).
SERVER GESTEUERTE EINBLENDUNGEN (OVERLAYS)
srvoverlay: Einblendungen bzw. Überlagerungen werden normalerweise von clientseitigen Programmcode gesteuert. Davon abgesehen: Aktionsabhängige (mission-critical) Einblendungen werden von serverseitigen Programmcode behandelt. Das betrifft normalerweise die Einblendungen bei anvisierten Objekten. Sie werden im Verlauf der serverseitige Ende Funktion ausgeführt. Aktionsabhängige Einblendungen sind die, die von Nahkampfangriffe verwendet werden. Verschiedene Monster, die buffs??/Flüche (buffs??/curses) anwenden verwenden sie und Himmelsfaust (Fist of the Heavens) verwendet sie auch. (das sich abwärts bewegende Geschoss ist tatsächlich eine (Anm. serverseitige) Einblendung). Der Eintrag ist ein ID pointer von Overlays.txt. Wann und ob er genutzt wird ist von der benutzten serverseitigen Ende Funktion abhängig.
AURA / FLUCH / ANHALTENDE WIRKUNGEN BEZOGENE EINSTELLUNGEN
Diese Spalten müssen nicht notwendigerweise nur durch Auren/Flüche/Buff?? verwendet werden. Das Spiel verwendet diese Felder zum Beispiel auch für Skills, die irgend eine Art von Suchradius besitzen oder auch ein "AoE". (< -- "AoE". -- > Was ist das?)
aurafilter: Dies ist ein bitweiser Filter, welcher steuert was für eine Art von Einheit durch diesen Skill beeinflußt wird. Eine Diskussion darüber wie der aurafilter arbeitet kann hier gefunden werden (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?t=18470) Nicht alle Aurafilterwerte arbeiten in geeigneter Weise mit allen Skills zusammen. Das ist weitgehend abhängig davon, wie die serverseitigen Skillfunktionen nach potenziellen Zielen suchen! Aurafilter wird von den meisten zielsuchenden Skills verwendet.
Code:
0001000010110000011 - inner sight, taunt
0001100010110000011 - slow missiles
0001010010110000011 - lightning fury, conviction, tornado
0001000011110000011 - static field
0000000000000000011 - amplify damage, weaken, iron maiden, life tap, decrepify, lower resist [work on bosses]
0000000000000000010 - dim vision, terror, confuse, attract, grim ward [don't work on bosses]
0010010000000000011 - might, prayer, resist fire, thorns, defiance, resist cold, blessed aim, cleansing, resist lightning, concentration, vigor, fanaticism, salvation, defense curse, blood mana
0001010011110000011 - holy fire, holy shock, hurricane
1001010001010000011 - holy freeze
0001110011110000110 - sanctuary
0001010010110000111 - fist of the heavens
0000001000100000010 - redemption
1100000000000000000 - battle cry
0001110000000000011 - cloak of shadows
0001000001110000011 - mind blast, blade shield
0001000011100001011 - blades of ice
0010000000100000011 - spirit of barbs aura, heart of wolverine aura, oak sage aura
aurastate: Beschreibt die Auswirkungen (state), die dem Caster (Benutzer) der Aura / buff / Fluchs zugeordnet werden. Im Falle von Verzaubern (enchant) gelten die Auswirkungen für die Einheit, auf die der Skill angewendet wurde. Hier wird ein ID pointer von States.txt eingetragen. Achtung: Man sollte nicht versuchen, die gleiche Wirkung (state) aus state.txt auf mehr als einen Skill zu ermöglichen, wenn diese Skills beim gleichen Character oder Monster zum Einsatz kommen. Das Spiel benutzt eine Indextabelle um die verwendete Wirkung (state) zu bestimmen (und auf diese Weise bestimmen welche Wirkungen (stat) wechseln) die gerade bei einem Char/Monster (unit) aktiv ist. Eine Wirkung die gerade bei einem Char/Monster (unit) aktiv ist, kann nicht noch einmal hinzugefügt werden während die erste (gleiche) Wirkung noch aktiv ist. Folglicherweise werden zwei Skills mit der gleichen Wirkung niemals gleichzeitig zur Geltung kommen. Das heißt nicht, dass sie immer ein "übereinanderstapeln" (stacking) verhindern. Es heißt nur, dass man dann größte Erfahrung mit Störungen bzw. überhöhten Wirkungen (glitches) sammeln kann.
auratargetstate: Das sind die Auswirkungen, die dem Empfänger der Aura / buff / Fluches zugeordnet sind. Hier wird ein ID pointer von States.txt eingetragen. Achtung: Hier gelten die gleichen Aussagen über Mechanismen und Probleme wie bei aurastate.
auralencalc: Dieses Feld kann entweder eine Berechnung oder einen festen Wert (static value) beinhalten. Es steuert wie lange (in frames) die Effekte der Aura / buff / Fluchs anhalten. Echte Auren benutzen dieses Feld nicht, weil sie periodisch erneuert werden.
aurarangecalc: Dieses Feld kann entweder eine Berechnung oder einen festen Wert (static value) beinhalten. Er steuert die Größe des Gebietes (in subtiles) in welchen die Aura / buff / Fluch auf Char/Monster (unit) wirkt. Einige andere Skilltypen verwenden dieses Feld auch (wie Blitzendes Unheil (Lightning Fury)) um den Such- oder Schadensradius von den entsprechenden Skills ausgelösten Geschossen zu bestimmen.
aurastat1-6: Die Wirkung dieser Aura / buff / Fluches kann sich ändern. Es enthält ID pointer aus ItemStatCost.txt.
aurastatcalc1-6: Die Werte, die der fraglichen Wirkung (state) hinzugefügt oder abgezogen wird. Die in dieses Felder einzutragende Werte sind begrenzt auf Werte zwischen -2147483647 und +2147483647. Höhere oder niedrigere Werte führen zu einem überrollen der Zahl.
auraevent1-3: Diese Felder bestimmen welche Ereignisse (events) mit Aura / Fluch / buff reagieren sollten, wenn dieses Ereignis beim Caster (Benutzer) dieses Skills eintritt. Hier wird ein ID pointer aus Events.txt eingetragen.
auraeventfunc1-3: Diese Felder bestimmen die Funktionen, die ausgeführt werden, wenn das entsprechende Ereignis auftritt (wie oben beschrieben, Sie beziehen sich nur auf den caster des Skills alleine). Eine Liste der Ereignisfuktionen kann hier gefunden werden: (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?p=259558#259558)Achtung: Die große Mehrheit dieser Funktionen werden nicht richtig bearbeitet, wenn sie durch einen Skill aufgerufen wurden.
auratgtevent: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, ist dieses Feld ein Equivalent zu den auraevent Spalten. Jedoch für den Empfänger der Aura.
auratgteventfunc: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, ist dieses Feld ein Equivalent zu den auraeventfunc Spalten. Jedoch für den Empfänger der Aura.
PASSIVE SKILL EINSTELLUNGEN
Ob ein Skill wirklich passiv ist oder nicht, hängt davon ab ob die boolsche Variable Passive auf wahr (true) gesetzt wurde. Ansonsten ist die Wirkung dieser Spalten von den benutzten serverseitigen Funktionen abhängig. Sie können die Funktion von sekundären passiven Boni des Skills gewähren, als eine Erweiterung einer Aura / Fluchs / Buff oder einer beschworenen Kreatur zugefügt werden.
passivestate: The state used by the game to assign the stats and events related things granted by this passive to the unit. Dieses Feld ist ein ID Pointer auf States.txt. Achtung: Hier gelten die gleichen Aussagen über Mechanismen und Probleme wie bei aurastate.
passiveitype: Dieses Feld wird im Zusammenhang mit den pasiven Boni, der Waffenbeherrschungen (weapon masteries) verwendet. Es enthält einen ID pointer auf ItemTypes.txt. Dort wird dem Spiel mitgeteilt, welche Gegenstände (item types) vom korrespondierenden passiven Skillwirkung (passive stat)profitieren. Achtung: Dies arbeitet nicht mit Einträge (stats), die ursprunglich nicht Teil der Waffenbeherrschungen (weapon masteries) sind. Vergiss es! Die einzigsten Einträge (stats) mit denen es arbeitet ist passive_weaponblock und passive_mastery__, usw... Waffenbeherrschungen (weapon masteries) sind nicht in den Zeilen von Skills.txt fest codiert, dies ist nur ein sehr hartnäckiges Gerücht.
passivestat1-5: Diese Felder teilen dem Spiel mit welche Wirkungen diesem passiven Skill zugeordnet sind. Sie enthalten einen ID pointer auf ItemStatCost.txt.
passivecalc1-5: Diese Felder können entweder Berechnungen oder feste Werte beinhalten. Die Werte, die der zugeordneten Wirkung (state) hinzugefügt oder abgezogen wird. Die in dieses Felder einzutragende Werte sind begrenzt auf Werte zwischen -2147483647 und +2147483647. Höhere oder niedrigere Werte führen zu einem überrollen der Zahl.
passivevent: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, steuert dieses Feld welches Ereignis mit diesem passiven Skill reagiert.
passiveeventfunc: Nicht benutzt von vanilla. Achtung: Ich konnte sie in meinen Tests nicht richtig zum laufen bekommen, aber soweit ich sagen kann, steuert dieses Feld welche Funktion auf das zugehörige Ereignis durchgeführt wird.
BESCHWÖRUNGSEINSTELLUNGEN
Spezielle Eigenschaften werden Beschorenen Kreaturen entweder über MonEquip.txt, MonProp.txt angehängt oder über die aurastat bzw. passivestat Spalten definiert.
summon: Dieses Feld bestimmt welches Monster durch diesen Skill beschworen wird. Es ist ein ID Pointer auf MonStats.txt.
pettype: Dieses Feld bestimmt in welcher Gruppe sich die beschorenen Kreatur befindet. Es steuert welches Bildchen am Bildschirm erscheint und ob die beschorene Kreatur zusammen mit anderen beschorenen Kreaturen existieren kann oder nicht. (genauso wie nur ein Golem existieren kann anstatt ein Golem von jedem Typ) Der Eintrag ist verknüpft(warping) mit dem Verhalten der Beschworenen und vielem mehr. Das ist ein ID Pointer auf PetTypes.txt.
petmax: Dieses Feld kann entweder Berechnungen oder einen festen Wert beinhalten welcher die Anzahl der beschorenen Kreaturen dieser Gruppe bestimmt, die der Spieler gleichzeitig beherrschen kann. Kein Eintrag hier bedeutet, das keine Grenzen gesetzt sind.
summode: Die Animation, die bei der beschwörung einer Kreatur abgespielt wird. Laßt euch sagen, wenn ihr einen Zombie beschwören wollt der aus dem Boden aufsteigt, dann solltet ihr hier S1 einsetzen .(Das ist die spezielle Animation eines Zombies). Normalerweise wird man NU, den neutralen Modus hier wählen, weil die meisten Kreaturen/Monster keine passende Animation besitzen.
sumskill1-5: Diese Felder steuern die Fähigkeiten, welche der beschworenen Kreatur zugeordnet werden. Das heißt nicht, dass diese Skills von der beschworenen Kreatur angewendet werden. Sie werden hauptsächtlich dafür genutzt um einen Synergiebonus der beschworenen Kreatur zu übergeben. (Beispielsweise zusätzlichen Schaden für Hydra). Immer wenn ein Beschworener aktiv ist, dann benutze beliebige dieser Skills abhängig von der künstlichen Intelligenz (AI) die benutzt wird. Man kann es vergessen die Necrobeschworene (Necropet) AI zu verwenden. Diese AI ist vollständig fest programmiert und benutzt diese Skills nicht, außer der Programmcode wird modifiziert. Die beste nutzbare AI ist die Schattenmeister(Shadowmaster) AI. Man sollte beachten, dass auf die von den Beschworenen verwendeten Skills auch in MonStats.txt verwiesen werden muß. Mehr zum geeigneten Verwendendes Schattenmeisterverhaltens (Shadowmaster AI) kann hier gefunden werden: (http://phrozenkeep.planetdiablo.gamespy.com/forum/viewtopic.php?t=21049)
sumsk1-5calc: Dieses Feld kann entweder Berechnungen oder einen festen Wert beinhalten, welcher dem Spil mitteilt welcher Skilllevel (sLvl) dem entsprechenden Skill des Beschworenen zugeordnet ist.
sumumod: Dieses Fie Fuktion dieses Feldes ist außerordentlich(pretty neat). Es steuert welche Bossmodifikationen (boss modifiers) den beschworenen Kreaturen gewährt werden. Das bedeutet, das man seinen Beschworenen Eigenschaften wie Blitzverzaubert (Lightning Enchanted) oder Auraverzaubert(Aura Enchanted) = zufällige Aura zuordnen kann. Diese Spalte enthält ID-Nummern aus MonUMod.txt. Es existiert ein nur kleinerer Seiteneffekt. Weil die beschworenen Kreaturen keinen speziellen Boss haben (special boss seed) ist der Name, der beim darüberfahren mit der Maus mit der Funktion Wegschicken (unsummon) angezeigt wird "Mind Maw the Slasher".
sumoverlay: Dieses Feld steuert welche grafische Einblendung (overlay) gezeigt wird wenn die Kreatur beschworen wird (Dieses Overlay ist der beschworenen Kreatur zugeordnet und nicht dem Caster). Sie enthält einen ID-Pointer auf Overlays.txt.
TON UND BILDEINBLENDUNGSEINSTELLUNGEN
Ziemlich einleuchtend, das alle Spalten, die mit 'sound' enden, ID pointer auf
Sounds.txt beinhalten. Solche, die auf 'overlay' enden beinhalten ID pointer auf Overlays.txt.
stsuccessonly: Diese logische Variable steuert ob die zugeordneten sounds und Animnationen (overlays) weiter abgespielt werden wenn ein Angriff den Caster beim zaubern unterbricht. (Korrektur durch brappy)