Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: DLPB_ on 2012-08-01 07:43:48
-
I would spend more time on this if I really felt it was needed but I have done what i set out to do.
Each enemy model has a corresponding **ab file (for example Midgardsormr's is ddba). The 3rd byte of this file is the identifier for the death animation (Death Value) AND identifier for model type (so far unknown what this type is and why it needs to be set). The Death Value is used at 004258ac when the battle ends to determine what death animation the model will undergo.
The following game code is a break down of how the game uses the 3rd byte of **ab.
Code starts At 0042bc7a
mov cl,[eax+02]: Takes the 3rd byte of the **ab file and places into cl
mov [edx+00BE119F],cl: Places in new address
This address is then accessed by a few places
but the one related to the death animation is at 0042BE62
mov dl,[ecx+00BE119F].
And edx,3F
The And edx,3F is stripping away the model type identifier which
is the high bit of the 8 bit register. Therefore 80 would become 00
and 82 would become 02.
Then the Death Value is placed in a new memory
address (mov [eax+009A87F8],dl) at 0042BE72.
This memory address is the one used for death animation when the battle ends.
The usual area is 009a8838 for first enemy. I will use this address when
referring to the Death Value Memory Address.
This value is then accessed at 004258AC
mov dl,[ecx+009A87F8]
mov [ebp-08],edx
cmp dword ptr [ebp-08],12
ja 00425A72
A comparison is made with 12 (Sepher Sephiroth's and largest normal value).
If greater it will jump to end of function and do nothing
the same as value 10 jumps to the end of function.
When this occurs, the enemy stays on screen at battle end.
The value is now in [ebp-08]
if not greater than 12, it continues:
xor eax,eax
mov ecx,[ebp-08]
mov al,[ecx+00425A9A]
The value is now providing an offset to a memory address to find a new value
This value is placed in al.
jmp dword ptr [eax*4+00425A76]
al from above is now used as an offset to new memory address which
holds the address to jump to. In the case of a normal enemy death (ecx 00)
mov al,[ecx+00425A9A] returns a value ALSO of 00
al is now 00
jmp dword ptr [eax*4+00425A76]
Since al (and therefore eax given the xor above) is 00, at 00425A76 onwards you
find a table of addresses, and the address at 00425A76 is used for the jump in
the case of a normal death enemy. In this case Jump to 004258d1.
This pushes a new value then makes a specific call. The push and call function will change
as the jump address changes. This section of code contains all necessary parts for each
of the games death animations.
You can see further down that the obvious jump-to locations are:
004258D1
0042590C
00425947
00425991
004259CC
00425A04
00425A3C
These are all involved in the actual animation itself based on the death value.
The Death Value merely ends up providing a jump to one of the above addresses.
Therefore there are 7 distinct death animations.
If you want to force death value without having to keep changing the battle files,
change the jump at 004258CA (that's CA) to force the exact area you want to start at from list
above, or probably best, change 004258AC (that's AC) to mov [ebp-08],00000002 where 2 is
"melt" and 11 is "boss" etc.
High Bit Model Type Identifier.
As said, when the 3rd byte is set to 80-FF in **ab, the high bit will be set to 1.
I have not gone into this much but the 2 areas involved are at 0042BE84 (at battle start)
and 00429858 (constantly accessed on loop during battle).
Death Values are 00-12, and they are as follows:
00: Normal
01: Disintegrate (Think mechanical things)
02: Melt (Think 8-eye, flans and Tonberry's)
03: Disintegrate 2
04-06: No death animation, enemy will remain as battle ends.
07: Morph
08: Flash death (Flash animation where enemy floats to sky. Translated Iainuki)
09: No death animation, enemy will remain as battle ends.
0A: Disintegrate
0B-10: No death animation, enemy will remain as battle ends.
11: Boss death
12: Boss death
And as memory addresses
for main functions:
004258D1: Normal
0042590C: Flash
00425947: Disintegrate 1
00425991: Melt
004259CC: Disintegrate 2
00425A04: Boss
00425A3C: Morph
00425A72: No death animation.
Pointed to from 004258CA
My conclusions are these:
- 07 and 08 are animations associated with actions during battle. When a player uses Morph or Flash, the new death value is placed in memory, replacing the one that was placed there from the **ab file.
- Although 12 is set by Sepher Sephiroth's **ab file, the value is not used in that battle, as the death animation is hard-coded. 12 simply jumps to the same place as 11 and performs the same action when not Sepher (which bypasses the death animation code altogether as said). If you look at the entries above it seems fairly likely that the design team had a number of entries that weren't used or ended up being dropped (04-06,0b-09, 0a,12, 13-FF). The code has been changed to reflect only values of 00-12. First an "And 3F" is used to clamp the lower 6 bits and then a compare is made to reflect only values 00-12. Anything else simply performs no animation (like 10).
- When Values greater than 10 are used (11 and 12), the game will not allow Morph or Flash to change the death value. If the death value is not 11 or 12, the new value will be reflected. This is because the game checks to ensure bosses do not perform the Morph and Flash animations. A boss will always die like a boss unless the jump is deleted at 005DB127 for Flash ( 8 ) and 005CACEE for Morph (7).
- The Model Type Identifier is the high bit (of 8 bit register). Therefore, values 80+ in the **ab file will set the high bit to 1. The difference between models using the high bit and those that do not is unknown. The **ab file relies on the skeleton file (**aa) when the high bit is set to 1. If the skeleton does not belong to the correct model and the highbit is set there is a crash. Therefore the model type set by the high bit is related to the skeleton. Setting high bit to 0 on the wrong model seems to have no adverse effects. Certainly there is no crash.
- When the high bit identifier is set to 0, animation values in the **ab files are 00-12 (as above). However, to achieve the same animations when it is set to 1, values 80-92 are used instead. This is because the code at 0042BE68 strips away the identifier for purposes of keeping the actual death value. In other words, the death value placed into memory (009a8838 for first enemy) for **ab values 82 and 02 (for example) is the same. If you wanted a melt animation with a normal enemy (high bit set to 0), you would use 02 in the **ab file. If you wanted melt animation with a model with the high bit set to 1, you would use 82. In both cases 02 will be placed as the death value in memory. Remember the death value has nothing to do with the high-bit identifier. The identifier is letting the game know which of the 2 types of model are being used. What distinguishes these 2 types is unknown. The only things that set the high bit in the default game are User characters (like Cloud), Yuffie battle and certain human enemies (like MP).
- The melt (Death Value 2) animation is broken. It has been broken in the PC version for as long as I can remember. When the animation finishes the model temporarily restores to its full size again. I will see if I can fix this.
-
What about Steel Bladed Sword? Does it use a specific death animation or is that another built-in thing?
edit:
Also, the 40 and 80 bits have a different function from the other bits. They're part of something else and aren't considered in choosing the death type.
-
The steel bladed sword certainly isn't part of the normal set up since there are only 7 functions inside the main code for the 7 types of death (which you can force just by altering the jump). Must be handled elsewhere.
As for 40 (and well spotted! ;)), this means there are 2 flags for the 2 higher bits. No monster in the game uses 40-7f though to my knowledge?
Note for others: The 40 check is at 0042658A and only seems to be used at model death. I can't tell what it does. Doesn't look like it does much because it skips to the end and adds FFFF to a memory location (needed for some sort of check) and then pretty much that is it. I used 40 in an ememy file and see no difference to the others. It also doesn't crash the game like 80 does on an ordinary model.
-
A quick note:
To speed up the death animation (normal death) change the value at 005BBD5D (5 is a good value) and the loop that uses it. I think the death animation goes on too long. I will be adding this option to M06.
-
Interesting stuff. It's not possible to edit or change the death animations is it?
-
Can change colour or timings. The rest is based on the model itself and changing it would be a nightmare. I can't do that anyway :P
-
It's too bad it's not easy enough, otherwise we could make death animations A LA FF8
-
Oh those are not simple fade outs... those are literally model animations initiated on death.
-
so someone with enough boredom can expand on these animations and add FF8 / 9 etc style animations
good luck finding that someone though
-
No, they'd need to create proper model animations and then reprogram game to use them instead of normal red fade out. As usual, doing that is infinitely harder than saying it. Game has nothing there to assist with that. Chances I put of it ever happening? 0.