Ergebnis 1 bis 5 von 5

Thema: Frage zu RM2k-Fileformaten (konkret: Maptree/Encounters)

  1. #1

    Frage zu RM2k-Fileformaten (konkret: Maptree/Encounters)

    Moin,

    ich bau gerade an einem Parser für die Fileformate des RM2k rum, hab aber jetzt gerade ein Problem im Maptree: Die Dokumentation, die ich verwende, erklärt, dass innerhalb eines Map-Blocks nach 0x29 der encounter data block kommt, erklärt aber diesen Block offensichtlich falsch, und da ich gerade keinen RM2k da hab, kann ich da auch nicht wirklich selbst mit rumspielen und rausfinden, wie der aufgebaut ist.

    … hat jemand da Ahnung, wie das Format von dem Block ist?

  2. #2
    http://forum.rpg2000.4players.de/php...=91564&start=0 << in der Datei hab ich mehrere Erklärungen drin, vllt nützt dir da eine davon mehr.

  3. #3
    Das sieht recht cool aus, hilft mir aber leider nicht weiter – das braucht ’ne Windows-only Software zum lesen, und ich bin auf Mac OS. ^^"
    Könntest du mir zumindest sagen, was da über den entsprechenden Block drinsteht?

  4. #4
    Das Grundformat ist ja so:

    Zitat Zitat von Cherry
    Alle Datendateien sind gleich aufgebaut.

    Zuerst kommt ein Identifizierungsstring: ein Byte Länge und dann die Stringdaten.

    Bei den Maps ist das 0x0A,'LcfMapUnit', beim Map Tree 0x0A,'LcfMapTree', bei der Datenbank 0x0B,'LcfDataBase' und bei den Saves 0x0B,'LcfSaveData'. "Lcf" steht übrigens für "Lucifer", den Nick eines der Programmierer des RM2k.

    Danach folgen schon die Daten: verpackt in einzelne "Datenfelder" (Blöcke). Diese bestehen aus einer ID, einer Längenangabe und dann dem Inhalt (alles BERs).

    Beispiel (Anfang einer Map):

    0A 4C 63 66 4D 61 70 55 6E 69 74 0B 01 00 47 84 58 FB 13 28 00 08 00 00 ...

    Zuerst der Identifizierungsstring (0A 4C ... 74), dann der erste Block: ID 0x0B (Looping), Länge 1, Inhalt "00" (kein Loop). Dann der zweite Block: ID 0x47 (Lower Layer) Länge 600 (84 58 -> 4*128 + 88), Inhalt "FB 13 28 ...".

    Das geht dann immer so weiter, wobei ein Block auch Unterblöcke enthalten kann. Die enden dann mit immer mit einem Null-Byte.
    In diesem Fall kommt noch die Array-Regel dazu: Bei einem Array wird zuerst die Anzahl der Elemente angegeben, danach bei jedem Element zuerst immer seine ID.

    Hier ein konkretes Beispiel:

    29 15 04 01 01 01 0B 00 02 01 01 0A 00 03 01 01 28 00 04 01 01 50 00

    29 ... Block-Typ. Dies ist ein Encounterdaten-Block.
    15 ... Länge des Inhalts.
    Rest ... Inhalt.

    Der Inhalt ist nun ein Array:

    04 01 01 01 0B 00 02 01 01 0A 00 03 01 01 28 00 04 01 01 50 00

    04 ... Anzahl Elemente im Array

    Dann die einzelnen Elemente, hier exemplarisch das erste Element:

    01 01 01 0B 00

    01 ... Element-Nummer. Es ist das erste Element im Array.
    Rest ... Inhalt

    Der Inhalt ist nun der "Inhalt"-Teil eines ganz normalen Blocks mit genau einem Unterblock:

    01 01 0B 00

    Rest ... Der (einzige) Unterblock.
    00 ... Ende des Unterblockenthaltenden Blocks.

    Und dieser einzige Unterblock jetzt:

    01 01 0B

    01 ... Block-Typ: Dieser Block gibt die Monstergruppen-ID an.
    01 ... Länge des Inhalts.
    0B ... Inhalt. Und zwar die Monstergruppen-ID!

    Hoffentlich hab ich das jetzt so erklärt, dass es auch irgendwer versteht

    mfG Cherry

  5. #5
    Alles klar, die Info, wie man Arrays parst (bzw. dass das eins ist) hat mir gefehlt. Danke. 

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •