Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation III Glitch Discussion

"Used a (TYPE) move" cause - Pokémon Ruby - Page 1

"Used a (TYPE) move" cause - Pokémon Ruby

Posted by: Torchickens
Date: 2015-01-04 14:30:48
Wack0 did some research into the glitch moves that display "used a (TYPE) move" on English Ruby and wanted me to post it for him.

First, here are the strings that appear in the Ruby text dump:

a NORMAL move
a FIGHTING move
a FLYING move
a POISON move
a GROUND move
a ROCK move
a BUG move
a GHOST move
a STEEL move
a ??? move
a FIRE move
a WATER move
a GRASS move
an ELECTRIC move
a PSYCHIC move
an ICE move
a DRAGON move
a DARK move


The explanation is apparently rather simple:

Wack0 dumped this unmodified code ("from hexrays", I'm not sure what that means). The code begins at offset 0x120DE8 (or 8120DE8 in memory viewer).


if ( (unsigned int)*(_WORD *)dword_2039270 <= 0x162 )
          strcpy((unsigned _int8 )byte_3004290, &byte_81F8320[13  (WORD )dword_2039270]);
        else
          strcpy((unsigned int8 *)byte_3004290, off_8401674[(unsigned int8)byte_20160A0]);


Commented:

// ptrGenericTypeMoveStrings contains pointers to the "a NORMAL move", "a FIGHTING move" etc strings, ordered by type index.
// So, ptrGenericTypeMoveStrings[0] is "a NORMAL move" etc.
// This was probably used for debugging purposes during development.
// However, if the selected move is of an invalid type (above DARK, 0x11), a string is taken from DWORDs located after the array.

if ( *ptrSelectedMoveIndex <= 0x162 )
strcpy(UsedMoveName, &MoveNames[13 * *ptrSelectedMoveIndex]);
else
strcpy(UsedMoveName, ptrGenericTypeMoveStrings[SelectedMoveType]);


It simply looks like if the move ID is greater than 0x162 (Psycho Boost), then the game is programmed to say "a(n) [type] move", but this doesn't always happen, probably because of either moves that have a very long "Super Glitch" causing name and/or have an invalid type (above Dark, 0x11); where the game will display text from an invalid pointer instead of something like "a NORMAL move".

Re: "Used a (TYPE) move" cause - Pokémon Ruby

Posted by: Stackout
Date: 2015-01-04 14:45:20
To clarify:

1) "hexrays" here means the commercial Hex-Rays decompiler plugin for the also-commercial IDA disassembler, which transforms disassembled code of supported architectures (currently x86, x64 and ARM) to more readable C-like code. Both have had several versions leaked onto the internet; however the ARM version only leaked last summer, and the x64 version hasn't been leaked at all yet.

2) Moves that have a very long name could cause it. However at least two locations in RAM (the byte at 0x20160A0 (selected move's type) and the word at 0x2039270 (selected move's index number) in English Ruby) would need to have been corrupted and not changed. I'm not sure if this could occur without cheating. The main cause of this would be an invalid move with an invalid type.

Sometime I should try and correspond the move type as shown in battle with the type sprite in summary.

I know that in Emerald, type 0xE1 crashes when its summary sprite is attempted to be shown, and it shows up in battle as type "curacy." (this is taken from ability descriptions, in fact in Emerald, all move types from 0x32 onward have battle type names taken from ability descriptions). (Fun fact: one example move of type 0xE1 is the one shown in that "Emerald Super Glitch" video.)