Der Maker nimmt beim importieren ja auch Änderungen vor (transparente Farbe setzen, Farbtiefe auf 8 Bit ändern, ggf in XYZ konvertieren, ...), daher verändert sich die Dateigröße.
Im Map Tree sind eigentlich nur folgende Informationen gespeichert:
---RPG Maker LcfMapTree---
Introduction
Rather than try to lex the database next (which doesn’t look fun at all), I’ll attempt to lex the map tree next. See the RPG_Maker_Map_Grammar_Guide for an explanation of RPG Integers, the syntax used in this guide, and other particulars.
Properties not in the lmt file
The following properties do not appear in the lmt file, but in the respective lmu files for each map:
Chipset
Width
Height
ScrollType
UseParallelBkgrd?
BkgrdFileName
HorizPan?
VertPan?
HorizAuto?
HorizAutoSpd
VertAuto?
VertAutoSpd
A word about the map tree file
The map tree file is a lot simpler than the individual maps’ files. However, there’s a few things in it that remain a myster to me. As always, if you can decipher the “unknown” imperials (even if they turn out to be size hints) send me an email:
Sorlok_Reaves@yahoo.com
The Map Tree File Format
<lmt_map_tree_file> ::= <file_type> <tree_node>+ <map_end>
<file_type> ::= <str_len> <character>+
The end of the file
I haven’t fully figured out what all that junk at the end of the map tree file means. For lexing purposes, you’ll basically just detect a map number followed immediately by a null terminal, and then a handful of digits (which varies depending on the map, but seems to increase in length as the number of nodes increases.) For now, we will lex it as a node, and cut off program execution at that point.
The Tree Nodes
Every map has at least one tree node; the root node. This is the folder icon at the top of the RPG Maker’s map tree viewer. Following this, a number of other nodes are listed in ascending order. These are either maps or areas, and they form a tree structure through the use of a “parent” reference.
As an aside, we will lex all tree properties and interpret them in the lexer itself. I realize now the foolishness of ignoring size hints in the lmu parser. We will also lex all numbers as rpg_bytes, and convert to integers in the lexer. This avoids potential lexing bugs that plague the lmu lexer.
<tree_node> ::= <tree_node_id> <end_of_file: 00>? <tree_property>+ <area_layout> <null: 00>
<tree_property> ::= <long_property> | <background_music> | <monster_encounters>
<long_property> ::= <imperial> <size_hint> <byte>+
<imperials> ::= (01,Map Name) , (02,Parent) , (03,Tree Depth) , (04,Type of Node) , (05,Unknown Property 1) , (06,Unknown Area Property) , (07,Has Children) , (0B,BGM Options) , (15,Battle Background) , (16,Battle Background File) , (1F,Teleport Option) , (20,Escape Option) , (21,Save Option) , (2C,Encounter Steps) (Italics denote optional properties)
<background_music> ::= <imp:0C> <size_hint> <sub_imp:01> <str_len> <character>* <null:00>
<monster_encounters> ::= <imp:29> <size_hint> (<none:00> | <monsters>)
<monsters> ::= <
<area_layout> ::= <imp:33><size_hint><x_min_byte>4 <y_min_byte>4 <x_max+1_byte>4 <y_max+1_byte>4
A note on byte order
The size of the area_layout is fixed at 0x10. Each value (x_min, y_max+1, etc.) is made of four bytes, arranged in reverse order.
(0C,BGM File Name) ,
0A – Length Hint
“LcfMapTree”
09 — Number of maps, areas, and root nodes(1)
End:
09 00 -- 01 03 08 02 04 05 06 07 08 01 01 23 00
11 00 02 01 03 0A 0C 0D 0E 0F 10 04 05 06 07 08 09 0B 10 01 01 10 02 01 0A 03 01 0B 00
05 und 06 sind unbekannt, aber ich glaube noch immer nicht, dass das etwas mit dem Map Tree Data Break zu tun haben soll.
Ich erkläre mir das eher so:
Kopiert man eine Ressource, anstatt sie zu importieren, und verwendet sie dann im Maker (z.B. bei Show Picture), dann kann, wenn die Datei dem Maker aus irgendeinem Grund nicht in den Kram passt (hätte man sie importiert, hätte er sie zurechtgebogen), etwas passieren (z.B. irgendwelche ungültigen Werte im RAM oder dergleichen), was quasi zufälligerweise dazu führt, dass der Maker beim Speichern das Map Trees Mist baut.
Ich würde das ja gerne genauer analysieren, aber dafür bräuchte ich eine defekte rpg_rt.lmt.
mfG Cherry