Gw Temp

Menu

Tutorial - 'Fixing the Corrupt Map Tree Data Error' by Runiss Knight

An item about RPGMaker 2000 posted on

Blurb

Have that dreaded "Corrupt Map Tree" Error on your project? Well here is a wonderful technical tutorial on how to fix it

Body

A problem which I have had twice (Once each with my copies of RM2k and RM2k3) is an error which appears labelled "The map tree file is corrupted." The first time I got this message, I had no idea what to do to solve my problem and ended up losing a fairly substantially sized project in the process, beginning it again using RPG Maker 2003. Recently, the same problem occured (With the same project, no less), and I almost lost the whole thing... Again. However, through some trial-and-error, I discovered a method which will spare you most of the work of remaking a game should this happen to you.

To begin, let's look at the reasoning why this error exists in the first place: To be honest, I'm not 100% sure what the exact dynamics of it is, but I do know one thing: It happened to my projects both times as a result of my computer crashing due to memory overload while testing my game. Hence, it seems that it only happens on slower computers which have multiple things running in the background at the same time as you test your project. If this happens, the next time you try to open your project, you will get a simple error stating "The map tree file is corrupt.", and the project will immediately close.

Now that we understand the nature of this problem, we can go about fixing it. First of all, the best way to protect yourself from this problem is, quite simply, back up your map tree regularly. The map tree contains the 'backbone' of every map in your game: The order in which they are displayed in the project editor, the background music of the map, whether you can save, what monsters you might encounter, the map's name, et cetera. All this information is contained within a tiny file (Smaller than most MIDI files) called RPG_RT.lmt. For the record, RPG_RT.ldb stores all the database information, but I've never had a problem with this file, so I've never had an experience requiring a backup of this file... However, any time you remember to, I would suggest making a copy of RPG_RT.lmt. The more recent this backup is, the less work you have ahead of you.

Now, let's say that your map tree is corrupted. After the first few moments of random shock, it's time to fix the problem. The steps that follow will outline the process for completely remaking the .lmt. The steps for rebuilding off of a recent backup are not much different, but it can be done with little deviation from the following:

Step One: DO NOT TRY TO REBUILD THE MAP TREE IN THE PROJECT WHICH WAS CORRUPTED. This is a key thing to remember- Every map you try to remake in the original project will immediately overwrite the other maps in the project.

Step Two: Start a new project. It doesn't matter what it's called, I'm not trying to get you to give up and make a new game, but you MUST have a new project (With a fresh, uncorrupted .lmt file).

Step Three: If you have a backup of your original game's .lmt, no matter how old (Unless the map data has changed completely), close this new project, and replace its current RPG_RT.lmt file with your backup. Do this to the New project, not your original game (Though doing so won't hurt your project any worse than it already has been, it won't help you, either.) This will reduce the amount of work you have to do, probably quite substantially.

Step Four: Now, go into the corrupted project's folder. In here, there will be a varying number of Map####.lmu files. These represent everything else about your map data- The Events, the actual tiles, the tileset and panorama background being used, the map dimensions, et cetera. Fortunately, these things remain completely unharmed when the Map Tree is corrupted. There is one Map####.lmu file for each map (Or Area, I believe) your game contains, starting with Map0001.lmu. Why is this important? Well, for the most part, it isn't. However, what IS important is the highest numbered .lmu. Assuming you've spent a marginal amount of time on your game (Hence your want to recover it), this will probably be at least 20, and I personally have never seen a game with more than 1027 maps (Three The Hard Way takes the above prize). This number represents two things: First, aprroximately how heavily, in decibels, you should be sighing about the amount of work ahead of you. Second, obviously, the highest numbered .lmu indicates the number of maps contained within your game. This number is key to restoring the .lmt file.

Step Five: We now have a new project with only one map: The blank, 100x100 world map. We also have the number of maps in our original game. Prepare yourself for the easiest part of the real work. Create new maps until the identity of the map (MAP____) is a number equal to the number of maps in your original game. So, if your game had 100 maps, keep creating them until you get a map named MAP0100. Again, make SURE you do this in the New project, not your original game (If you do, every one of your maps will turn into 20x15 water maps) You can branch these out any way you want, but unless you have a fairly good idea of what your original map tree looked like, it's probably best to make every map a branch off of the "World Map" which the new project provides you with. Why? In the case of most games, your map branches off in such a way that the background music and most of the other settings which the .lmt affects will be set to "Same As Parent Map". Maps created as a branch of any other map will, by default, have everything set to "Same As Parent Map". However, if you create the map as a branch off of the project folder, the defaults are "Entrust to Event" for music, and "Allow" for Save, Teleport and Escape. Since, in most games, well over half of your maps will have these statistics based off of some parent map, it will save you a lot of pointless and tedious clicking if all of your maps are already set by default to "Same As Parent Map".

Step Six: So now our New Project has the same number of maps as the one with the corrupted file. At this point, our New Project is of no use to us. Copy the RPG_RT.lmt file from the new project and use it to overwrite the one in the corrupted project's folder. Do whatever you want with the New Project now, we won't be using it again.

Step Seven: Now is the part that is likely to make your ears bleed and you go criminally insane if you had a huge project. Granted, it is FAR less work than remaking your entire game, but it's still incredibly tedious. You should now be able to open your corrupted project, and all the map files will be there, layed out with all the events and the same map sizes as they originally were. HOWEVER, they will now have reverted to their original names- Map0001.lmu will be called MAP0001, Map0002.lmu will be MAP0002, and so on down the line. They will also be set up in the same tree that you put them in in the New Project. At this point, I find it easiest to do one of two things first: Either you can rename the maps, THEN put them back into their original tree configuration, or do it the other way around. Neither of these need to be the same as they were before the project was corrupted- There won't be any mismatches in events if the name of the map is different, since event commands use map file numbers, not their names. Reorganize these as you see fit. Since YOU made this game, the names and order of the maps should be fairly easy to remember. Your map tree won't look identical to the old one, but it will probably be very similar.

Step Eight: Now that the maps have been sorted into a recognizable form again, it's time to go through and fix everything else the map tree contains. Depending upon how much the settings for your maps vary, this can be moderately easy or EXTREMELY tedious. The things which must be reconfigured are:
-Any random monster battles. This is probably the hardest part of the whole thing to remember clearly, especially if you have a lot of maps with random battles.
-The default BGM for all maps (If you took my advice above, the maps should default with "Same As Parent Map", which will save you some time, as you won't have to change anything with the maps whose BGM is the same as a parent map). As with all things above, this may not necessarily be identical to what it was in the original project, but it should be very similar.
-The Battle Background settings. I've NEVER used this feature, however, so unless you have a thing for it... You will probably use it very little to never.
-Any restrictions on saving, teleport or escape. This is something you will DEFINITELY want to remember if you have a game in which you can only save at certain save points- Otherwise the game will by default put the ability to save on "Allow".

And you're done, or as done as you can be! Though your project may have changed slightly from the form it was in before it was corrupted, it will nonetheless be VERY similar after following these steps, and it's a lot less work than simply remaking your game entirely. However, I must stress that the best solution to this problem is to simply have as current of a backup RPG_RT.lmt file as possible at any given time. If this problem has never occured with you- Be glad. It's incredibly annoying. If it has happened, however, or you suspect it might (Old computers are especially at risk since they have less memory to work with), I hope this helps.