Topic: Shadow Party Stats

[Pinkpuff]

I've conceptualized and have started writing new subroutines to fix this, so that all 14 characters in my hack can be switched in and out freely.

If you can figure out how to do this, if it's not too much trouble, would you be able to describe how it's done? I'm sure I'm not the only one who would like to make a hack which gives the players the ability to change party members among the whole cast.

[Phoenix]

I can tell you the concept (which is pretty simple), but you would need some ASM knowledge and understanding of the shadow data loading/storing subroutines to be able to write a fix yourself. What's probably easier for everyone is if I release a patch to change the behavior, which I plan on doing once I incorporate a working version in my hack.

Here's the concept for those of you that are interested: There are five shadow data slots of 64 bytes each. These store the same stat data as the RAM locations that store your current party stats. If you want to see what these are, click the spoiler button below. (I took these from the Tower of Bab-il documents; I didn't come up with them on my own.)

[spoiler]1000   *character id/handedness
1001   *class id/row properties
1002   level
1003-6   current status anomalies
1007-8   current hp
1009-A   maximum hp
100B-C   current mp
100D-E   maximum mp
100F   *base strength
1010   *base agility
1011   *base vitality
1012   *base wisdom
1013   *base willpower
1014   *modified strength
1015   modified agility
1016   *modified vitality
1017   modified wisdom
1018   modified willpower
1019   attack elemental
101A   *attack strong vs. creature types***
101B   physical attack multiplier
101C   physical attack percent
101D   physical attack base
101E   attack status 1***
101F   attack status 2***
1020   elements weak vs***
1021   elements very weak vs***
1022   magical defense multiplier
1023   magical defense percent
1024   magical defense base
1025   elemental defense (if immunity bit wasn't set)***
1026   elemental defense (if immunity bit was set)***
1027   *defense strong vs. creature types***
1028   physical defense multiplier
1029   physical defense percent
102A   physical defense base
102B   status immunity 1***
102C   status immunity 2***
102D-F   ?
1030   *helmet
1031   *armor
1032   *gauntlet
1033   *right-hand item
1034   *right-hand quantity
1035   *left-hand item
1036   *left-hand quantity
1037-9   *experience
103A   ?
103B   speed modifier. lower = faster. for autobattles, starts at 01; otherwise
      starts at 10. slow adds +08, (upper bound 20) haste adds -3 (lower bound 0C)
103C   ?
103D-F   *experience to level up
[/spoiler]

Since there aren't any unused locations of RAM (that I know of), I knew I had to fit as many characters' stat data within this 64 x 5 = 320 bytes of data that I could. Ideally, this would be 14, because there are 14 character classes and sets of sprites (not including Golbez and Anna, who don't have complete sets). In order to do this, I needed to store only the absolutely essential stats of a character, removing non-essential stats like modified strength/agility/vitality, hit percentage, attack statuses, etc. I call these "non-essential" because they can be calculated from a character's base stats and equipment data.

Looking at the data, I pared the stat list down to: character id (1 byte), class id (1), level (1), max HP (2), max MP (2), base str/agil/vit/wis/will (5), helmet (1), armor (1), gauntlet (1), right-hand weapon (2), left-hand weapon (2), and experience (3). This adds up to 22 essential bytes per character. Finally, I divided the 320-byte block by 22, and lo and behold there's room for 320/22 = 14.54 characters. It's like it was fated to be.

A bonus side effect of this method is that this should fix the adamant armor bug, since switching characters out would clear the elemental defense byte of the character.

[Deathlike2]

Since there aren't any unused locations of RAM (that I know of), I knew I had to fit as many characters' stat data within this 64 x 5 = 320 bytes of data that I could. Ideally, this would be 14, because there are 14 character classes and sets of sprites (not including Golbez and Anna, who don't have complete sets). In order to do this, I needed to store only the absolutely essential stats of a character, removing non-essential stats like modified strength/agility/vitality, hit percentage, attack statuses, etc. I call these "non-essential" because they can be calculated from a character's base stats and equipment data.

Looking at the data, I pared the stat list down to: character id (1 byte), class id (1), level (1), max HP (2), max MP (2), base str/agil/vit/wis/will (5), helmet (1), armor (1), gauntlet (1), right-hand weapon (2), left-hand weapon (2), and experience (3). This adds up to 22 essential bytes per character. Finally, I divided the 320-byte block by 22, and lo and behold there's room for 320/22 = 14.54 characters. It's like it was fated to be.

Can you say, incompatible SRAM time! The only issue you would have to deal with though is refreshing the character's data, since it is updated via the Equip menu...

Edit: As an aside, a conversion app would be nice, but not required. If the data is fucked up (not sure how you'd test this), use the default character data.

A bonus side effect of this method is that this should fix the adamant armor bug, since switching characters out would clear the elemental defense byte of the character.

Great, so make that fix pronto! 

Also, I have an idea...

Additional Edit: I do blame FF4A (US/Jap v1.0) for this idea, but there should be some event trigger/script that's executed to enable/disable characters gaining EXP while not in the active party. This way, you can maximize their stats and potential, which would make this version much more superior than its FF4A brethren.

[Phoenix]

The only issue you would have to deal with though is refreshing the character's data, since it is updated via the Equip menu...

I worried about the same thing, but it turns out that some check after the stat data is loaded takes care of this, and the non-essential stats are loaded into RAM at the same time the character is added to the party. Lucky for me, I guess. 

As an aside, a conversion app would be nice, but not required. If the data is fucked up (not sure how you'd test this), use the default character data.

Do you mean a conversion between the original FF2/4 SRAM data and the patched one? This would have to be up to somebody else, since I'm not really a programmer; and if I was, it would be on a Mac, which most people wouldn't find very helpful. 

I do blame FF4A (US/Jap v1.0) for this idea, but there should be some event trigger/script that's executed to enable/disable characters gaining EXP while not in the active party. This way, you can maximize their stats and potential, which would make this version much more superior than its FF4A brethren.

Hmm...if I come across the experience adding subroutine that might be possible, but as of now I don't know the location of it. If someone finds it let me know.

[Deathlike2]

From the info that was quoted from the docs...

[spoiler]1000   *character id/handedness
1001   *class id/row properties
1002   level
1003-6   current status anomalies
1007-8   current hp
1009-A   maximum hp
100B-C   current mp
100D-E   maximum mp
100F   *base strength
1010   *base agility
1011   *base vitality
1012   *base wisdom
1013   *base willpower
1014   *modified strength
1015   modified agility
1016   *modified vitality
1017   modified wisdom
1018   modified willpower
1019   attack elemental
101A   *attack strong vs. creature types***
101B   physical attack multiplier
101C   physical attack percent
101D   physical attack base
101E   attack status 1***
101F   attack status 2***
1020   elements weak vs***
1021   elements very weak vs***
1022   magical defense multiplier
1023   magical defense percent
1024   magical defense base
1025   elemental defense (if immunity bit wasn't set)***
1026   elemental defense (if immunity bit was set)***
1027   *defense strong vs. creature types***
1028   physical defense multiplier
1029   physical defense percent
102A   physical defense base
102B   status immunity 1***
102C   status immunity 2***
102D-F   ?
1030   *helmet
1031   *armor
1032   *gauntlet
1033   *right-hand item
1034   *right-hand quantity
1035   *left-hand item
1036   *left-hand quantity
1037-9   *experience
103A   ?
103B   speed modifier. lower = faster. for autobattles, starts at 01; otherwise
      starts at 10. slow adds +08, (upper bound 20) haste adds -3 (lower bound 0C)
103C   ?
103D-F   *experience to level up
[/spoiler]

102D-F is most likely status immunities for the other stuff (Egg, Defense, Reflect, etc)... which AFAIK don't have a resistance to begin with.

On the other hand, those locations and/or 103A and 103C are the info revolving around the other equipment bits.

I'm talking about the bits that control back row compat, metallic, throwable... which I've also mentioned that some of those bits (no critical hits, back row compatible weapon) are buggy.

[Phoenix]

102F is related to escaping. The data there is modified when using Porom's Cry command. My thought is that it is some type of internal "Luck" stat, that is used when determining whether the party can escape, and maybe other times.

The data from 102D-F is calculated during the equipment initialization, so it could be immunities for the other statuses; however, those statuses don't really need immunities (Barrier, Wall, image, jumping, hiding, etc.). Also, the values don't really seem to support this. At the beginning of the game, the values for Cecil at 102D-E are 02 and 14, which would imply immunity to Stop, image high, and Wall. Since we know this isn't true, it must be something else.

They could be related to the other equipment bits. Since they're buggy it's difficult to test. However, the 102D-F data comes from within the character stats; the bits that control metallic/throwable/etc. are stored within the equipment data, meaning they are calculated from the equipment. It's unlikely that equipment data would be stored within the character stat data. This is why I think those three bytes may be some internal "Luck" stat, or something to that effect.

[Deathlike2]

102F is related to escaping. The data there is modified when using Porom's Cry command. My thought is that it is some type of internal "Luck" stat, that is used when determining whether the party can escape, and maybe other times.

AFAIK, Cry seems to reduce the time to run in half, and the behavior is stackable (up to a point).

The ability to run away AFAIK is either tied to Agility and/or Level.

They could be related to the other equipment bits. Since they're buggy it's difficult to test. However, the 102D-F data comes from within the character stats; the bits that control metallic/throwable/etc. are stored within the equipment data, meaning they are calculated from the equipment. It's unlikely that equipment data would be stored within the character stat data. This is why I think those three bytes may be some internal "Luck" stat, or something to that effect.

You can easily test it believe it or not. Since they are buggy, just compare the data from before/after equipping stuff. The bug happens to be that the no-critical hit bit and back row bit doesn't revert when removed.

Some examples:

Dwarf Axe - no crit + back row
Arrows or Bows - back row
Boomerangs - back row
Whip - no crit + back row

Note that the back row detail requires 2 bits. A bow and arrow combo sets boths bits required for the back row check. I wrote specifically on how the back row check works.. if you need to test it out for yourself.

The back row check is like this (perhaps I need to write it in a separate thread):

1) Check if character is in back row and/or target is in back row
2) If true, determine the number of weapons equipped
3a) If there is 1, check if weapon is back row compatible
3b) If there is 2, check if both weapons are back row compatible (this includes Bow+Arrow combos)
4) If false, reduce hit rate by 1/2, repeat reduction if target is considered in the back row (stackable)

Since the back row bit is not unset when deequiping non-back row compatible weapons, you can check the bits for the bug and therefore determine the changes in the Shadow Data.

[Phoenix]

I believe the long-range/back-row-compatible bit is stored within the second byte of the character stat data, along with the class id. I noticed this when handling the shadow stat data, Rosa's class id was always 25 (when it should be 05). I traced it to characters with a long-range weapon. So, the bits for this byte are:

0-4   Class ID (class, appearance, magic)
5        long-range weapon
6        ?
7        in back row

This is another reason why I think it's unlikely that this bit is stored in 102D-E, because it's already stored here. (The 6th bit was never active for any character that I could find, so I don't know what it's for yet.)

The no-critical bit isn't stored in the class ID, however, so I did test changing weapons to see if the bits were loaded. However, 102D-F remained unchanged for my tests.

One last note: My method of shadowing stat data should also remove the back row bit bug, since I'll remove the top three bits when storing/retrieving so I can just use the class id. If we can find the other bits, I can see if I can reset them as well. I'll see if I can search for subroutines that load the weapon data, and check those out.

[Deathlike2]

The "back row bit" has gotta be two bits. You can test this with Edge and Boomerangs...  one of the bits is set, even after you remove the weapon on the hand it was equipped on. Once the back row bits are set on both hands, both weapons instantly become back row compatible.

Rosa starts with a Bow+Arrow combo initially. Changing the set to something else initially is an easier method of testing this with either Bow or Arrow.

Two bits are needed.. one for each hand.

[Phoenix]

Perhaps that's what the bit 6 is in the class id. It would make sense. I'll test it when I have time later.

[Deathlike2]

I forgot to mention that the Silence Staff also prevents critical hits, which is also worth testing against.

[Phoenix]

Bit 6 in the class id is NOT set when equipping a long-range weapon to either hand. I still don't know what it's used for.

Equipping a long-range weapon in Edge's left-hand has strange behavior. It doesn't set bit 5 if you have a short-range weapon in his right-hand. If the right-hand is empty or has a long-range weapon, however, then the bit is set. For his right-hand, as soon as you equip a long-range weapon, it does set bit 5. You can see this behavior if Edge has two swords in his hands, and you equip a boomerang in his left-hand and move him to the back row. He'll still do half damage, compared to if you equip a boomerang in his right-hand and stick him in the back row. So although he's ambidextrous, apparently he's still right-hand dominant.    Also, I tested bows and arrows with Cecil, and the bit is only set once both the bow and arrow are equipped (hands don't matter).

I've confirmed that once you remove the weapon, bit 5 stays set. Unless the character leaves your party, it's stuck. Which is actually beneficial, considering you can then use short-range weapons in the back row.

[Deathlike2]

Bit 6 in the class id is NOT set when equipping a long-range weapon to either hand. I still don't know what it's used for.

Equipping a long-range weapon in Edge's left-hand has strange behavior. It doesn't set bit 5 if you have a short-range weapon in his right-hand. If the right-hand is empty or has a long-range weapon, however, then the bit is set. For his right-hand, as soon as you equip a long-range weapon, it does set bit 5. You can see this behavior if Edge has two swords in his hands, and you equip a boomerang in his left-hand and move him to the back row. He'll still do half damage, compared to if you equip a boomerang in his right-hand and stick him in the back row. So although he's ambidextrous, apparently he's still right-hand dominant.    Also, I tested bows and arrows with Cecil, and the bit is only set once both the bow and arrow are equipped (hands don't matter).

I've confirmed that once you remove the weapon, bit 5 stays set. Unless the character leaves your party, it's stuck. Which is actually beneficial, considering you can then use short-range weapons in the back row.

Ok, I believe I have confirmed that behavior for Edge.

The only part that doesn't make sense is for left-handed people. I suspect the algo checks for handedness first (ambidexterous defaults to right handed). That would make a lot more sense.

Try see if bit 6 is either the "no critical hit" bit or metallic bit... that's all I can think of at the top of my head.

The only character that doesn't fit this is Edward.. so I'm kinda at a loss at the moment for ideas.

It would help if you kindly give all the weapon/armor info for those character profiles that have that bit set.. there's usually something in common with them all that I simply can't think off at the top of my head.

[Phoenix]

Bit 6 isn't the no critical bit or the metallic bit. As far as I can tell, it's not used for anything. If it was ever set, I could trace it to something, but any RAM that I've analyzed doesn't have it set.

Edward, like Rosa, always has bit 5 set. He starts with a harp, which is a long-range weapon, so the bit is always set.

You want weapon/armor info for characters that have bit 5 set? Or bit 6? (I can't provide any data for the latter.)

[Deathlike2]

Actually, never mind that... I think my reading comprehension is being reduced too quickly to tell. 

The left handed check for back row compatible weapons the should be correct though...

Now I'm very curious how the back row bit is supposed to work in FF4A for ambidextrous characters.