Items, stats and equipment

Speed Elixirs and void turns

Reported as

"Stat boost overflow": stacking Speed Elixirs in battle makes the turn-order number go negative. The character stops getting turns and "void turns" appear, where the camera swings to a spot where nobody stands and nothing happens. A dead enemy can take a turn, and the game can freeze (community report)

Cause

The turn-order number rolled from Speed is kept in 16 bits, and the routine that picks the next fighter reads its best-so-far as signed, so a number of 32,768 or more can never win

Where

Key seed FUN_801DA780 and next-actor picker FUN_801DABA4 in PROT 0898; Elixir arm 0x80041464 in SCUS_942.54

Affects

The over-boosted character and every party member seated before them; all three builds read (USA, Japanese, French)

Status

Explained - read from the instructions and captured on a poked state; the freeze is not traced

This entry is about Elixirs used in battle, and about Speed in particular. A Speed Elixir or a Wonder Elixir multiplies a character's battle Speed by 1.2, and nothing stops the next one from doing it again. On the USA disc the Speed stat itself is safe - it stops at 65,535. The overflow is one step further on, in the number the game rolls from Speed every round to decide who acts next.

That turn-order number is kept in 16 bits. The routine that picks the next fighter walks the seats in order and remembers the best number so far, but it reads the remembered number as signed and each new candidate as unsigned. A number of 32,768 or more therefore beats everything when it is the candidate, and then reads as negative when it is the remembered best - so the very next seat takes the lead from it, even a seat whose number is zero.

Two things follow. The over-boosted character can never be picked, and neither can anyone seated before them, because each of those lost the lead to the big number on the way past. And the round still hands out one turn per living fighter, so the turns those characters should have had go to whichever later seats are left. Once those have acted their numbers are zero, every remaining seat ties at zero, and the game draws one at random without asking whether anyone is there:

• an empty enemy slot - the void turn: the camera frames a spot with nobody in it and the turn ends at once;
• a fighter who has already acted, who gets a second action;
• a defeated enemy's slot, which the draw does not exclude.

The effect has a window. From an ordinary Speed it takes roughly 16 to 26 Elixirs on one character to open it, and a few more close it again: once Speed is pinned at 65,535 the sum wraps all the way round to an ordinary positive number and the character simply acts first.

Speed and Wonder Elixirs count toward the same total. Which party members lose their turns depends on where the boosted one stands: in the first seat only that character is locked out, in the second seat the first two are, and in the third seat the whole party is - and then every freed turn goes to an enemy slot, living, empty or fallen.

What was captured, and how

The mechanism was read from the instructions and then observed in PCSX-Redux on the unpatched USA disc, in a battle of three party members (seats 0 to 2, Speed 331, 364 and 310) against one enemy in seat 3. These are captures on a poked state: Speed, or the turn-order number itself, was written directly in the emulator. No Elixir was used, so the Elixir routine itself was not exercised in a running game, and nobody has yet played the 24-odd Elixirs out by hand. Commands were entered by scripted pad presses (a plain attack for every member).

Every round lasted four turns for four living fighters, whoever took them. Not captured: a defeated enemy taking a turn (the battle had one enemy, so no fallen seat existed) and the freeze, which has been neither reproduced nor traced.

The Japanese and French builds

The picker is the same in all three builds, instruction for instruction. The Elixir routine is not: the Japanese executable has no ceiling on it, so on the Japanese disc the boosted stat itself wraps round to a small number once it passes 65,535 - an Attack of 300 is 59,077 after the twenty-ninth Power Elixir and 5,356 after the thirtieth. The USA and French builds stop the stat at 65,535. The localisation closed the stat wrap and left the picker as it was.

What it is not

The permanent stat items - the six Waters, Honey and Miracle Water - cannot overflow anything. Each adds a small fixed amount to a 16-bit number and immediately compares the result with a ceiling (999, or 9,999 for HP and 280 for agility), writing the ceiling back if it was passed. The largest value that ever exists before the compare is 1003 (10015 for HP). The Japanese and French builds carry the same compares with the same ceilings. A status-screen figure above 999 is the stored stat plus equipment, summed for display.

801da800  lhu a0,0x164(a1)        ; SPD
801da840  addu a0,a0,v1           ; + rand() % (SPD/2 + 1)
801da844  addiu a0,a0,1
801da84c  sh a0,0x16c(a1)         ; 16-bit store, no ceiling

801daca4  sll v0,a1,0x10
801daca8  lhu v1,0x16c(v1)        ; candidate key, zero-extended
801dacac  sra v0,v0,0x10          ; running maximum, sign-extended
801dacb0  slt v0,v0,v1            ; (signed) max < (unsigned) candidate?
801dad60  sb v0,0x274(a1)         ; the chosen seat

800411e8  lhu v0,0x6ec(v1)      ; stored ATK (record +0x124)
800411f0  addiu v0,v0,0x4
800411f4  sh v0,0x6ec(v1)
800411fc  sltiu v0,v0,0x3e8     ; below 1000?
80041200  bne v0,zero,<exit>
8004120c  _sh v0,0x6ec(v1)      ; otherwise store 999

Verifying it

On a poked state: at the entry of 0x801DA780, write 0x8000 to +0x164 and +0x166 of the party member in seat 1. A breakpoint at 0x801DA84C shows a0 between 0x8001 and 0xC001; a breakpoint at 0x801DAD60 never shows seat 0 or seat 1 as the result, and shows an empty seat once seats 2 and up have acted. Unpoked, use Speed Elixirs on one character up to the count in the table and watch the same two breakpoints.

Still open: the freeze (a battle with one enemy already defeated and a later-seated party member in the lock-out band would show where the action state stops); and a played reproduction with real Elixirs. Related reference: item-effect table, battle action state machine, battle formulas.

Story equipment removal skips the re-check

Reported as

When the plot takes a piece of equipment, its bonus keeps working until something else re-checks equipment (community report)

Cause

The script's take-item instruction empties the equipment slot but never calls the routine that turns slots into bonuses

Where

Field script instruction 4C 52 at 0x801E1ABC (PROT 0897) and FUN_800430AC in SCUS_942.54

Affects

Nine story hand-overs of a wearable item, listed below, when the item is equipped at that moment

Status

Explained - the mechanism and the nine sites; how long the stale bonus lasts is only partly traced

An accessory's effect is not looked up when it is needed. One routine "bakes" it into each character: it reads the eight equipment slots and writes out a set of ability bits and a block of live stats. Battle, the random-encounter roll and the menus all read the baked copy, never the slots.

When the story takes an item, the script instruction first tries the bag. If the item is not there because it is being worn, it clears the equipment slot directly - and stops. It does not run the bake, so the baked copy still says the item is on.

The game does have a script instruction that writes an equipment slot and re-bakes; it is the one that grows the Ra-Seru. The take-item fallback simply does not use it.

The list is computed, not picked: every take-item instruction on the disc was decoded, and these nine are the ones whose item carries a wearable effect. All the others take key items or consumables and leave nothing behind.

How long it lasts

Until the next event that re-bakes. Entering any scene always does. So do using an item or magic from the menu, equipping or removing anything, Best Equipment, and buying-and-equipping in a shop. The field scene is reloaded after a battle, which would limit the stale bonus to a single battle fought before leaving the room; that part rests on the engine documentation and was not re-read. The in-field save screen does not re-bake. Whether simply closing the pause menu does is not traced.

801e1ac4  lbu a0,1(s6)              ; item id
801e1ac8  jal 0x80042310            ; remove one from the bag
801e1adc  bne v0,v1,0x801e00b8      ; found in the bag: done
801e1ae8  jal 0x800430ac            ; not in the bag: unequip it
801e1af0  j 0x801e3628              ; exit - no jal 0x80042558

Verifying it

Equip Yuma's Ring on Vahn: 0x800847FC has bit 0x4 and the live max MP at 0x80084810 is 110% of the stored one at 0x80084826. Give the ring to Zalan. Straight afterwards the slot bytes at 0x800848A3..0x800848A5 hold no ring, but the bit and the live max MP are unchanged. A breakpoint on 0x80042558 that logs the caller shows which event finally clears it. Related reference: accessory passives, field script VM.

Enemy items aimed at an ally

Reported as

An enemy-targeted battle item can be aimed at one of your own characters. The Point Card then hangs the battle (the "Point Card softlock"); the Lippian Flute can kill an ally who stays on their feet ("Lippian Roulette"). Outcome matrix from a community report by ZetaPhoenix

Cause

The target cursor can step onto an ally. The Point Card's damage skips the HP-counter bookkeeping the end of the action waits on; Lippian's kill runs a fade that stands a party member back up at 0 HP

Where

Item window at 0x801D18F8 and the action state machine in PROT 0898; discharge arm 0x8004209C and fade arm 0x80050230 in SCUS_942.54; Lippian cast module FUN_801F6A18 in PROT 0924

Affects

The Point Card and the Lippian Flute, aimed at any party member. Not the Spikefish Flute, which hits every enemy and never opens a cursor

Status

Explained - read from the instructions, matched against the community matrix and captured on a poked state

Two items in the game are meant for one enemy and nobody else: the Point Card and the Lippian Flute. Both can be pointed at your own party, and each does something its designers never drew.

The cursor can reach an ally. When you pick one of these items, the game builds a ring of targets that starts from whoever this character aimed at last. It builds the ring first and only afterwards checks that the last target was an enemy. If the last thing this character did was aimed at an ally - any healing item or Elixir, whose cursor starts on the user - that ally is already in the ring. The cursor is moved to an enemy, but one press of Left steps back onto the ally.

The Point Card breaks the HP display. Its damage routine subtracts HP and does nothing else. Every other routine that changes a party member's HP also notes how far the on-screen number still has to count. At the end of an action the game holds, slowly turning the camera, until on-screen HP equals real HP. Here they differ and nothing is counting, so the hold never ends: the "Points returned" caption stays up, the HP bar keeps its old value and the camera circles for good.

Lippian's kill is written for a monster. It sets HP to 0, starts the target's knockdown and switches on the fade a defeated monster disappears with. On a party member that same fade is the one a revive uses: the body goes black, is put back in its standing pose and fades in again. HP stays at 0, so the character is dead in every way except how they look.

The Point Card hang is the same end state as the first of the two known battle softlocks - the HP-counter wait - reached from the controller on an unmodified disc. It is not the approach softlock described in the endless camera orbit.

What happens, case by case

Each cell says where it comes from: C a community report (ZetaPhoenix, in game), D the disassembly, P a capture on a poked state, described below.

• The dead-ally column holds only when the item user is the first fighter to act that round. For anyone acting later the game re-rolls a dead target among the living party members, the user included, and the living-ally column applies to whoever it picks (D, P).
• Point Card on a dead ally is not quite nothing. The whole bank, up to 9999 points, is spent, a damage number is shown and the body replays its collapse. Nothing hangs because real and on-screen HP are both 0 (D, P).
• The Point Card itself is never used up. It leaves the bag when you confirm and is added back when the action starts. The Lippian Flute is consumed (D, P).
• The kill roll is 1 in 128, not 1 in 126: a random number's low seven bits must all be zero. The number 126 does appear on the item, as the effect class of its descriptor, which is not a probability (D).
• A standing character at 0 HP is dead to the rules. The command ring skips them, and when the last living member is "killed" this way the battle ends in the ordinary defeat message with the character upright (D, P).

Which items can do this

The Item window looks at two flags on the item: "enemy side" and "all targets". Only "enemy side, one target" opens the cursor whose ring is built too early.

Those are the only three consumables with the enemy-side flag. Two more descriptor rows carry the flute classes (7E 00 C6 41 and 7F 00 E6 41), and no consumable uses either. The game's own code names the same pair: the routine that re-aims an action whose target has died tests the item id against 0xFE and 0x98 and nothing else.

1. Aim at an allyA healing item or Elixir leaves an ally seat in the actor's target byte +0x1DD.
2. Pick the Point Card or the Lippian FluteThe ring is built at 0x801D18F8; the enemy check comes after, at 0x801D1918.
3. Press LeftThe cycler FUN_801D8D00 returns the ring head: the ally.
4. Point Card: the hit landsArm 0x8004209C lowers HP and seeds no countdown, so state 0x51 asks FUN_801E7250 every frame and is always told "not settled".
5. Lippian Flute: the rollOne chance in 128 at 0x801F6B14. On a miss the target is only tinted.
6. Lippian Flute: the kill0x801F7684 zeroes HP, seeds the countdown and sets the fade; the fade arm at 0x80050348 puts a party member back in the standing pose.

801d18f8  jal 0x801d8a88       ; build the target ring
801d1918  lbu v0,0x1dd(v0)     ; only now read the stored target
801d1924  sltiu v0,v0,5        ; a monster seat (3..7)?
801d1930  jal 0x801db8b4       ; if not: first living monster

801e4084  addiu v0,zero,0xfe   ; item 0xFE?
801e40bc  addiu v0,zero,0xe
801e40c0  sb v0,0x1e8(s3)      ; applier selector = 0x0E

801f6b14  andi v0,v0,0x7f      ; kill only when the low seven bits are zero
801f7684  lbu v1,0x1f1(s3)     ; the victim's knockdown clip
801f7688  lhu t0,0x14c(s3)     ; its HP
801f7690  sb v0,0x225(s3)      ; = 2
801f7694  sb v0,0x21c(s3)      ; = 2, the defeat fade
801f76a0  sh zero,0x14c(s3)    ; HP = 0
801f76a4  sb v1,0x1da(s3)      ; stage the knockdown
801f76bc  sw v1,0x10(s3)       ; countdown += old HP

801db1e0  li v0,0xfe
801db1ec  beq v1,v0,0x801db1fc    ; Point Card
801db1f0  li v0,0x98
801db1f4  bne v1,v0,0x801db300    ; anything but the Lippian Flute: leave it
801db1fc  sltiu v0,a1,0x3         ; is the dead target a party seat?

What was captured

The probe scripts/pcsx-redux/autorun_enemy_item_ally_target.lua runs on a catalogued save state with three members on the first command screen of a battle. The cursor path is the real one: it presses Begin, opens the Item window, picks the item, presses Left and confirms. Written by hand once beforehand: the item into the first bag slot, the Point Card's points, the user's stored target (the stale ally a healing item leaves), and 0 HP plus a staged knockdown on the two members who are not the user, so that they are lying dead when the walk starts. For the flute rows the kill flag is forced, since the roll is 1 in 128.

In the hang the screenshots show the "Points returned" caption still up, the HP bar at its old value and the camera at a different angle each time. In the kill-on-self runs the user is the last living member, so the standing character is followed by the party-defeat message and the title screen.

One detail explains an older report that the character is "revived" before the freeze. A lethal Point Card hit on the user's own seat shows the character collapse and stand up again: the end-of-action cleanup tells the acting character to return to the standing pose when its current clip ends. The HP bar still shows the old value, and the battle still hangs.

Verifying it

Use a healing item on the acting character, or open and cancel its ally cursor. Next turn pick the Point Card or the Lippian Flute and press Left: a breakpoint at 0x801D2630 shows a seat of 0, 1 or 2.

• Point Card: confirm, then watch the action state byte sit at 0x51 with its timer frozen at 0x3C, the target's +0x14C different from its +0x172 and its +0x10 zero. Writing +0x172 = +0x14C by hand releases the battle.
• Lippian Flute: write a non-zero word to 0x801F7C4C once the cast's phase byte ctx[+0x279] has left 0. At 0x801F76A0 register s3 is the ally's actor. Afterwards its +0x14C is 0 and its playing clip +0x1D9 is 0.
• Redirect: break on 0x801DB260. It is hit only when the user is not the round's first fighter.

Related reference: battle action state machine, item-effect table.

Open: whether a revive item works normally on a member left standing at 0 HP, and whether monsters still pick that seat; how a dead ally comes to be the stored target at command time (the round-boundary pass replaces a dead one); other builds were not read for this entry.

Coin vendor purchases past 99 (Japanese release)

Reported as

On the Japanese release a coin vendor sells an item while 99 are held; the coins go and the count stays 99 (community report)

Cause

The Japanese prize counter only asks whether the coins cover the price; the bag then adds the item and silently trims the stack back to 99

Where

Japanese prize session 0x801DE978 in PROT 0899 and bag add 0x80043210 in SCPS_100.59; USA counterparts FUN_801DC1CC and FUN_800421D4

Affects

Every coin prize row on the Japanese release; equipment bought "to the bag" in a gold shop on every release

Status

Explained - Japanese, USA and French code read; not run

At a coin prize counter the Japanese game asks one question before the Yes / No box: can the coins cover the price? It never looks at how many of the item you already hold. After Yes it adds the item and takes the coins with no further test.

The bag's add routine never refuses anything: it adds, then quietly trims the stack back to 99. So a hundredth copy costs the coins, is added, and is trimmed off again - exactly the report.

The USA build added two things in front of that. The prize list draws a row dimmed when you hold 99, and the confirm step asks "fewer than 99 held?" and buzzes if not. The French build carries both. The purchase itself and the trimming add are the same in every build.

Because only the coin counter was fixed, every release still has a relative of this fault in the ordinary gold shop. Stackable items go through a quantity screen capped at 99 - held, but equipment does not: the buy confirm tests only gold, and the "to the bag" row adds the item and debits gold with no held-count read between them. Buying a hundredth copy of one piece of equipment takes the gold and leaves 99. That is read from the instructions of the USA and Japanese builds (the French build is the USA code relocated) and has not been run.

801deb6c  slt v0,v0,v1            ; confirm: coins < price?
801deb70  beqz v0,0x801deb88      ; can afford: open the Yes / No box
801deb78  jal 0x8002cabc          ; otherwise buzz

801deca8  jal 0x80043210          ; commit: bag add (id, 1), result ignored

80043334  slti v0,v0,0x64         ; bag add: over 99?
80043340  addiu v1,zero,0x63      ; then 99
8004334c  sb v1,-0x4037(at)

801dc3dc  jal 0x80042f4c          ; held count
801dc3ec  slti v0,v0,0x63
801dc3f0  bne v0,zero,0x801dc408  ; fewer than 99: open Yes / No
801dc3f8  jal 0x80035bd0          ; otherwise buzz and stay

801dc514  jal 0x800421d4          ; commit: bag add, result ignored
801dc550  sw v1,0x464(a0)         ; coins -= price

800422f0  slti v0,v0,0x64         ; bag add: over 99?
800422fc  li v1,0x63              ; then 99
80042300  sb v1,0x1819(a0)

Verifying it

On a Japanese disc hold 99 of a prize item and buy another: a breakpoint at 0x801DEB70 shows the branch to the confirm window taken, and after Yes the coin word at 0x801CAC14 drops by the price while the item's count byte stays 0x63. On the USA disc the same attempt buzzes and no box opens; forcing the branch at 0x801DC3F0 to be taken reproduces the Japanese behaviour. Still unrun on any release: holding 99 of one weapon and buying one more to the bag. Related reference: shops and the prize exchange, inventory.

War God Icon can be missed for good

Reported as

The War God Icon is lost for good if the Muscle Dome Expert Course is beaten before defeating Jette (community report)

Cause

The item and its "already awarded" flag are handed out by two different pieces of code that disagree about what clearing the course means

Where

Arena settlement FUN_801D0F60 in PROT 0977; lobby victory scene, record P2[9] of scene koin1 (PROT 543)

Affects

The Master course - not Expert as reported - won while it is still shortened

Status

Explained - from the instructions and the scene script; not run

The prize is split in two. The item is added by the arena program, and only when the contest ended on its thirteenth fight and an "already awarded" flag is clear. The flag is set by the lobby's victory scene, which only asks: was this a Master contest, and was it won?

Early in the story the Master course is cut short to 8, 11 or 12 fights. Winning the shortened course is still a win as far as the victory scene is concerned, so it sets the flag and plays the presentation - the announcer names the Icon. But the arena saw fewer than thirteen fights and added nothing. From then on the flag is set, and the arena skips the item every time, including after a full thirteen-fight win.

The last of the three story flags that lengthen the course is set inside Jette's Fortress. That is where "before defeating Jette" comes from.

The tests overwrite one another in order, so the last missing flag decides: with all three missing the course runs 12 fights.

801ced44  jal 0x8003ce64   ; flag 0x378 missing: length 8
801ced6c  jal 0x8003ce64   ; flag 0x382 missing: length 11
801ced94  jal 0x8003ce64   ; flag 0x471 missing: length 12

801d111c  slti a1,a1,0xd          ; round reached below 13?
801d1124  bnez a1,0x801d1148      ; yes: no item
801d112c  jal 0x8003ce64          ; flag 0x6CB
801d1134  bnez v0,0x801d114c      ; set: no item
801d1140  jal 0x800421d4          ; War God Icon (item 0xCD) x1

Verifying it

From a save with flag 0x471 clear, win the Master course. It ends after fight 12; a breakpoint at 0x801D1124 shows the branch taken and the item add skipped; after the lobby scene, byte 0x80085831 has bit 0x10 set. The counter-test: clear that bit, set 0x471, win thirteen fights, and the item arrives. Clearing bit 0x10 at 0x80085831 should repair an affected save.

Open: whether the party can leave Jette's Fortress between the last flag being set and the Jette fight was not checked.