- 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 😱
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 😱