Spell table Confirmed

At a glance

Where

SCUS_942.54, RAM DAT_800754C8; the name pointers are read through the shifted base DAT_800754D0 (= stats base + 8)

Size

190 records (ids 0x00..=0xBD), 12 bytes each. Ends exactly where the description-pointer table 0x80075DB0 begins

In the port

legaia_game_tables::spell_names (SPELL_COUNT = 190); CLI asset spell-names <SCUS> [--json]; engine mirror engine-battle::retail_magic

Confidence

Confirmed - readers traced in the battle and menu overlays; the curated magic chart joins byte-exact on MP

Used by

Battle-action SM (cast + banner), field menu (descriptions), spell-cost slider, Magic viewer

Record layout

Record id sits at base + id × 12. Every record has the same shape:

The stats reader uses base DAT_800754C8 and reads +0..+4; the name reader uses DAT_800754D0, 8 bytes on, over the same rows.

Id ranges

Player Seru-magic block (0x81..=0x8B)

MP and target are byte-exact from the executable; element comes from the curated game-data chart, which matches on every MP value.

The nine enemy-side spells share +0 = 0x32, +1 = 0x00: the table cannot tell Gimard from Nova, which is the first sign that damage lives elsewhere. The two ally-side spells break the pattern (0x83 Vera is 0x00 / 0x03, 0x89 Orb is 0x01 / 0x04).

Target shape (+2)

Two bits, read relative to the caster: 0x40 = the caster's opponents (clear = its own side), 0x20 = every target on that side (clear = single). Both target pickers test exactly these: the monster AI branches on byte & 0x60 and the player picker on 0x40 then 0x20.

Bit 0x02 is a separate flag, field-castable: the field Magic list greys every spell without it. Read as the side bit it happens to agree on the four player values, and misreads the rest - it would aim Cort's Mystic Circle at Cort himself. Decoder SpellEntry::target_shape.

Cast classes (+0)

The class byte chooses which band of the battle-action state machine runs the cast:

Because the sub-index is static table data, the identity of every capture-class module is readable from the executable alone (spell_names::capture_class_records). The 32 modules (PROT 935..966) are shared: a multi-spell module dispatches per spell id at its head.

The byte has two readers, and they agree. The pager streams the module in; the battle image's cast-tick dispatcher FUN_801F2160 re-reads the acting actor's queued id, indexes this table, takes +1, bounds it with sltiu …, 0x20 and jumps through a 32-slot table - the same PROT 935 + sub entry, ticked once per frame while the cast runs. Outside the capture class nothing dispatches on the byte, because no other class reaches that routine.

How an enemy's cast lands in the same id space

An enemy is named exactly like a party caster. Two selection mechanisms both end in the same byte on the live actor, and the banner reads the row that byte names:

1. Record arrayThe AI picker reads a global spell id from the monster record's three-slot magic-attack array.
2. Special-cast switchThe picker's tail runs a hardcoded switch on the monster's formation id - about 30 boss and species cases gated on HP fraction, MP, round counter, RNG cadence and a not-charmed check.
3. QueueThe chosen id is written to the actor's action byte.
4. BannerThe action SM reads this table at that id - the same row a party cast would use.

The monster archive's own local action ids (0x0C..=0x1F) only gate action cost - they are not this table's id space. Two spells, Curse 0x40 and Curse All 0x53, are sourced by neither mechanism and are casterless in retail.

Descriptions and names

The pause menu's spell info window reads the +4 byte and indexes a flat pointer array at 0x80075DB0; index 0 means no description. Player-block strings are a title line, a line break, then an effect line. Parser SpellEntry::desc.

Each name string is followed by NUL bytes up to the next word boundary - that padding is the whole edit budget for a rename, and it is word alignment, not a fixed slot (a 13-byte name has three spare bytes, a 15-byte name one). Names nest - a text search for one finds the longer name that contains it - so the only safe way to rewrite one is through its record's pointer (spell_names::name_field).

Reading past the extent

Both neighbouring tables start on exact multiples of the 12-byte stride, so an over-read lands on whole words:

Whenever the arts index is 1 mod 3, the arts name pointer and a phantom spell record's name pointer are the same four bytes (spell 0xD7 = arts record 1, Burning Flare). A rename through either coordinate is one write. asset spell-names sweeps 256 ids for inspection, so the aliased rows show above 0xD4; the patcher stops at 190.

Where the damage comes from

The table carries no power field. The cast state reads only MP, the class byte and the name pointer; the static attack-vs-defence kernel is melee / arts only. Magnitude is computed at cast time by whichever overlay runs the spell:

• Damage summons (PROT 0903 / 0904 / 0906 / 0908 / 0909 / 0910 / 0912 / 0913, plus 0914 and one arm of 0915) roll rand % (summon AGL + 1) + summon HP + caster AGL × 2 against a defender roll, then apply element affinity, status weakening and the 9999 cap - the kernels on the battle-formulas page, ported in engine-battle-vm::battle_formulas.
• Heal summons are just two of the eleven, and their formulas differ: Vera (PROT 0905) restores level × 0x20 + 0xE0 on one ally, Orb (PROT 0911) restores (level << 6) + 0x1C0 across the party and cleanses status from level 3. Both read the caster's per-magic level byte out of the character record, not a power byte.
• Neither: Nighto (PROT 0907) computes no amount at all - a kill roll zeroes the target's HP outright, otherwise it sets the confuse bits.
• Capture-class casts carry baked constants in their cast module.
• The per-move power scalar that does exist - the move-power table - feeds the arts / physical branch and shares this id space (0x25..=0x74 are the named monster attacks).

How we know

Source of record: docs/formats/spell-table.md.

See also