MES dialog format Confirmed

At a glance

Where

Inline in each scene's MAN (the scene's script-and-data bundle) as the actors' interaction scripts; in data\battle\efect.dat-style bundles; as type 4 in the asset-type dispatcher

Magic

Compact: first u32 0x00000404. Records: recurring 0x44 0x78 marker pairs, no fixed header

Size / stride

Glyph bytes are 1 byte; escapes 0xC0..0xCF are 2 bytes; a line is 0x1F <glyphs> 0x00

Parser

crates/mes (CLI mes); box packing legaia_mes::dialog_box; pickers legaia_mes::picker

Engine

engine_core::dialog + inline_dialogue; pager SM in engine-vm

Confidence

Confirmed - four interpreter functions statically linked in SCUS_942.54; pager and pickers traced in the dialog overlay and pinned on disc bytes

Used by

field/event VM, translation packs, NPC browser

Anatomy of a line

Container variants

Compact header

The Records variant has no fixed header: the parser finds record boundaries by scanning for 0x44 0x78 markers (at least four). Its per-record structure is Unknown.

Bytecode encoding

Most bytes are glyphs. Prefix bytes 0xC0..0xCF (plus two aliases) take a data byte and either name a wide glyph, insert spacing, or substitute a string from one of the game's name tables. All four interpreter functions share this classification; only the action per byte differs.

The substitution gate is the integer test (byte + 0x40) < 8, catching 0xC0..0xC7; 0xC0 and 0xC6 fall through to "no substitution" at 2-byte stride.

The four interpreters

• Stride walker - 16 instructions returning the glyph count to the next terminator; the pager uses it for line lengths.
• Width measurer - the same walk plus substitution dispatch, recursing into the substituted string.
• Substitution expander - normalises the two aliases, then inlines each substituted name byte by byte into a working buffer.
• Renderer - expands first, then emits glyphs into the text-actor buffer and forwards spacing ops to the cursor.

The dialog window pager

Above the byte-level interpreter sits the per-frame state machine that opens the speech box, scrolls lines in, waits for a button press, and turns the page. It lives in the dialog overlay: 26 states covering load / scroll / drain / wait / done, with per-line bytecode pointers in a 16-line buffer. Rust port: engine-core's dialog_window (rows, scroll, confirm) and dialog_pacing (the typewriter), driven by dialog::OwnedDialogPanel on the path both play hosts share.

Box packing

• The window shows 3 rows; three box-open states each pin the limit to 3. It is a window height, not a page length.
• Consecutive 0x1F lines are one page: a line right after a line's 0x00 means "same page, next row". A fourth line scrolls the window up a row with no button press; the page ends only at a control byte.
• A 0xC? escape whose argument falls in 0x00..0x1E (e.g. 0xC1 0x00) does not end the line; the advance loop consumes the argument as part of the token.
• Multi-page speech is several pages chained by 0x24. dialog_box::pack_page decodes a page; pack_box / pack_boxes cut the same lines into window-sized chunks. The Rim Elm sparring partner's narration packs into three full pages then a 2-row box opening a 4-option menu.

Row window and scrolling

The row table is a scrolling window. State 0x0B types the last row; a line after a full window scrolls it (0x0C, 15 px per row at 0x24 * dt sixteenths a call); at a page end, rows the previous page left above scroll away (0x0F) before the page waits (0x19). A 0x24 page turn keeps the rows and types the next page beneath them. A confirm press while a row types or holds latches 0x25 and completes the page (0x0D, then 0x0E for overflow). The text is clipped to the box's rows band; the frame does not scroll. A town01 PCSX-Redux trace pins every arm, and the engine reproduces it vsync for vsync.

Post-page control byte

When the page is full and the player confirms, the pager reads the next control byte (masked & 0x7F) and picks the follow-on state:

The pager decides the box, not the conversation: teardown clears rows and stops. Whether the dialogue session ends is decided by the actor dialog SM and the field VM.

No menu takes input on the press that opens it. The box slides from off screen to its place over a span of 24 frame-step units - twelve pager calls at the field's 30 fps, 10 px a call for the inn's top-right box - and the option hand appears on the call where it lands, with input read from the call after. A capture of an inn's stay offer measures 26 vsyncs from the press to a usable menu. Tetsu's 4-option list in Rim Elm rises the same way from below the screen, y 240 to 148 at 8, 8, 7 px a call, with the same 26 vsyncs to input.

Choice menus (pickers)

Four open bytes - 0x27, 0x28, 0x29 and 0x2A - open a menu. Relative to the open byte at index O:

[ .. 0x1F prompt segment .. 0x00 ]   the box text shown above the menu
O                                     open byte (0x27 / 0x28 / 0x29 / 0x2A)
O+1 .. O+N*2                          N jump entries, 2 bytes each (i16 LE)
O+N*2+1                               continuation byte (0x24/0x25/0x48/0x4C 0xFF)
                                      OR the first label's 0x1F (immediate labels)
N * [ 0x1F label segment 0x00 ]       the on-screen option labels

• Each jump entry is a signed 16-bit relative jump applied on confirm: new_pc = (O + 1 + index*2) + entry[index], relative to that option's own entry.
• Labels are ordinary 0x1F segments after the continuation byte, drawn under the prompt at a 15-px row pitch.
• Two continuation forms exist: a dispatch byte before the labels (the izumi book menu) or the first label's 0x1F directly (Rim Elm's spar menu). The parser accepts both.
• 0x2A is a real 2-option picker whose cursor clamps instead of wrapping. Every inn's Yes / No offer is one (inn); a decoder that stops at 0x29 finds no inn menus.

Engine: OwnedDialogPanel::from_inline_dialog attaches the picker, confirm_menu applies the jump. The faithful path, inline_dialogue, drives the whole interaction script through the real field VM (flag tests, scene changes) and pauses only at each 0x1F segment - default in play-window, --simple-dialogue opts out.

How we know

Field dialogue has no dedicated opcode: it is the actor's inline interaction-script text, triggered by the touch / button-press interaction rather than an opcode (op 0x3E with op0 < 100 is the scripted-battle install). Op 0x3F is the scene change, not a dialog op.

CLI

mes info       <PATH>             # detect variant + report header
mes disasm     <PATH>             # walk the bytecode, print decoded ops
mes json       <PATH>             # emit machine-readable JSON
mes events     <PATH> [--index N] # walk the interpreter for one message
mes stats-all  <PATH>             # event-type histogram across every message

Source of record: docs/formats/mes.md.

See also