Tongari Boushi to Oshare na Mahou Tsukai โ€” Archive

Home Field GuideFile FormatsUI containers (text audit)

UI container .lzs files โ€” text audit

DS game only ใจใ‚“ใŒใ‚Šใƒœใ‚ฆใ‚ทใจใŠใ—ใ‚ƒใ‚Œใชใพใปใ†ใคใ‹ใ„ The field guide documents the DS game's internals.

Step-305 confirmed the 16 player-facing UI container files plus the inputstr/ directory carry zero translatable text. They are TAD/RESC graphics archives (sprites, palettes, cells) and internal kana-keyboard data. The text these UIs display comes from the message-system msg*.ofs files, not from the containers themselves.

Sixteen .lzs files under data/ sit behind the most text-heavy UI surfaces in the game: the bulletin board, mail editor, item-name entry, locker, mail-order list, sale ranking, music-select screen, shop info / profile / "make profile", default-costume picker, catch-display, and the lower-screen letter and BBS chrome. The inputstr/ directory adds five more files behind the on-screen Japanese kana keyboard. The step-305 audit (2026-05-20) put every one of them through a strict UTF-16-LE kana-required scan to settle whether any of them carry translatable text the toolchain had missed.

Headline result

19 of the 21 audited files are pure binary game-data containers (TAD/RESC graphics, palette, screen, and cell archives) with zero player-visible Japanese text. The two text-bearing files are inside inputstr/ and are part of the on-screen keyboard / profanity-filter machinery โ€” translating them would break Japanese name input, not enable English UI. No new translation work is opened by this audit.

Per-file findings

PathRaw โ†’ decompMagicText?Format
data/inputbbs.lzs2,048 โ†’ 4,688RESOโ€”TAD graphics (NCGR + NCLR + NCSR + NCER + palette)
data/inputmail.lzs3,584 โ†’ 6,912RESOโ€”TAD graphics
data/entryitmname.lzs6,144 โ†’ 32,384RESOโ€”TAD graphics
data/goodslist.lzs7,168 โ†’ 31,376RESCโ€”RESC v3.11 graphics
data/locker.lzs33,280 โ†’ 105,728RESOโ€”TAD graphics
data/mailorder.lzs16,384 โ†’ 68,400RESCโ€”RESC v3.11 graphics
data/saleranking.lzs7,680 โ†’ 20,752RESOโ€”TAD graphics
data/selectmusic.lzs17,408 โ†’ 40,400RESOโ€”TAD graphics
data/shopinfo.lzs5,120 โ†’ 11,808RESOโ€”TAD graphics
data/shopprofile.lzs9,216 โ†’ 43,488RESOโ€”TAD graphics
data/makeprofile.lzs8,704 โ†’ 28,144RESOโ€”TAD graphics
data/defcos.lzs1,536 โ†’ 6,576RESOโ€”TAD graphics
data/global.lzs68,096 โ†’ 166,176RESOโ€”TAD graphics
data/letter.lzs3,584 โ†’ 7,936RESOโ€”TAD graphics
data/catchdisp.lzs4,096 โ†’ 20,208RESOโ€”TAD graphics
data/bbs.lzs9,728 โ†’ 34,832RESOโ€”TAD graphics
data/inputstr/inp_bg.lzs1,024 โ†’ 4,336RESOโ€”TAD graphics (keyboard background)
data/inputstr/inp_objcell.lzs2,048 โ†’ 5,904RESOโ€”TAD cell container (keyboard sprite cells)
data/inputstr/inp_objchara.lzs9,216 โ†’ 35,696RESOโ€”TAD graphics (keyboard character sprites)
data/inputstr/strdata.lzs1,536 โ†’ 1,616RESOinternalKana keyboard button-glyph table
data/inputstr/taboo.bin20,586 โ†’ n/aB0D0โ€ฆinternalUTF-16-LE banned-word list (~486 entries)

What the RESO / RESC payloads actually contain

The RESO / RESC header is followed by an entry table laid out at a 0x10-byte stride: a 4-character lowercase ASCII fourCC tag (rgcn, rlcn, rcsn, recn, rcan, etc.), a 4-byte size, and a 4-byte offset, with the trailing 4 bytes zeroed. Each entry points at a standard Nitro graphics block โ€” RGCN/NCGR (character graphics), RLCN/NCLR (palette), RCSN/NCSR (screen / tile map), RECN/NCER (cell / OAM), and so on. None of these blocks carry human-readable text; they encode tile pixels, 5-bit color entries, tile indices, and OAM attribute words. The JP text those screens display comes from the entries rows of the relevant msg*.ofs files, not from the .lzs containers themselves.

The two text-bearing files (do not translate)

inputstr/strdata.lzs โ€” kana keyboard glyph table

Decompressed payload is a 1,616-byte RESO container whose embedded data block holds the kana characters that label the buttons of the on-screen Japanese input keyboard. Examples: hiragana "a-column" labels (ใ‚ใ‹ใ•ใŸใชใฏใพใ‚„ใ‚‰ใ‚) at offset 0x82, katakana "a-column" (ใ‚ขใ‚ซใ‚ตใ‚ฟใƒŠใƒใƒžใƒคใƒฉใƒฏ) at 0x2C2, and so on. These are the glyphs the player taps to enter Japanese names. They are not translation targets โ€” they are input alphabet data. Romanizing or rewriting them would break the input UI for any player who wants to enter a Japanese name. The English keyboard glyphs (A-Z) are part of the same file and are already present alongside the kana.

inputstr/taboo.bin โ€” banned-word filter

20,586-byte UTF-16-LE NUL-terminated string list. ~486 distinct kana/kanji-only entries (slang, ethnic slurs, drug terms, adult terms, yakuza idioms). This is the input-screen profanity filter: the list is consulted when the player types a custom name; if a match is found, the engine refuses the name. It is internal data, never rendered on screen, and translating it would weaken the filter (the JP entries catch JP slurs that an EN-only list would not). Leave it alone. Note the file is not LZ-wrapped โ€” .bin, not .lzs โ€” so it bypasses the lzs.py decode path.

False positives the strict scan filtered out

A permissive first-pass scan reported thousands of "JP" hits across the binary files. Every one investigated turned out to be a misread of binary structure bytes as UTF-16-LE โ€” repeating ็ˆ€ๆงใฎ runs are the byte sequence 00 72 67 63 6E 30 ?? 00 00 ?? ?? 00 00 (trailing NUL of a size field + ASCII fourCC rgcn + leading byte of the next field) read as UTF-16-LE; ๆ•ƒๆฑฌๆนๆตฉใฅๅ€ is the ASCII literal CellAnime0\0TXEUโ€ฆ read as UTF-16-LE; two pure-CJK hits in global.lzs sit inside 4bpp NCGR pixel blobs. The strict scan (require โ‰ฅ1 kana per run, 5+ kana for high-confidence) returns zero hits on the 19 binary files and only the legitimate keyboard / banned-word data on the two inputstr/ files.

Source