Crystals-DSA-Foren

Schade, wäre ja auch zu einfach gewesen
Der Index Wert hat jedenfalls direkte Auswirkungen auf den Kompass. Also welche Himmelsrichtungen möglich sind.

Zitat:Übrigens: Hat schon jemand herausgefunden, wo Sternenschweif die klassenspezifischen Ausrüstungs-Einschränkungen speichert?

Ich würde mal vermuten da wo die Klassen definiert sind, da bei den Items/Waffen keine Einschränkungen angegeben sind.

Ich habe mir mal die SCHOOL.DAT angeschaut. Die Daten dort beziehen sich, logischerweise, auf die magischen Schulen. Im Wiki habe ich dazu nichts gefunden, hoffe deshalb es ist noch nicht bekannt.

Pro Schule 33Byte. 9x33=297Byte
Byte 1 Anzahl der Modifizierten Zauber, max 7.
Byte 2 ID/Nummer des 1. Zaubers welcher modifiziert werden soll. Fängt bei 1 an, 0 bedeutet kein Zauber.
Byte 3 gehört wohl dazu, ist aber immer 0, müsste erst bei über 255 Zaubern zum Tragen kommen.
Byte 4 ID/Nummer des 2. Zauber.
Byte 5 gehört wohl dazu.
Das Wiederholt sich bis zum 7. Zauber also Byte 15.
Byte 16 und 17 sind immer 255 und schließen den ersten Teil ab.
Byte 18 und 19 beinhalten den Modifikator für den ersten Zauber. Dadurch könnte man sogar negative Werte einstellen.
Byte 20 und 21 ist der Modifikator für den 2. Zauber.
Das Wiederholt sich bis zum Modifikator für den 7. Zauber also Byte 31.
Byte 32 und 33 sind immer 0. (Eventuell für einen 8. Mod? )

EDIT1:
Die Schulen sind in der selben Reihenfolge hinterlegt wie im Menü. Genau wie die Zauber, von links nach rechts und oben nach unten wird gezählt.
Also die ersten 33 Byte sind Antimagie, die nächsten Beherschung, Dämonologie, Bewegung, Heilung, Hellsicht, Kampf, Verwandlung und Veränderung.


Weiter gehts mit SPBVALS.DAT
Dort sind die Startwerte der Zaubersprüche pro magischer Klasse hinterlegt.
86 Byte pro Klasse. Also 6x86Byte=516Byte
Reihenfolge der Klassen ist wie im Spiel. Hexer, Druide, Magier, Auelf, Firnelf und Waldelf.
Byte 1 ist immer 0. Danach gibt es ein Byte pro Zauber, also 85 Byte für die gleiche Anzahl an Zaubern.


SKBVALS.DAT
Die Startwerte der Skills sind hier enthalten.
Pro Klasse 52 Byte. Da die ersten 52 nur einen Dummy-Eintrag repräsentieren geht es um 13 Blöcke, also 13x52Byte=676Byte. Die Reihenfolge der Klassen und Skills entspricht denen aus dem Spiel, wobei die Fähigkeiten, genauso wie die Zauber, von links nach rechts und oben nach unten gezählt werden.


EDIT2:
TAVERN.DAT
Jeder Tavernen Block ist 7 Byte groß. 27x7Byte=189Byte.
Byte 1 und 2 ist der Modifikator der Kosten in Prozent (Essen und Trinken).
Byte 3 Werte zwischen 4 und 20. Höhere Werte bedeuten schlechtere Qualität. Preis und Qualität des Essens hängen zusätzlich davon ab. Bei einem Wert von 25 kostet das Essen nichts, bei noch höheren Werten wird der Preis sogar negativ. Die Bierkosten werden nicht modifiziert.
Byte 4 immer 0.
Byte 5 bestimmt ob Wirt(0) oder Wirtin(1).
Byte 6 ist Unbekannt. Meistens 0, manchmal auch Werte von 20, 30, 40, 50.
Byte 7 immer 0.

INN.DAT
Sehr ähnlich den Tavernen.
Pro Herberge ist der Block 6 Byte groß. 28x6Byte=168Byte.
Byte 1 und Byte 2 Modifikator der Kosten in Prozent. (Basis Suite 100Heller, Essen 36Silber)
Byte 3 Herbergsqualität, kleinere Werte sind besser (0-20), wirkt sich auf Essenspreise aus.
Byte 4 immer 0.
Byte 5 Unbekannt, zwischen 10-50 und 100.
Byte 6 0=Wirt, 1=Wirtin.

SMITH.DAT
Pro Schmied 4 Byte. 13x4Byte=52Byte.
Byte 1 und Byte 2 Modifikator der Kosten in Prozent.
Byte 3 Schmiedequalität, kleinere Werte sind besser (1-20).
Byte 4 gibt ebenfalls wieder das Geschlecht an.

HEALER.DAT
Pro Heiler 5 Byte. 10x5Byte=50Byte.
Byte 1 und Byte 2 Modifikator der Kosten in Prozent.
Byte 3 Qualität, kleinere Werte sind besser (1-15).
Byte 4 gibt ebenfalls wieder das Geschlecht an.
Byte 5 Kann Versteinerung behandeln 0=Nein, 1=Ja.

SHOP.DAT
Pro Block 13 Byte, 25x13Byte=325Byte
Byte 1 und 2 Modifikator für Kaufpreise in Prozent.
Byte 3 und 4 Modifikator für Verkaufspreise in Prozent.
Byte 5 1=Waffen, 2=Kräuter, 3=Gemischt.
Byte 6 Sortiments ID.
Byte 7 und 8 ID eines zusätzlichen Items, bei 0 keins.
Byte 9 und 10 ID eines zusätzlichen Items, bei 0 keins.
Byte 11 und 12 ID eines zusätzlichen Items, bei 0 keins.
Byte 13, Geschlecht.

TEMPLE.DAT
Ein Byte pro Temple. 28x1Byte=28Byte.
Gibt jeweils an ob Priester(0) oder Priesterin(1).

Sorry wegen dem dreifach Post, aber ich befürchte es wird sonst zu unübersichtlich
Mir hat das Problem mit den Ruten keine Ruhe gelassen. Ganz verstanden habe ich es immer noch nicht, aber ich kann sagen, dass die ROUTE.DAT, POINT.DAT und SECTION.DAT zusammengehören.

Über ROUTE haben wir ja schon gesprochen, dort werden die Strecken (x,y Tuples) selber und ein Index definiert.

POINT.DAT
Pro Block 3 Byte, 220x3Byte=660Byte.
Byte 1 sieht wieder nach nem Index bzw. ID aus.
Byte 2 und 3 enthalten Flags für den Kompass. Warum ein Byte dafür nicht ausgereicht hat ist unklar. Teilweise stehen im 2. und 3. die selben Werte, manchmal sogar verschiedene. Aber überwiegend ist Byte 2 auf 0 gesetzt.

Werte für Himmelsrichtungen:
Diese sind beliebig kombinierbar, schalten aber nur den visuellen Teil des Kompasses frei.


SECTION.DAT
Pro Block 10Byte, 262x10Byte=2620Byte.
Byte 1 Unbekannt
Byte 2 Unbekannt
Byte 3 mögliche Richtung
Byte 4 nicht ganz klar, könnte Byte 3 ähneln (benutzt Werte zwischen 0 und 7).
Byte 5 Landschaft
Byte 6 Straße
Byte 7 nicht ganz klar, hat etwas mit der Geschwindikeit zu tun.
Byte 8 Unbekannt
Byte 9 Zufallsereignisse?
Byte 10 Sichtbar auf Weltkarte 1 oder nicht 0

Cool, Helios!

Tatsächlich haben wir da wohl etwas parallel gearbeitet. Ich habe mir in letzter Zeit auch die .DAT-Formate von Sternenschweif angeschaut. Zu jeder Datei gibt es (im Sinne "lebender Dokumentation") eine Ruby-Datei, die die Datei dekodiert, irgendwas nützliches anzeigt und mit Kommentaren versehen ist.
Neben einigen Dingen, die du schon erwähnt hast (skbvals/spbvals/schools) habe ich auch die gbspells/bskills entziffert - die enthalten Listen für die automatische Steigerung (wie sie im Anfängermodus oder auf Wunsch auch im Expertenmodus verwendet wird).
Die needs.dat codiert die Anforderungen an die einzelnen Charakterklassen bei der Generierung. Das etwas krude Format hat mich einige Zeit gekostet.
Ansonsten habe ich das Rätsel um die Karten-Formate zum großen Teil gelöst.
Demnach sind die .CYB- und die .DBG-Dateien "Geschwister", .CYB erfüllt für Städte den gleichen Zweck wie .DBG für Dungeons. Beide enthalten Daten zu den einzelnen Gebäudetypen. Witzigerweise ist die Information, was genau beim Betreten eines Gebäudes passiert, zum Teil in den .3D-Dateien versteckt: Wenn man z.B. tent2.3d durch tent1.3d ersetzt, ist in Kvirasim jeden Tag Markt! Ersetzt man tent2.3d durch temple.3d, steht dort ein Tempel. Beim Betreten ist es aber kein Marktstand, auch kein Tempel, sondern ein normales Bürgerhaus! Seltsam.
Die Bytes der ITEMS.DAT (und der dazugehörigen I_ENTRY.DAT) habe ich auch größtenteils enträtselt.

Ich habe mal ein Repo auf GitHub angelegt, damit ihr an meinen Ergebnissen teilhaben könnt.

Super Idee mit dem Repo

Zitat:Tatsächlich haben wir da wohl etwas parallel gearbeitet.

Nicht schlimm, vier Augen sehen mehr als zwei.
Aber das Wiki scheint wirklich etwas veraltet zu sein, was die Infos betrifft.

Das mit den Karten-Formaten ist super, vielleicht ist das Bürgerhaus eine Art Fallback weil irgendwas nicht ganz passt?

(21.09.2013, 21:32)Helios schrieb: [ -> ]Super Idee mit dem Repo

Zitat:Tatsächlich haben wir da wohl etwas parallel gearbeitet.

Nicht schlimm, vier Augen sehen mehr als zwei.
Aber das Wiki scheint wirklich etwas veraltet zu sein, was die Infos betrifft.

Das mit den Karten-Formaten ist super, vielleicht ist das Bürgerhaus eine Art Fallback weil irgendwas nicht ganz passt?

Wenn du Interesse hast, melde dich doch im wiki an und schick mir danach hier ne PN mit deinem Loginnamen. Ich schalte dich dann frei und du kannst die Informationen updaten.

@Hendrik
Beim nlt-itemviewer steht unk2, also Byte 9, für die Sortiments ID.
Die Händler haben auch eine Sortiments ID. Ein Item ist im Sortiment wenn die ID gleich oder größer ist. Also ein Händler mit der ID 0 würde alles anbieten.

Jedenfalls habe ich mir das Script etwas umgeschrieben, um die Datenflut auch speichern zu können und ich lasse mir zusätzlich noch die Item ID ausgeben. Diese findet Verwendung bei Türen(Schlüssel), Truhen(Schlüssel und Inhalt), Händlern (die drei extra Items).

Danke, Helios, ich habe die itemsdat.rb entsprechend ergänzt. Auch unk1 konnte ich entziffern, das ist einfach das höherwertige Byte vom Gewicht.
Fehlt nur noch unk3. Das kann Werte von 0-2 annehmen und ist vermutlich ein Enum oder Flag. Mit einem der anderen Felder hat es wohl eher nichts zu tun, ich habe keinen Zusammenhang erkennen können zwischen dem Wert von unk3 und Itemtyp, Gewicht, Preis, Häufigkeit, Magie oder Itemcode.
Auch einen Zusammenhang zu "Sperrigkeit/Größe" oder "wird einem von den Orks vor Lowangen abgenommen" habe ich nicht gefunden. Bruchfaktor, Anwendungen, etc. passt auch nicht.
Einen interessanten Hinweis bietet vielleicht die Lederkluft aus der Finsterkopp-Binge: Bei Stiefel (0xD300) und Weste (0xC500) ist unk3==0, bei den Hosen (0xD200) ist unk3==1. Was die Hose so besonders macht im Vergleich zu den anderen Kleidungsstücken, sehe ich gerade nicht.
Der Wert 02 ist nicht weniger rätselhaft, sämtliche Elixiere, Rezepte und Dokumente haben diesen Wert, aber auch einige Waffen und Rüstungen, sowie normale Rationen und Bier. Merkwürdig.

EDIT: Ach ja: i_entry ist auch noch unklar. Hat vielleicht irgendwas mit Tagebucheinträgen zu tun?
EDIT2: Ja, das dürfte es sein. Offenbar wird für alle Items, die dieses Byte gesetzt haben, der Fund im Tagebuch vermerkt.

Super, dann fehlt ja wirklich nur noch ein Byte bei den Items

Ich bin mit den Routen etwas weiter gekommen. Im Anhang ist ne Liste mit allen Daten. Leider sind noch ziemlich viele Felder unklar.
Bei ROUTES das erste Byte, in der Liste zerlege ich es in zwei Nibbel, da das zweite nur 0 oder 8 ist. Eventuell Flag ob die Ruten Punkte von oben oder von unten benutzt werden. Also quasi Start/End vertauscht wird.
Dann die beiden Bytes der SUBLOCS, wahrscheinlich IDs für die Zufallsbegegnungen. Zumindest wird auf der ersten Rute auch das erste Ereignis aus der SECTION.LTX benutzt.
Bei SECTIONS auch wieder zwei Byte. Das 8. hat Werte zwischen 0 bis 4. Das 9. Werte von 50, 2, 1, 0.

Zu der Liste noch ein paar Worte. Die Kompass Einträge zeigen welche Richtungen visuell möglich sind. Kompass 1 ist vom Startpunkt aus gesehen, Kompass 2 vom Endpunkt (also wenn man wieder zurück will). Wobei es nochmal eine Unterscheidung gibt, 1.1 und 2.1 sind per Routenplanung zu sehen, 1.2 und 2.2 nur wenn man sich an diesem Punkt befindet. Richtung 1 und 2 geben an welche Richtung begehbar ist, also es reicht nicht aus, wenn sie auf dem Kompass verfügbar sind, zumindest bei der Routenplanung.

So, die Itemliste von DSA2 ist entschlüsselt. Geholfen hat mir dabei auch der neue Bildentpacker, mit dem ich mir auch die passenden Icons zu den Gegenständen anschauen konnte, sowie die Ausgabe der Itemliste als HTML-Tabelle.

Zunächst einmal habe ich einige Fehler beim Raten gemacht. Die vermeintliche "Icon-ID" ist in Wirklichkeit eine Art "Fremdschlüssel" für Waffen und Rüstungen, der in eine andere (vermutlich hard-coded) Tabelle mit deren Werten zeigt. Das, was ich für die Item-ID hielt, ist wiederum die echte Icon-ID. Und die echte Item-ID? Die wird einfach durch die Position des Items in der ITEMS.DAT bestimmt.
Fehlt noch das unbekannte Byte unk3. Ich hatte ja oben schon erwähnt, dass teilweise sehr unterschiedliche Gegenstände dort den gleichen Wert haben und es nur Werte von 0-2 gibt. Nachdem ich die Daten einmal danach sortiert hatte, fiel es mir wie Schuppen von den Augen: Mit hoher Wahrscheinlichkeit handelt es sich dabei um das grammatische Geschlecht des Gegenstandes! Erschwerend wirkte dabei natürlich, dass ich die englische Liste vor mit hatte (mit den deutschen Genii ).

Damit sind die Item-Daten soweit klar, fehlt nur noch die Liste mit den Waffen- und Rüstungswerten, die vermutlich irgendwo in der SCHWEIF.EXE steckt.

Zitat:So, die Itemliste von DSA2 ist entschlüsselt.

Super

Zitat:Und die echte Item-ID? Die wird einfach durch die Position des Items in der ITEMS.DAT bestimmt.

Genau und diese werden eben auch in anderen Dats benutzt. Zum Beispiel funktionieren Türen oder Truhen damit. Also die Item-ID der Schlüssel findet sich dort wieder, genauso wie der Inhalt der Truhen auch damit bestimmt wird.

Ich hatte leider nicht soviel Zeit die letzten Tage, bin daher nicht viel weiter gekommen, sondern habe nur das Wiki um einige Einträge ergänzt. Damit werde ich heute fortfahren.

Bei den Ruten sind leider immer noch einige Dinge zu klären. Der Sinn der Sublocs.dat ist mir noch rätselhaft. Vorallem da Änderungen, wie es scheint, keine Konsequenzen haben. Ich war davon ausgegangen, dass diese eventuell was mit den Orten bzw. Kreuzungen zu tun haben.
Immerhin ist es mir gelungen, eine Rute mit neuen Richtungen und Kompass auszustatten. Ein Rätsel ist auch noch wie die Länge einer Sektion genau beschrieben wird. Direkt die erste Sektion beinhaltet ja mehrere Routen. Die Verbindung zwischen den Ruten wird aber definitiv von den Kompass Einträgen und den beiden Richtungs Bytes der SECTION.DAT bestimmt. Die 2. Richtung muss der 1. Richtung der nächsten Rute entsprechen, ansonsten hängt sich Schweif auf, weil quasi keine Verbindung hergestellt werden kann.

Die 4 Byte pro Route in ROUTES gehören zusammen.
Wenn man diese als uint32 interpretiert, durch 2 teilt und die Header größe von 1052 dazu addiert, kommt man auf die Position der Startkoordinate in ROUTES.
Die SUBLOCS scheint für die Wegweiser in den Städten zu sein. Da ich die Stadt nicht verlassen konnte, nachdem ich die Daten auf 0 gestellt hatte. Die Reihenfolge der Einträge ist mir aber noch unklar, ebenfalls ob auf diesem Weg auch Orte betreten werden.
Ansonsten fehlen nur noch 2-3 Byte der SECTION.

Section ist bis auf ein paar Unsicherheiten fertig, auch bei Points und TLK hab ich noch etwas korrigiert.
Die Chest, Door und D_Search Formate sind auch soweit ins Wiki gewandert.

Aber am meisten freut es mich, dass die Subloc.dat auch weitestgehend entschlüsselt ist
Sie definiert was passiert, wenn man ein Gebäude betritt (Typ des Gebäudes, Subeintrag(z.B. welcher NPC) und String Index). Details stehen im Wiki.

wow da wart ihr aber echt fleissig, ich hoffe ihr schreibt auch immer schön im wiki mit?

Ja das Wiki ist ziemlich aktuell. Kannst ja mal einen Blick riskieren

Gerade noch die Spoil.dat hinzugefügt. Scheint zusätzliche Container für Items zu definieren. Im Anhang ne Liste was enthalten ist (Salamanderstein und Asthenilschwert z.B.)

Sieht doch schon echt gut aus, ihr habt ja schon über die hälfte der .DAT Dateien erforscht.

Falls ihr mal Lust und Zeit habt, bei DSA1 konnte nie geklärt werden was in der BSSKILLS.DAT steht. (Es wurde vermutet, dass es irgendwie mit den Startwerten zusammenhängt, aber naja...)

tommy schrieb:Falls ihr mal Lust und Zeit habt, bei DSA1 konnte nie geklärt werden was in der BSSKILLS.DAT steht. (Es wurde vermutet, dass es irgendwie mit den Startwerten zusammenhängt, aber naja...)

(21.09.2013, 21:14)Hendrik schrieb: [ -> ]Neben einigen Dingen, die du schon erwähnt hast (skbvals/spbvals/schools) habe ich auch die gbspells/bskills entziffert - die enthalten Listen für die automatische Steigerung (wie sie im Anfängermodus oder auf Wunsch auch im Expertenmodus verwendet wird).

Die Startwerte für Skills sind in SKBVALS, die Zauber in SPBVALS. Für Magier ist noch SCHOOLS interessant, enthält die Werte für die Unterschiedlichen Zauberschulen.


Ich hab den Routen kram endlich verstanden. Genauer gesagt wie die Routen durch die Kreuzungen(Points.dat) verbunden werden. Es scheint auch erfreulich wenig Einschränkungen zu geben, also man darf ziemlich frei kombinieren. Wiki bekommt nachher noch ein Update.
Schade ist nur, dass ich nirgends eine Definition der Orte finde. Also wie Städte mit den Straßen verbunden werden ist mir unklar.

Die CYBER.DAT hat ziemlich sicher etwas mit der Beleuchtung zu tun. Auch wenn mir der Aufbau noch ein Rätsel ist.

(05.10.2013, 15:45)Helios schrieb: [ -> ]

tommy schrieb:Falls ihr mal Lust und Zeit habt, bei DSA1 konnte nie geklärt werden was in der BSSKILLS.DAT steht. (Es wurde vermutet, dass es irgendwie mit den Startwerten zusammenhängt, aber naja...)

(21.09.2013, 21:14)Hendrik schrieb: [ -> ]Neben einigen Dingen, die du schon erwähnt hast (skbvals/spbvals/schools) habe ich auch die gbspells/bskills entziffert - die enthalten Listen für die automatische Steigerung (wie sie im Anfängermodus oder auf Wunsch auch im Expertenmodus verwendet wird).

Die Startwerte für Skills sind in SKBVALS, die Zauber in SPBVALS. Für Magier ist noch SCHOOLS interessant, enthält die Werte für die Unterschiedlichen Zauberschulen.

ok danke, muss ich wohl überlesen haben, aber es hat sich ja auch echt viel getan

(05.10.2013, 15:45)Helios schrieb: [ -> ]Schade ist nur, dass ich nirgends eine Definition der Orte finde. Also wie Städte mit den Straßen verbunden werden ist mir unklar.

Es muss auch nicht alles in den Dateien sein. Aus DSA 1 kennen wir es ja nun schon zu genüge das vieles direkt in der .exe codiert ist. Und ich bezweifle das jetzt bei Sternenschweif wirklich schon alles ausgelagert wurde...

(05.10.2013, 15:45)Helios schrieb: [ -> ]Die Startwerte für Skills sind in SKBVALS, die Zauber in SPBVALS. Für Magier ist noch SCHOOLS interessant, enthält die Werte für die Unterschiedlichen Zauberschulen.

Wie kriegt man denn so etwas raus?

(05.10.2013, 19:26)tommy schrieb: [ -> ]Es muss auch nicht alles in den Dateien sein. Aus DSA 1 kennen wir es ja nun schon zu genüge das vieles direkt in der .exe codiert ist. Und ich bezweifle das jetzt bei Sternenschweif wirklich schon alles ausgelagert wurde...

Das stimmt wohl leider. Hatte trotzdem die schwache Hoffnung noch passende Daten zu finden. Ist halt irgendwie witzlos, neue Routen und Kreuzungen zu bauen, ohne neue Ziele.

(05.10.2013, 21:59)wiese.hano schrieb: [ -> ]Wie kriegt man denn so etwas raus?

Es gibt mehrere Möglichkeiten, konkret hatte ich eh schon eine Vermutung wegen den Dateinamen (sk=skills und sp=spells). Dann musste ich nur die Werte vergleichen, also Ingame beim Char und in den Dateien. Zum testen wurden ein paar Werte verändert und fertig.