*.def Files

Hier geht es rund um das Verändern der nichtextra aufgeführten Mul-Files wie Art, Tiledata, Anim, Sound etc.

Moderator: Mods - Mulbearbeitung

Antworten
Nachricht
Autor
nazghul

*.def Files

#1 Beitrag von nazghul » 19 Feb 2007 00:10

Irgendwer - ich glaube, mennowar - fragte danach. Dies habe ich auf einem verstaubten alten Backup-Band gefunden:
Die drei ??? und die *.def files

Zusammen mit der ersten großen Karten-Erweiterung (LBR), in der Map und Statics für die neue Karte in eigenen Dateien untergebracht wurden, führte OSI auch eine zusätzliche anim.mul ein - die anim2.mul (zusammen mit der dazugehörigen Index-Datei). In dieser Datei waren Animationen nicht nur für neue NPC, sondern auch für neue Ausrüstungsgegenstände vorhanden. Und damit stand OSI vor einem Problem: Da diese neuen Animationen nämlich nicht an die neue Map gebunden waren, musste der Client irgendwie herausfinden, aus welcher Datei er denn nun die Grafikdaten für die Animation einen bestimmten NPC oder Gegenstands nehmen sollte. Und das, ohne zu den bisherigen Datenstrukturen etwa der tiledata.mul inkompatibel zu werden.

Nach wie vor - obwohl es derzeit sogar schon die anim5.mul gibt - ist etwa zu einem Gegenstand nur eine Animationsnummer verzeichnet, die einen Zeiger in die anim.mul darstellt. Allerdings greift der Client noch auf einige Textdateien zu, die sozusagen ein Mapping zwischen anim.mul und animX.mul, oder auch innerhalb der anim.mul vornehmen.

Wenn der Server den Auftrag bekommt, die Animation mit der Nummer X darzustellen, öffnet er zunächst die Datei body.def und sucht in deren erster Spalte nach der Nummer X. Findet er sie, gibt die Zahl in der zweiten Spalte an, wo in der Anim.mul die TATSÄCHLICH darzustellende Animation steht. Die dritte Spalte gibt ggf. noch einen Farbton (Hue) an, in dem die Animation eingefärbt werden soll. Unbeschadet davon wird ein evtl. Gump aus der gumpart.mul, Slot X+50.000 (resp. X+60.000) geholt. Damit ist die body.def vor allem dafür geeignet, neue Items einzuführen, die zwar ein eigenes Gump, aber keine eigene Anim haben. Hat man z.B. das Gump einer tollen, aufwändig geschnittenen roten Robe, so kann man durch einen passenden Eintrag in der body.def dafür sorgen, dass die Animation der normalen Robe, nur rot eingefärbt, verwendet wird. Dies verbraucht zwar ein "Fach" in der anim.mul (genauer: in der anim.idx), weil ja evtl. dort hinterlegte Daten nun nicht mehr erreichbar sind, fügt aber keine eigenen Grafikdaten hinzu.

Nur wenn in der body.def _nichts_ gefunden wird, greift der Client hernach auf die Datei bodyconv.def zu. Ihre Funktion ist jener der body.def sehr ähnlich, nur dass hier nicht innerhalb der anim.mul, sondern zwischen anim.mul und anim*.mul verwiesen wird. Die Datei besteht aus 5 Spalten: Ganz links steht wieder der Wert "X", die Nummer der Animation, die der Client darstellen soll. In den folgenden Spalten steht entweder ein "-1", oder eine Nummer "Y", die in die entsprechende anim2.mul, anim3.mul, anim4.mul oder anim5.mul verweist. Ein Eintrag der Form
X -1 -1 Y -1
Bedeutet also: Wenn der Client den Auftrag zur Darstellung der Animation X bekommt, soll er stattdessen die Daten aus der anim4.mul, Eintrag Y, darstellen. Wieder befindet sich das ggf. dazugehörige Gump weiterhin unter X+50.000 resp. X+60.000 in der gumpart.mul. Und der entsprechende Slot in der anim.mul ist auch hier nicht mehr erreichbar.

Unabhängig von den vorherigen Redirections wird schließlich in der equipconv.def nachgesehen. Diese Datei erlaubt es, abhängig vom Körper des Charakters den von ihm getragenen Gegenständen andere Gumps und/oder Animationen zuzuweisen. Das ist z.B. sinnvoll (meint jedenfalls OSI) bei Gegenständen, die etwa an einem Elf anders aussehen sollen als an einem Menschen (Helme z.B.). Die Datei besteht aus fünf Spalten, die man so übersetzen könnte: "Wenn der Träger den Körper (Spalte 1) hat und das Item mit der AnimID (Spalte 2) trägt, dann soll stattdessen die Animation (Spalte 3 - bodyconv.def wird ggf. wieder ausgewertet) dargestellt werden; steht in (Spalte 4) etwas anderes als -1, soll auch das dort genannte Gump in der Paperdoll dargestellt werden; in jedem Fall wird die Animation in Farbe (Spalte 5) eingefärbt".

Wenn es nicht um Equipment, sondern NPC geht, gibt es noch zwei weitere Textdateien von Interesse.

Die eine ist die Mobtypes.txt (Anmerkung: Ja, die gilt auch für Equipment). In ihr wird angegeben, welche Art Animation sich in einem bestimmten anim.mul Slot befindet. Im Wesentlichen bedeutet "Human": "Hat eine Paperdoll und getragene Gegenstände mit Animation können dargestellt werden", während "Monster" eben nicht diese Möglichkeiten haben. "Sea-Monster" werden "halbversenkt" dargestellt, und "Equipment" beschreibt halt "tragbare Dinge". Die hinter dem Typ stehende Zahl beschreibt, für welche Art Bewegungen in der Animation Frames vorhanden nicht sind und ist abhängig vom Typ.

Wenn man nun eine Animation mit den body*.def "umgeleitet" hat, möchte man vielleicht auch, dass, wenn der NPC stirbt, er einen passenden Corpse hinterläßt. Das Bild des toten Wesens wird sonst nämlich immer noch aus der anim.mul genommen - mit dem Effekt, dass, wenn dort nichts hinterlegt ist, auch nichts dargestellt wird (resp. ein Default-Körper, das hängt vom Server ab). Diese Zuordnung übernimmt die Datei corpse.def. In ihr stehen wieder 3 Spalten: Die Animationsnummer, um die es geht, also "X", der Animations-Slot, aus dem der Corpse genommen werden soll (bodyconv.def wird ausgewertet), und ggf. der Farbton, in dem das Ganze eingefärbt werden soll.

Die weiteren *.def Dateien haben vergleichbare Aufgaben, nur für z.B. Sounds. Und einige von ihnen werden nur vom 3D-Client benutzt (z.B. stitchin.def)

Benutzeravatar
Barkie
Newbie
Beiträge: 1
Registriert: 29 Mai 2012 22:41

Re: *.def Files

#2 Beitrag von Barkie » 26 Jan 2013 21:52

Wie sieht es aus,

was würde passieren, wenn man einige Daten in diesen .def Files auskommentiert oder sogar löscht?

Wir haben aktuell das Problem, dass wir zwar viele neue Arts und Gumps eingepatcht haben,
aber die Animationen sich nicht ersetzen lassen (TDV-Patcher).

Beispiel: Helm aus Samurai Empire gegen Frisur getauscht, copy existing animation = ohne Funktion.
Könnte das an den .def Files liegen? Wenn ja, wenn ich die .def Files komplett leere, hätte dies
starke Nachteile? Oder wenn ich zB Einträge für Samurai Empire oder andere, spätere UO Versionen
ändere?

Vielen Dank vorab :)
Bild

Antworten