Topics

1

General Discussion / State of current wiki

« on: 2022-05-26 20:52:38 »

Is the replacement qhimm wiki gone? https://wiki.ffrtt.ru/index.php/DamageFormula This page doesn't seem to exist any longer. I don't remember the last time I checked. Probably years.

2

General Discussion / Sephiroth in Smash Bros now...

« on: 2020-12-11 17:31:50 »

Thoughts? Overpowered? Underpowered? Cash-grab?

I'm not even going to bother with this generation of smash. Nintendo's gone to the dark side of corporate greed lately and I'm not sure if this is trying to get more people to spend more money on their games or trying to appeal to cross-platform fans.

3

General Discussion / Anyone play the Japanese version of FF7 and want to help me translate a text?

« on: 2018-06-08 17:09:15 »

I was digging through the text of the original Japanese version and found this line in the battle texts:

正気にもどった
shouki ni modotta
"Consciousness was recovered"

It looks like it should be prefixed by an actor's name/title, but there's no reference to it. There is no text in the English version (maybe not even in the international version), possibly because it never got used in the game. What's further interesting is there is a verb in japanese that means this:

覚める
sameru (or sameta in past form)
"wake up/regain consciousness/sober up"

However, "shouki" can also mean "sanity". Perhaps this was intended to be displayed when a character left the confused status. Anyone have better knowledge of Japanese that can explain the differences in these two?

4

Gameplay / [FF7 mod idea] Need some help defining challenge

« on: 2018-03-14 16:31:42 »

I've noticed a few "randomizer" games starting to pop up in the modding community as a while (specically LoZ, LttP and SMB3) and thought it would be great/funny/frustrating to do this with FF7 as well. I think it's possible, with enough hijacking, to remove lots of the calculation of the mechanics and make them actually random rather than influenced by stats. statuses, power, etc. It would also be possible to randomize encounters (sans boss encounters), chest contents, shop inventories, chocobo breeding results, et al just by modifying the exe. The only question I really get stuck on is what SHOULD be randomized?

Here's a partial list of what I've determined should and shouldn't be randomized:

-Action accuracy: much more random on if it will hit or not. 50% hit rate across the board might not be great, but it will balance "well" with other plans
-Action damage/healing: as long as it connects, it can do anywhere from 0 to 9999 damage.
-Statuses/Elements being inflicted: this entire idea might be unbalanced since any random multi-hit action can one shot an entire party with paralyzation. Maybe just randomize a set of statuses (haste, slow, poison, regen, etc)
-ANY random encounter formation can be encountered anywhere: potentially terrible. Would almost certainly game over if the first random encounter was a Stilva or something.
-Chests have random contents with very few exceptions: One key among most randomizers is just randomizing placement of key items/unique items. Getting a Tissue when you thought you were getting the MP Absorb materia might be frustrating. Or using multiple save crystals might break the game.
-Shops contain random items: this is probably the hardest thing to implement and would require a seed stored somewhere. Making sure weapons had appropriate weapons/armor wouldn't be necessary if damage and accuracy is always random.
-Randomize materia: this will be the first on the chopping block since you won't be able to make mastered materia without at least one of each in a set. The best way to enforce this is to not randomize the materia at all.
-Randomize fields: Absolutely not. This will break the game in almost all cases.

Of course the most important question would be does this sound interesting to anyone? If no one would go for it then it's pointless to start. Maybe I'd release them all as individual patches so you can mix and match your favorite randomized features.

5

General Discussion / How many knew about this mechanic in FF7?

« on: 2017-12-13 14:31:28 »

https://www.youtube.com/watch?v=1X1t_B2f9Gw

Title sounds a little click-baity, but there's apparently been a lot of confusion about what happens to new-born materia with full inventories.

6

General Discussion / Steam Square sale

« on: 2016-03-04 01:43:34 »

In case anyone's interested, pretty much anything Square on Steam is on sale between 20 and 85 percent from now (3/3/16) to Monday (3/7/16).

That's:

• Dragon Quest
• Final Fantasy
• Hitman
• Tomb Raider
• Just Cause
• Deus Ex
• Thief
• Most Eidos stuff too

and all related DLC.

http://store.steampowered.com/sale/squareenix-publisher-weekend-2016

7

General Discussion / Steam release - FFXIII: Lightning Returns

« on: 2015-12-11 11:52:17 »

http://store.steampowered.com/app/345350/

The concluding chapter in the least-asked-for video game trilogy. I'm still hoping they'll port IX after this and most of the others have been Steamed.

I
II There's still hope for these two, actually. I think they got iOS ports a while back, but the PSP releases are obviously the best
III
IV
IV:AY
V
VI Officially not released yet.
VII
VIII
IX Oddly missing from everything. It's the awesome game that Square wants to forget. Licensing issues?
X
X-2 There was a PS3 HD re-release of these so it's possible we'll see these in the future.
XI
XII Way too grindy IMO. And the plot didn't make sense in the end, but when have plots made sense since IX?
XIII
XIII-2
XIII-3

8

General Discussion / Final Fantasy XIII-2 now on Steam for pre-order

« on: 2014-11-12 19:47:40 »

Well, they delivered.

http://store.steampowered.com/app/292140/

I still haven't even gotten to play the first one and I'm going to get this one too since I've got the Steam money for it.

9

Scripting and Reverse Engineering / [FF7] Vincent Mug Glitch *EXPLAINED AND SOLVED*

« on: 2014-10-22 20:58:45 »

If you've been keeping up with all my posts on things (I don't blame you if you haven't. Most of them are pretty technical) then you know I've been reversing the animation scripts in the AB files. I'd provide links to these, but I'll just re-provide relevant info here.

So, about the VMG:

WHAT IS IT?
There's an entire article on Final Fantasy wikia about it. Basically, if Vincent performs a Mug with the Shortbarrel, Winchester, Long Barrel R, Sniper CR, or Death Penalty equipped then the next action's effects are entirely skipped, but the action will still take place and do damage/heal. This includes items, summons, magics, enemy attacks, damage indicators, et al. This is so well known that it's a legitimate speed running tactic for skipping summons like Ultimate End.

WHY IS IT?
This is a three-fold explanation.

First of all it's important to understand that Vincent has three battle models. Yep, three. One for shotguns, one for pistols, and one for rifles. It's the rifle one that's bugged so we'll focus on that. Each of these has an animation file associated with it. The glitched one is SHAB. These AB files have pointers to animation scripts that tell the engine how to act (I'll get to that in part two). This particular one has a single byte different in its mug script compared to the others. For reference, this is script 36 in 0-based decimal. They each have different arguments to their F7 code and this one is set to 18 decimal.

Secondly, let's talk about what animation code F7 does. Each AB script code gets run in "chunks" between the animations. Valid codes start at a value of 8Eh and any value below that is considered an animation index (not to be confused with animation script index). This particular function tells the game to queue the damage indicator (how much damage has been done), the 2D strike effect, and the sound associated with the action to play in X frames.

Finally, let's talk about thread. More specifically, how the game handles all these effects. As some of you may know from my previous posts, there are thread queues for 2D and 3D effects in battle. Their handlers are queued when the effect starts and they are self-terminating (they remove themselves from the queue when they are done). the damage indicator is actually a 2D effect that runs for 11 frames. While this script is running the "animation thread indicator" is set to active because there are still effects in the queue. Once the animation is complete it marks the thread as complete and the effect queue as empty for the next animation to come around.

HOW IS IT?
Have you spotted the problem yet? If not, don't blame yourself. The QA team at Square didn't either. Here it is: The animation finishes before the effect starts. In fact, the animation ends on the same frame that the effect gets added to the queue. This is a problem. If the effect had started before the animation finishes then it would be cleaned up at the end of the animation. Because animation frames (and by extention, scripts) are handled BEFORE effect handlers this effect doesn't get correctly associated with the animation script. The animation script thread is marked as complete and ready to accept the next animation, but the effect queue is still marked as in-use. When the next animation comes it runs the script, but can't queue anything because it's not granted access to queue anything. All the mechanics still run in the background though so enemies are marked as dead, poisoned, or whatever. And at the "end" of the animation script (that doesn't actually do any animating) everything is correctly marked as empty/complete.

SOLUTION:
There are actually several solutions to this. By far the easiest is to DECREASE the delay the F7 creates (as mentioned above). Even decreasing this by one frame is enough to prevent this glitch. The following solution works for all PC versions of the game:

1. Open the ff7/battle/battle.lgp file in a hex editor.
2. Search for the case-sensitive ascii string "SHAB" without quotes.
3. Search for the byte sequence 17h 1Ch from the point you found the SHAB.
4. The byte preceding the 17h should be 12h. My mostly-unaltered battle.lgp file has this at address 0x3A7D7F2.
5. Change this 12h to something less. I tried 0Ch and it looks nice.

Problem solved! The effect is queued before the animation completes and the animation correctly associates the damage indicator with the animation script. Now everything gets cleared correctly and the summons can no longer be skipped.

10

Completely Unrelated / Need new high-end laptop

« on: 2014-10-12 13:11:32 »

The laptop I got for Skyrim is finally dying. It had a good run but the video hardware is messing up. For those of you with gaming laptops, where did you get them? I really like AMD processors so I'm trying to stay with them, but it doesn't seem like their newest laptop core is all that popular. Of the laptops they (AMD) list on their website they have outdated models that aren't customizable by the original manufacturers.

11

Completely Unrelated / Xeno- relation?

« on: 2014-08-29 16:25:03 »

So with the today-announcement of Shulk to the new Smash roster I had to look him up. He's the Xenoblade protagonist, great. Another rep from a game I've never played.

Is/was there any relation to the Xenoblade series and the Xenogears/Xenosaga series? I had assumed there was but Xenoblade is apparently a Nintendo series. Learned something new today.

12

Scripting and Reverse Engineering / [FF7PC] EXE 1.02 "Editing Real Estate"

« on: 2014-08-04 20:45:54 »

Ya know what? I'm tabling this for now. My XPath tracer isn't tracing enough and it's getting things I don't want. I'll have to make my own tracer at this point. That might take a while. I'll still try to make this list.

13

General Discussion / latest kimera source?

« on: 2014-06-03 17:23:44 »

Where be at? Rapidshare doesn't have .97 like the link suggests. I'm trying to put together something that can render the entire battle field at once and I still don't understand how animations are handled.

14

Solved Problems / Can't initialize sound

« on: 2014-04-04 15:52:31 »

This isn't exactly FF7 or FF8 related as the problem is outside the scope of the two. I can't load FF7 at all (haven't tried . I'm using Aali's latest driver with a slightly modded 1.02 exe. Not using it causes the error too. I can even tell you what line is causing the problem (which is why I know it's not in any of the FF7 files). The actual error is:

Debugged application message:    ERROR: No sound driver is available for use. in FILE C:\lib\src\sound\dx_snd.cpp LINE 68

which doesn't make it into the APP.LOG so I won't bother posting that. I will mention one thing, though. Some time before I noticed this happening I installed Dead Space 3 via Origin (I wouldn't have that except it came in a Humble Bundle) and did something to make my headphones work with it because EA thinks they have to do sound that one way for that game. I just want to know if anyone had this problem and managed to fix it.

FF7Config works fine though.

15

Scripting and Reverse Engineering / Hypothetical overflow glitch fix (PC)

« on: 2014-02-17 18:59:03 »

I can't search for this because the 386 processor (anyone else remember having those?) that powers these forums isn't working at its peak. If this is already known then ignore me.

So recently finding where the limit bar is filled during damage calculation made me stumble upon where damage is actually applied to the targets. That led to the line of code that causes the overflow "glitch".

The code is basically this:

Code: [Select]

newHP = CurrentHP - Damage;
if ( newHP > previousHP )
   newHP = 0;
return newHP;
In a way this makes sense, but only when dealing with HUGE numbers that overflow. Damage is NEVER supposed to be greater than 9999.
Several steps prior to this code executing, this happens:

Code: [Select]

HPDamageLimit = 9999;
...
if( damage > HPDamageLimit )
   damage = HPDamageLimit;
See where this is going? If damage is GREATER than 7FFFFFFFh. The program flow is then bypassed because 32-bit apps treat any value higher than that as negative. I've known about this snippet for a long time, but couldn't quite figure out why it was wrong. Just now I found out what the problem is: The comparison jump is signed.

The jump that is used is JLE (jump if less or equal) which is a signed jump. Clearly no one was meant to exceed 2147473648 damage. Either they didn't test it enough or thought it so insignificant to be fixed.

Changing this to an unsigned comparison suddenly eliminates this check from operating undesirably. The UNSIGNED equivalent is JBE. That should be a simple as changing 0x5DAAD0 (0x1D9ED0) from 7E to 76. Since I can't get my game running and can't test it, would someone else do the honors?

16

Completely Unrelated / After 7 years of owning it, I finally beat FF3DS

« on: 2013-12-03 16:12:39 »

I let this game gather dust for years before I decided I need to put in a little time to be done with this. I really wanted to beat the super boss before beating the game. I finally managed to do it with 73+ hours on my file after starting the experience with maybe 40. Got four full sets of Onion gear and leveled my characters to 99 having 9999MHP each and leveled their onion knight job to level 99. Super Boss's meteor spell did 0 damage to my party and CoD died in three rounds (because I spent one round attacking the physically immune tentacle with physical attacks).

Just thought I'd share. I've finally beaten the one FF that I never took the time to before (XIII and sequels/spinoffs excluded).

17

General Discussion / FF8 Save game memory location

« on: 2013-09-16 14:40:37 »

Does anyone know where FFVIII keeps its save game in memory? Every time I think I find it the memory structure is wrong.

18

General Discussion / Undiscovered FFIX sidequest.

« on: 2013-05-28 13:49:47 »

Total mindblown!

http://www.youtube.com/watch?v=9vYMDCuS_lA

19

Scripting and Reverse Engineering / (FFVII PC) The **ab files

« on: 2013-04-18 15:30:03 »

So I put my mind to it yesterday and I found out quite a bit about those elusive **ab files in the battle.lgp archive (I don't know the PSX equivalent). Thanks to DLPB who discovered that the death animations are set there, it got me wondering more about the structure of the entire file. Let me share what I've learned. Because I don't want to keep typing "**ab file" I'll refer to them as animation script files or script files or maybe just "ab".

Each model grouping (aa**, ab**, etc) has an ab file, even backgrounds. They are at least 8 bytes in size and contain lots of info on how to group animations stored in the associated **da files. The models are assigned to actors which each get a large chunk of memory to determine lots of things like position, orientation, height, model info, and a bunch of other stuff. The chunks for each model are 6892 bytes in size and exist for three player characters, the battle background model, and up to six enemy models. This chunk is where the bulk of the info in the ab file goes, just in different places.
There's also another actor-related chunk that is 116 bytes in size. This also gets a few settings from the ab file.

The ab files are broken up into three chunks:

Header:
This is what I know very little about. It has some things related to rotation of the model and possibly defines "front" and "up" for the model. I DO know where it all maps to in memory (at least on the PC version) and most of it goes into that chunk I just mentioned.

Code: [Select]

ab address     memory    size
   0x00       0xBE1178   word
   0x02       0xBE119F   byte
   0x04       0xBE118A   word
   0x06       0xBE1180   word
   0x08       0xBE1182   word
   0x0A       0xBE1184   word
   0x0C       0xBF23E6   word
   0x0E       0xBF23E8   word
   0x10       0xBF23EA   word

   0x12       0xBE11A3   byte
   0x13       0xBE11A4   byte
   0x14       0xBE11A5   byte
   0x15       0xBE11A6   byte
   0x16       0xBE11A7   byte
   0x17       0xBE11A8   byte

   0x18       0xBE11A9   byte
   0x19       0xBE11AA   byte
   0x1A       0xBE11AB   byte
   0x1B       0xBE11AC   byte
   0x1C       0xBE11AD   byte
   0x1D       0xBE11AE   byte

   0x1E       0xBE11AF   byte
   0x1F       0xBE11B0   byte
   0x20       0xBE11B1   byte
   0x21       0xBE11B2   byte

   0x22          align   word

   0x24      translate   dword
   0x28      translate   dword
   0x2C      translate   dword
   0x30      translate   dword
   0x34      translate   dword
   0x38      translate   dword
   0x3C      translate   dword
   0x40      translate   dword

   0x44       0xBF23C4   word  ;address of last actual script pointer (others may follow, but they are ignored?)
   0x46       0xBF23C6   word
   0x48       0xBF23C8   word
   0x4A       0xBF23CA   word

   0x4C       0xBF23CE   word
   0x4E       0xBF23D0   word
   0x50       0xBF23D2   word
   0x52       0xBF23D4   word
   0x54       0xBF23D6   word
   0x56       0xBF23D8   word

   0x58       0xBF23DA   word
   0x5A       0xBF23DC   word
   0x5C       0xBF23DE   word
   0x5E       0xBF23E0   word
   0x60       0xBF23E2   word
   0x62       0xBF23E4   word

   0x64       0xBF23F0   word
   0x66          align   word
I grouped them like that because that's the way the game stores them or loads them. I assume they're all related. Right now, we only really know what byte 02 does. That's the death animation.
The first word determines what type of actor it is. Most enemies is just 1, backgrounds is 501h, player characters are 0h. There might be other values, I don't know.

Now the second group. Script headers. Just like it is in text files and AI script blocks, these point to a raw memory address within the file to a script that defines an animation group for an actor. These don't get stored anywhere. Instead they are translated, but I'll mention that later. There are no more than 74 scripts in these files. Players use all of these, while enemies typically need less than 20, though those are bosses.

The file group is the actual animation scripts. These are pretty powerful scripts that control a lot about the actors. For example, using an item plays three different animations from the da file. One is hopping foward, one is tossing the item, and the last is hopping back to position. These scripts will merge all three of the actions while setting new positions, orientations and, in some cases, speed and even volume.
There are 113 opcodes ranging from 8E - FF inclusive. Some take arguments some don't. I'm still going through them. If it comes across something less than 8E it will assume it's a defined animation and attempt to execute that animation index from the **da file. If it doesn't find it...well....bad things will happen. So codes, like B2 and C9, do absolutely nothing and are skipped over and even sometimes picked up later.
For example, most enemy animation 0 (the idle animation) scripts look like this:

Code: [Select]

A9 C9 00 C1A9 takes two parameters, but completely ignores the first one. The second one gets mapped to 0xBE1186 (It's probably safe to assume that's the **da animation that will serve as the idle animation for that actor).
Now we're at C1. It's function is to find the C9 value and treat that as the next code. It will then set the animation script location at the first C9 it finds in that script. So C9 and C1 are like a loop (although C9 by itself does nothing). There might be something similar to B2 because it doesn't have a function either.

If anyone wants to help me derive the functions of these codes or functions of the header values feel free. The function that handles all this starts at 0x41FBA4 with the individual opcode handler addresses starting at 0x4248C2. First one of those handles 8E, the second handles 8F and so forth. Some are shared like 9A and FB.

I almost forgot, the translations. For the script pointers and the few dwords in the header, they get translated into RAM addresses after being loaded into memory. So if something points at 0x190 within the file, it may get translated to 0x3492A8F or wherever that file's location ends up in memory. It will still point to the same location within the file that it pointed to before so all the unique pointers will point to different places. I hope I explained that adequately.

20

General Discussion / You think you know what happened...

« on: 2012-11-14 18:44:39 »

Just watched this. Actually slightly convincing.

http://www.youtube.com/watch?v=tEJ_3_wYROc

It's a little far-fetched and relies on Cloud and co being COMPLETE idiots, but still plausible.

This guy's got some other good theories on other games too.

21

General Discussion / [SOLVED] Can anyone identify this?

« on: 2012-10-16 21:25:38 »

Ignoring the color scheme, this is a graphical representation of a string found in ff7.exe. It looks like it should be an image with a CLUT, but I can't find it so I made some colors up.



It might look more like this in-game:




In case you're wondering, it's 4096 bytes long and 64x64 with values ranging from 30h - 38h which represents the characters 0 - 8 in ASCII.
0 - Black
1 - Grey
2 - Red
3 - Orange
4 - Yellow
5 - Green
6 - Purple
7 - Blue
8 - White

There are 12 other little blocks of text that look similar to this one (in range, not shapes). This one starts at 0x991F00.

22

Scripting and Reverse Engineering / Unused sections of the exe

« on: 2012-09-11 21:59:09 »

Someone recently (Don't know whom) asked for a list of sections of code that don't get executed in the exe. I would like to attempt to compile this information as my efforts to reverse some things constantly clue me into unused sections:

0x4079B8 - 0x40800F  //starting off early and large, this looks like it used to be a large debug sub that simulated the loading and parsing of lgp files. Doesn't seem to get run.
   0x7443E7 - 0x7443FF //related to the above, this was loaded after selecting the appropriate midi lgp file
0x40AC8E - 0x40AC99
0x40B276 - 0x40B27A //one of those winxfltr functions here that doesn't get called. I don't know why there are so many in this file....
0x40B373 - 0x40B3FF //Might have something to do with playing movies. Uses a range of static bytes that don't get used elsewhere.
   0x7BB1D0 - 0x7BB377 //Range of values used by above function. Doesn't look like it does anything.
0x40F0C7 - 0x40F0CA
0x40F4F0 - 0x40F5CF
0x40F8F0 - 0x40F99F
0x40FF60 - 0x40FFBF
0x410056 - 0x41034F
0x410550 - 0x41080F
0x418DD4 - 0x41920F //might actually be used for software rendering. It's actually two functions. The first has to do with error messages related to D3D Devices. The second one is related, but I'm not sure how.
0x41AD4B - 0x41B092
0x41CD2D - 0x41CF09
0x41F1C3 - 0x41F39B //actually three different funcs called by a function above
0x41FB15 - 0x41FB1B \
0x41FA5A - 0x41FA6F  | there are lots of these little do-nothing snippets that are easily overlooked.
0x41FB15 - 0x41FB1B /
0x430266 - 0x4302E7
0x430CE4 - 0x430CF9
0x5C1FBC - 0x5C206F
0x5C8C82 - 0x5C8CF9
0x5E1D93 - 0x5E23F5 //looks like PSX code residue. Morphing models and testing hrc files and the like
0x5E2908 - 0x5E2A0F
0x5F4C67 - 0x5F4CA5
0x5FA68B - 0x5FA6F4
0x5FA761 - 0x5FA781
0x60B6F3 - 0x60B9CF
0x6384B0 - 0x6384E5
0x64060D - 0x64085B
0x64179F - 0x6417D5
0x6417DE - 0x641950 (?)
0x64271C - 0x642ACC
0x64B16A - 0x64B562
0x663C2F - 0x66415F
0x6672A1 - 0x6672CF
0x68FFA4 - 0x690052
0x6E2E5B - 0x6E2FA8
0x703828 - 0x703ABC
0x75AADC - 0x75AB4F
0x76C3C1 - 0x76C57D
0x77F324 - 0x77F397
0x7B1997 - 0x7B1A3F

Not so sure about these:
0x6CBD54 - 0x6CBD64
0x71FF95 - 0x72007F
0x719D7A - 0x719DBD
0x71A6E6 - 0x71A7A8
0x71FF8B - 0x71FF94
0x71AAA3 - 0x71E1E6  //this one is HUGE (14,147 bytes!) g and calls 357 different subs, many of which are uniquely associated with this function.
I think this might have been part of the shop menu at one time seeing all the text that is associated with it. It would be executed if 0xCC0D89 had a value of 8, but that can't happen.
These are actually called if 0xCC0D89 has a value of 9, which can happen. I'm not sure what conditions cause it, but I'm striking these from the list.

That's all I have for now. I'll update this as I find more. Feel free to chime in and let me know of other places that aren't used and I'll add them to the list.

23

General Discussion / Bizarre question about submarine game

« on: 2012-08-29 09:35:08 »

DLPB created a patch to make the sub game more manageable apparently, but I never had the slightest problem with it. What is it about the mini game that makes such a thing needed? Not to knock DLPB. I just want to know.

PS - if this seems rude or oddly worded, know that I'm typing this on an iPad having woke up at 4am and my brain doesn't fully work yet.

24

General Discussion / It's FFIX's turn.

« on: 2012-03-06 19:34:23 »

Has anyone followed this?

http://tasvideos.org/forum/viewtopic.php?t=12535

I guess with proper RNG manipulation it's possible, but all the Excalibur II guides I've seen say you have to skip the FMVs to get it in time. Definitely going to take time to watch this once the encode is done.

25

Scripting and Reverse Engineering / [FF7] Action Data Structure

« on: 2012-02-29 14:32:24 »

So I've been trying my darnedest to figure out new battle addresses and reverse damage equations and such. A long while back I found this structure of data that is used over 1200 times in the exe and is only used during battle. This seems to be populated per-target of an action whenever a battle actor initiates a command. I'd put this on the wiki, but there doesn't seem to be a place for it since the wiki doesn't deal with direct memory.

This is all for the PC's structure, first of all. The actual data is stored at 0x99E308, but there is a constant pointer to that address at 0x99CE0C that is what's always referenced. The next mapped memory address appears to be 0x99F308, but it hardly uses any of that. It consists solely of 32-bit DWords even if the value stored is a single byte. It uses 256 bytes for the actor and technical information of the attack then an additional 100 bytes for target data with a 256 byte gap between them. So the valid ranges look like 0 - 260h for the size of the array. I've mapped out quite a bit of it, but some is still eluding me. I thought I'd share what I have so far. For these purposes, "Actor" is the one performing the action.

Code: [Select]

000 - Actor Index (0-2 are playable characters, 4-9 are enemies)
004 - Actor Level
008 - Battle Formation Index?
00C - Command Index
010 - Action Index
014 - Action Data Base (0 for magic, 38h for summon, 48h for E.Skill, something else for scene.bin and limit attacks)
018 - Allowed Targets (seems to only select non-dead, active targets)
01C - Active Allies
020 - Actor's Command Animation (animation index for current action)
024 - Action Visual Effect
028 - Command Index again?
02C - Action Index again? (lots of repeats)
030 -
034 -
038 - MP Cost
03C - Action Accuracy
040 - Damage Calculation
044 - Action Element
048 - Action Power (typically 16, 2 for morph)
04C - Actor Attack or MAttack (depends on what type of attack it is)
050 - Action Targets (bitmask)
054 - Action Impact Sound
058 - Action Impact Sound again?
05C - Action Impact Sound yet again?
060 - Action Single target Camera index
064 - Action Multiple target Camera index
068 - Action Impact Anim Index
06C - Special Attack Flags
070 - Not used?
074 - Not used?
078 - ?
07C - ?
080 - Inflicting Statuses
084 - Curing Statuses
088 - Toggle Statuses (these are only ones the Action is told to effect, not the ones that actually connect and inflict)
08C - Chance to Affect Statuses
090 - Command Properties (4h - Steal attempt; 2000h - Morph attempt; etc)
094 - Some other flags?
098 - Action Index position in scene
09C - ?
0A0 - Accuracy check function (upper nybble of damage calculation value)
0A4 - Action Damage Function (lower nybble of damage calculation value)
0A8 - ?
0AC - related to magic effects, but I'm not sure what
0B0 - Number of damage calculations?
0B4 - ?
0B8 - number of targets?
0BC - Action Additional Effects
0C0 - Action Additional Effect Magnitude
0C4 - Action Power (copy of 48 above)
0C8 - Actor's current statuses
0CC - Target's Action connect animation
0D0 - ?
0D4 - ? (these two are related somehow
0D8 - Actor's Strength
0DC - Some battle related flags (36h indicates successful escape)
0E0 - ?
0E4 - ?
0E8 - ?
0EC - ?
0F0 - AllowedMagic[7] (I don't know what that means)
0F4 - ?
0F8 - AllowedMagic[3] (might be allowed multiple toggles)
0FC - ?
...
<these get changed per target>
200 - ??
204 - Character Map address (playable chars only)
208 - Target Index
20C - Formation Slot (enemy only)
210 - Target Def/MagDefense
214 - Damage taken from Action
218 - lots of flags (1h - successful hit; 4h - steal attempt; 20h - some always hit check?; 4000h - Barrier active; 8000h - MBarrier active)
21C - ?
220 - Some flags (1h - damage is healed; 2h - Critical Hit; 4h - Damages MP)
224 - Target Reaction Animation (copied from CC above I think)
228 - Target's current statuses
22C - Target's status immunities
230 - Some other weird flags (1h and 80h are used by the "Recover" damage calculation)
234 - more flags (1h - back exposed; 2h - multiple targets?)
238 - Status related (statuses successfully inflicts?)
23C - Action removes these statuses from target
240 - Status related also (statuses toggled?)
244 - ?
248 - Sound to play
24C - Action Animation to use
250 - ?
254 - Target's Level
258 - Target's HP
25C - Target's MP
260 - Action Accuracy
That's all I got. If anyone has any more info on this I'd like to know.