The Unwritten Rules of .mes Files

Last time I went over dialog, I detailed how to edit index entries.

Upon review, I’ve found that there are some additional “unwritten rules” on how .mes dialog files in A Wonderful Life are structured.

Index Entries Aligned as Hex “Words”

After looking at the index values in any given .mes file, I began to notice a pattern.

Note every dialog index ends in a 0, 4, 8, or c

Every single message starts at a position ending in a multiple of 4 in hex (i.e. 0, 4, 8, c).

At first I thought this was a weird coincidence. However, upon review I’ve determined that this is not on accident.

Different Types of Hex Grouping

There are different ways of grouping hex values.

Bytes: A pair of hex values
Words: 2 bytes
Double Words: 4 bytes

Message #1 in badog.mes, illustrated as bytes, words, and double words

What this means for MES files

It seems that .mes files are read in memory as “double words”. This means that a new message needs to start at a double word position (i.e. a hex position multiple of 4).

Every message needs at least one “00” end-of-message {EOM} byte to tell the system that it’s the end of that message. Additional EOM bytes are then added to pad out the message so that the next message in the file is pushed to start at the next double-word position.

This explains why some messages seem to have only 1 {EOM} byte, while some messages can have up to 4 {EOM} bytes.

File Endings

The Double Words pattern above still didn’t explain why the last messages in each dialog file seemed to have a random number of EOM bytes.

After reviewing the file endings, I found that the last byte position in any .mes file was at the “f” position on an odd line.
i.e. 1f, 3f, 5f, 7f, 9f, bf, df, ff

The last bytes for carter.mes, badog.mes, and bahn.mes are all at an odd _f position

This means that each file is padded out with EOM bytes until they reach a valid ending position.

Why bother with any of this?

These groupings are both seemingly due to how the game stores dialog in memory.

If dialog files weren’t configured properly with these rules, there is potential for dialog to overflow into other areas of memory (or other areas of memory to overflow into allocated “dialog space”) and wreak havoc.

This was evidenced during a recent Twitch stream, in which the dialog for Muffy (muumuu.mes) was improperly configured.

In this case, the game would experience numerous glitches following any interaction with Muffy (e.g. random words/phrases showing up where they shouldn’t, freezing, crashes, etc.).

To prevent any of these types of issues, dialog files must follow the above positioning rules.

Discovery of SceneInit function potentially related to reading data from CLZ files

After opening the game’s main executable (Start.dol) in BrawlBox’s memory editor, I was able to find references to a SceneInit.cpp (C++) file.

Based on the name, I assume that SceneInit would be called whenever loading (i.e. initializing) the game (scenery). This function would then need to load certain files (models, textures, etc) from a mainchapter file (e.g. mainchapter2.arc.clz).

In addition, there are also references to common.arc.clz and preload.arc.clz, possibly related to a FileUpdater.cpp function.

I’m going to post some of my findings on ZenHax. Hopefully someone there will be able to provide some additional insight.