Apologies for the double-post (yet again ) but I would like to share some new interesting findings.
I quickly ran through the [MAGIC] files and they all have ASCII names (or some other kind of visual tag) at the end of the files, describing what they are.
Here is a list of all the names exactly as I read them (starting from file 08628):
FIRE
FIRA
FIGA
BRIZD
BRIZRA
BRIZGA
THD
GRABIDE
ANKOKU
ULTIMA
?EMPTY?
?EMPTY?
?EMPTY?
REJNE
DREIN
GRABIDE
POISON
QUAKE
STOP
BARRIER
MABARRIER
WALL
?EMPTY?
LEAVES_WUTAI SMOKE_FALL, SMOKE_BOSS_FALL
LEAVES_SPIN, SPIN_SPIN, SPIN_KISEKI
LEAVES_HIT_TEST, HIT_FLASH, SWORD_KISEKI
?EMPTY?
?EMPTY?
HIT
HIT_01
?EMPTY?
LEAVES_GOD_HAND, STEAL_HAND, STEAL_ARM
RECOVERY, SWORD_KISEKI
JUMP_JUMP, LAND_HIT, KISEKI_SHINRA , KISEKI_BASTER, KISEKI_PRASOL
RAKURAI
FIRE_HIT, SWORD_FIRE
BRI_HIT, SWORD_BRI
THD_HIT, SWORD_THD
SHOOT_THROUGH_HIT
SWORD_KISEKI
ZENI_COIN, ZENI_HIT, ZENI_PITCH
LEAVES_STEAL, STEAL_HAND
SP_CHARGE
LEAVES_SAILESS, SAIRENT2, SAIRENT4
HIT01_DEATH
ASPIL, ASPIL_HIT, ASPIL_SIPPO
QUAKE
?EMPTY?
HIT_RECOVERY
HIT01, SEORD_KISEKI
EXPLOSION_HIT, KISEKI_SHINRA
LEAVES_TEKKEN_PUNCH
LEAVES_FLARE, FLARE_FILTER, FLARE_HIT
?EMPTY?
THDGA
LEAVES_GOBURIN_PUNCH
?EMPTY?
?EMPTY?
?EMPTY?
DESP
The "?EMPTY?" ones are just my own tags, because those are 1KB files which do not contain any ASCII text.
The comma seperated ones represent multiple ASCII texts following one another in the same file.
But everything else is exactly from the files, spelling mistakes included.
My observataions:
- "R"'s are used instead of "L"s, as per Japanese fashion
- Japanese words like "KISEKI" are mixed in too
- References to "SHINRA" and "BASTER" and "PRASOL" refer to the 3 swords which Zack has during the game, namely the Shinra standard, Buster Sword and the parasol (used when on vacation at Costa De Sol)
- The spelling mistakes suggest that these ASCII characters were typed in very quickly without much care, so they probably were nothing more than aides to the developers
- Most of them seem to be obvious Materia magic, but others (like the "HIT" ones) are standard attacks used by Zack
- "DESP" is probably DMW attack activation
- "ASPIL" is probably items being used
- There are TWO "GRABIDE" files, kindof strange, no?
- "RAKURAI" and "ANKOKU" seem just as mysterious
- The one called "LEAVES_WUTAI" is quite interesting too
- "LEAVES_TEKKEN_PUNCH"
These can probably be called "Zack's Battle Attacks and Actions" to be more precise, encompassing Materia as well but by no means stopping there.
Can anyone spot anything else?
Rather than treating this as materia with other attacks thrown in, I would suggest that this is all of the battle commands... just some of them happen to be item based like materia and item usage. While this doesn't change anything, it gives a little more insight into the programmers' mindset.
an interesting note about the game that may be useful... or not, is that no matter when you do it, the fight with Minerva ALWAYS uses the Buster Sword. (This may point in some way to how scripted events work in the game at a later point.)
I finally got my custom firmware now, so at any point if you all figure out where the 'DEBUG materia' is if it exists, and you can give me an ISO offset for the memory address materia is in... I can test it out with CWCheat.
I haven't looked into the model data just yet, but I'll post anything that piques my interest once I do.
AH! and about the type 1 and type 2's MrAdults mentioned they might be 1 weight verts. This would mean that the other verts, type 2, are weighted to multiple bones. If that is the case, then we would need to figure out how the weight is displayed...
Or rather, another way to look at it... the type 1 and type 2 verts are
exactly the same but the bone data for the type 2's continues after the 1st bone index.
This means, we simply need to figure out how to determine the difference between vertex data and bone relations. I imagine the bone indeces wouldn't extend past 4... and more likely would only hold 2 bones.
Now, there are 2-3 things bone indeces would need...
Vertex in question's XYZ orientation + texture UV + :
1. how many bones are weighted...
2. bone's name (probably just a number)...
3. Bone's actual amount of influence...
here is how I would set it up if I were making the format.
x,y,z,u,v,#bones,bone1,weight1,bone2,weight2
20 32 12 20-42 02 10 32
11 32
This means vertex 32, 50, 18
has a UV of 32, 66
and has 2 bones
Bone 1 is bone number 16, and has a 50% weight.
Bone 2 is bone number 17, and has a 50% weight.
(I used a 100% scale on the bone weight, because a decimal number would be harder to program. the scale goes from 00(0) to 64(100) )
This is only my thoughts on how it might be worded for efficiency. So, looking at that, the type 2 verts might be as long as 10 offsets if they only have 2 bones, and up to 14 if they had as many as 4 bones weighted.(this is unlikely, but possible...)
Type 1 verts mightn't need the bone amount mini header, and would be implicitly converted.
Still, this is all speculation- Educated speculation, but speculation nonetheless.
In short... We need to decipher the bone data.
EDIT:
Ok, Upon examining I find that the verts are separated by a series of 00 chunks... between 00 00 00 and 00 00 00 00 00 00 long... what are these for? I could speculate that the length of this padded 0 data is used in determining the type of vertex it is. I notice the very first vert begins with a 4 byte long 00 00 00 00.
(In Reno)
So, my guess is that the verts begin with the padded 0's to determine their type, and then use actual coords to determine their location. I could be wrong, but that is my first thought.