• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[ASM & Hex] Is there a COMPLETE and documented list of the status condition data in Generation 3?

  • 12
    Posts
    3
    Years
    • Seen Jul 19, 2022
    Hello everyone 😀

    Does anybody of you know the very details about the status condition data in Gen 3?
    According to this article the status condition is a DWORD (32 Bits), but they only describe Bit 0-7 in detail later.

    I also tried to crawl through the decomp for Ruby, but my brain already starts to melt.
    It seems they have defined Bit-masks to filter for certain conditions.
    But I don't understand why there is a differentiation between STATUS1, STATUS2 and STATUS3 values and also why the Bit-masks between those overlap (well, yes i know about volatile and persisting conditions, but still why is it split this way?!).
    My best guess is, that the masks for STATUS1* have an offset of 0x0, and for STATUS2* the offset is (where the mask is applied) is even higher... still the theory doesn't really check out since the mask for STATUS2_TORMENT is 0x80000000 (32nd Bit) and that would make out out of bounds if an offset is added.

    Also it seems that the decomp declares both status1 and status2 (both u32... wtf?) where those flags are applied later.
    But I am probably too dumb to understand how .status1 and .status2 are even set, so I can find out what data is stored in there...
    STATUS3* stuff seems to be applied to an array gStatuses3 which keeps flags during a battle.

    What I want in the end is a >complete< map of the 32 Bits of the status condition data, where it is explained what each Bit represents.

    Been trying to understand for a while now, but it's super frustrating 😱
     
    What I want in the end is a >complete< map of the 32 Bits of the status condition data, where it is explained what each Bit represents.
    Those bitmask definitions you found are probably the closest you can get.

    The STATUS1, STATUS2 and STATUS3 definitions are meant to be used with completely different variables.
    STATUS1 is for the status field in the Pokemon structure (this is what is described in the bulbapedia article you linked), while STATUS2 and STATUS3 are for variables that are only used in battles and are not a part of the Pokemon struct.

    Any bits not mentioned in the bitmask definitions are likely unused.
     
    Hmmm OK...
    I find it kinda strange though, because the Toxic Counter seems to be part of the STATUS1 masks.
    This is not mentioned in the Bulbapedia article at all and to my knowledge the Toxic counter gets reset after battle (or even when switching out during it) - and at least I would have thought that the other stuff gets treated just the same way.

    According to the decomp this means, that out of all the 32 Bit in the Pokemon struct, only the first 12 are used (8 for all the status condition and an additional 4 for the Toxic Counter).
    I mean this can of course be the case, but I thought it was highly unlikely because it doesn't even use half of it.
    That counter would make more sense if it was in the volatile category as well tbh, then they could have rolled with a simple Byte for all the permanent ones, which haven't changed in any game to this day afaik.
     
    I'm honestly wondering if Bulbapedia is wrong on this point, and the Toxic counter doesn't reset on switch-out. I couldn't find any code which does it unless there's something very odd going on where the status field is truncated to eight bits in the process of being copied from the battle struct to the Pokemon struct. Can anyone test?
     
    I will check this out later today when I am back home.
    Should be possible to use Toxic on myself in a double battle and see how the damage ticks after switching out and in (if I am able to, I will also show the data in memory viewer, so I should be able to see the corresponding DWORD).
     
    I just tested it out, and yes, the Toxic counter resets when you switch the Pokemon during combat.
    The interesting thing is now to understand how and where this happens.
    Trying to pin down the memory address with the DWORD so I can investigate the Bits a bit (hehe).
     
    So, I just tested Toxic on myself with a double battle.
    The following picture shows the DWORD for the status conditions of the first Pokemon of my Party (Ruby/Sapphire offset) - keep in mind the data has to be read in a Little-Endian way:
    Spoiler:


    As you can see, there is only the Toxic flag (8th) set in the Pokemon struct itself, the Toxic Counter is completely absent (should be 3 or 4 when I took the screenshot).
    This means either that the TOXIC counter is actually NOT part of the STATUS1* bitmasks (and the struct stored in the Pokemon), or that the whole DWORD is copied to a new memory location during fight, and the lowest 8 Bits are kept sync with the "real" DWORD.
    Oh boy, what an absolute brainfuck to wrap your head around 😱
    Will investigate further... maybe i manage to pin down the memory location of STATUS1 and STATUS2 (and maybe even STATUS3)
     
    Last edited:
    https://bulbapedia.bulbagarden.net/wiki/Status_condition#Badly_poisoned
    Badly poisoned:

    The bad poison condition inflicts damage every turn, with the amount of damage increasing each turn. It initially inflicts damage equal to 1/16 of the Pokémon's maximum HP, with the damage inflicted increasing by 1/16 each turn (2/16 on the second turn, 3/16 on the third turn, etc.). In Generation V, Pokémon glow purple while afflicted with bad poison.

    In Generations I and II, if a badly poisoned Pokémon is switched out, the condition reverts to regular poison. From Generation III onward, the poison remains bad poison while switched out, but the damage counter will be reset when switched back in (i.e. it always will take 1/16 of its maximum HP as damage after switching in). After a battle is over, the badly poisoned status will become a regular poison.

    All moves which badly poison are Poison-type, except Psycho Shift (while badly poisoned) and Fling (if Toxic Orb is held).

    ---

    I just checked this myself and the status condition keeps being "badly poisoned" after the battle ends, and I could confirm it too by the amount of damage I took during the next battle (against a lvl 3 enemy).
    To be sure I also checked it with Emerald - exact same behavior.
    Seems the statements on Bulbapedia aren't quite correct.
    Can someone of you check this with a newer generation game maybe?
    Will try to contact someone from Bulbapedia to get this corrected.
     
    As you can see, there is only the Toxic flag (8th) set in the Pokemon struct itself, the Toxic Counter is completely absent (should be 3 or 4 when I took the screenshot).
    This means either that the TOXIC counter is actually NOT part of the STATUS1* bitmasks (and the struct stored in the Pokemon), or that the whole DWORD is copied to a new memory location during fight, and the lowest 8 Bits are kept sync with the "real" DWORD.
    The pret repos have symbol files available in a branch, so you don't need to hunt for the other status fields.
    • gBattleMons at 0x02024084 has the in-battle status fields (STATUS1 for nonvolatile, STATUS2 for volatile).
    • gStatuses3 at 0x02024C98 has the third status field.
     
    Back
    Top