Main Menu
Main Page
New pages
Recent changes
Random page

Arbitrary code execution
Pokémon cloning
Pomeg glitch and Glitzer Popping
Tweaking and voiding
Glitches by generation
Other glitch categories

Disassembly projects
The Big HEX List
Interactive tools
Reference documents

Legendary Star Blob 2 (Hakuda) (日本語/Japanese)
Pokémon Speedruns wiki (English)
PRAMA Initiative (Français/French)
MissingNo. Glitch City (Italiano/Italian)
Become an affiliate!

Site source code

Search Wiki


Search Forums


Author Topic: "Used a (TYPE) move" cause - Pokémon Ruby  (Read 1709 times)

0 Members and 1 Guest are viewing this topic.

Evie the Mother Hen ☽ ❤

  • Head Administrator
  • *****
  • Offline Offline
  • Gender: Female
  • I love My Melody ✿(not really a mum but wanna be)
    • View Profile
"Used a (TYPE) move" cause - Pokémon Ruby
« on: January 04, 2015, 02:30:48 pm »
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 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]);
          strcpy((unsigned int8 *)byte_3004290, off_8401674[(unsigned int8)byte_20160A0]);


// 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]);
   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".
« Last Edit: January 04, 2015, 04:13:18 pm by Torchickens »

Here have some free flowers on every post :)

(Images © Sanrio, Nintendo, Pokémon, HAL Laboratory)

✿ Hi, I'm Evie. Transgender woman but spiritually doesn't believe 'male'/'female' needs to be defined; lives more stereotypically like a woman/I'm a 'girly' nerd who discovered herself. Call me whichever pronouns you like. :)

Feel free to contact me here about anything regarding the site.

Forgiveness. I feel that the more people pray to our greatest source/God/mathematical equality for world peace, the more and more it manifests into reality (until our next spiritual death).

Thank you Nyapon for this lovely artwork. :3


  • Coder, reverser, beta collector [BetaArchive staff]
  • Distinguished Member
  • *
  • Offline Offline
  • Gender: Male
  • cBRH - Doing nothing since 2k7
    • View Profile
Re: "Used a (TYPE) move" cause - Pokémon Ruby
« Reply #1 on: January 04, 2015, 02:45:20 pm »
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.)
C H E C K E D . B U I L D S . A R E . A W E S O M E N E S S

BetaArchiveSoftHistory #galaxy,#softhistory

Also known as The Distractor.

Shane, please stop telling children that there's a Mew outside under the delivery trucks. - Management

Pokémon: arbitrary code execution 1996-2016